Microsoft SC-500 - Questions & Answers

AKS workload protection is best handled with Microsoft Defender for Containers because that plan covers Kubernetes clusters, container images, registries, and runtime signals. The requirement centers on protecting applications hosted on Azure Kubernetes Service, so the control must operate where that security decision is enforced rather than at a neighboring resource or reporting layer. When the protected workload is an AKS cluster, container-aware recommendations and threat detections are needed across admission, node, registry, and workload activity.

Defender for Servers focuses on hosts, Defender for App Service protects web apps, Defender for Resource Manager watches control-plane operations, and Defender for Storage protects storage accounts. Microsoft Defender for Containers keeps the implementation focused on the service boundary, identity boundary, or data boundary named by the scenario. For aks workload protection, administrators should verify the exact enforcement point, the identity or data boundary involved, and the operational evidence that proves the setting is active. The container plan is therefore the narrow Defender for Cloud plan that maps to the application platform described.

Storage account encryption for table-capable storage is best handled with an account encryption key because a customer-managed account key can apply across the storage account services that need Fabrikam-managed encryption. The requirement centers on encrypting all storage data with a customer-managed key, so the control must operate where that security decision is enforced rather than at a neighboring resource or reporting layer. Account encryption centralizes the key choice for the account and lets the organization own key rotation and key access decisions in Key Vault.

An encryption scope is useful for selected blob data, but it is not the broad account-level answer for every service in a storage account that includes table storage. an account encryption key keeps the implementation focused on the service boundary, identity boundary, or data boundary named by the scenario. For storage account encryption for table-capable storage, administrators should verify the exact enforcement point, the identity or data boundary involved, and the operational evidence that proves the setting is active. Purge protection and role assignment are useful controls, but they do not change which key encrypts the storage data.

Function app outbound routing to an on-premises network is best handled with Fa1 and Fa3 because Flex Consumption and Dedicated hosting can use virtual network integration for outbound connectivity patterns required by ExpressRoute. The requirement centers on forcing outbound traffic from supported function apps through private network connectivity, so the control must operate where that security decision is enforced rather than at a neighboring resource or reporting layer. Including only the plans that support the required integration avoids deploying an app that cannot meet the network path requirement.

The classic Consumption plan is the weak fit because it lacks the same outbound networking capability for this requirement. Fa1 and Fa3 keeps the implementation focused on the service boundary, identity boundary, or data boundary named by the scenario. For function app outbound routing to an on-premises network, administrators should verify the exact enforcement point, the identity or data boundary involved, and the operational evidence that proves the setting is active. The result is a hosting-plan decision, not an application-code decision or a firewall-only decision.

The Defender for Cloud planned compliance change is best handled with Admin1 because Admin1 has the Resource Policy Contributor role, which aligns with assigning regulatory standards and initiatives. The requirement centers on delegating only the policy-related work needed for the compliance standard, so the control must operate where that security decision is enforced rather than at a neighboring resource or reporting layer. Using the policy contributor keeps the implementation near Azure Policy and Defender for Cloud compliance management.

The other listed users either have identity roles, broad access-administration permissions, or no relevant Azure policy assignment capability. Admin1 keeps the implementation focused on the service boundary, identity boundary, or data boundary named by the scenario. For the defender for cloud planned compliance change, administrators should verify the exact enforcement point, the identity or data boundary involved, and the operational evidence that proves the setting is active. Least privilege favors the user with the narrow policy assignment role instead of a global administrator path. For the defender for cloud planned compliance change, administrators should verify the exact enforcement point, the identity or data boundary involved, and the operational evidence that proves the setting is active.

Disabling SQL authentication on an Azure SQL logical server is best handled with Microsoft Entra-only authentication because that setting blocks SQL authentication for databases under the server from one central control point. The requirement centers on server-level enforcement instead of per-database cleanup, so the control must operate where that security decision is enforced rather than at a neighboring resource or reporting layer. The central setting preserves the management model and prevents SQL password logins across the server.

Adding an Entra administrator enables identity administration but does not by itself deny SQL logins, and removing logins from one database is incomplete. Microsoft Entra-only authentication keeps the implementation focused on the service boundary, identity boundary, or data boundary named by the scenario. For disabling sql authentication on an azure sql logical server, administrators should verify the exact enforcement point, the identity or data boundary involved, and the operational evidence that proves the setting is active. Managed identity helps Azure resources authenticate, but it is not a switch that disables SQL authentication.

Delegated Microsoft Graph access when user consent is disabled is best handled with admin consent for the required delegated permissions because users cannot grant the permissions interactively when tenant policy disables user consent. The requirement centers on allowing user sign-ins without consent prompts while preserving delegated access, so the control must operate where that security decision is enforced rather than at a neighboring resource or reporting layer. An administrator must pre-consent to the delegated scopes so the application can request tokens for signed-in users.

Changing to application permissions would change the operating model from on-behalf-of-user access, and user assignment does not grant Graph scopes. admin consent for the required delegated permissions keeps the implementation focused on the service boundary, identity boundary, or data boundary named by the scenario. For delegated microsoft graph access when user consent is disabled, administrators should verify the exact enforcement point, the identity or data boundary involved, and the operational evidence that proves the setting is active. That preserves the delegated permission design while meeting the tenant consent restriction.