Free SC-500 Practice Test Questions and Answers (2026)

To manage and assign incidents in Microsoft Sentinel, a user must be granted the Microsoft Sentinel Responder Azure role. This built-in role provides the necessary permissions to read security data and perform incident management actions, such as actively assigning, updating, or dismissing incidents.

Additionally, Microsoft Entra ID restricts guest accounts from enumerating directory objects (like user lists) by default. When a guest user attempts to assign an incident, they must query the directory to find and select available users. Microsoft explicitly dictates that guest users require directory reading permissions—typically the Directory Readers role—to perform this assignment action. Because Directory Readers is not among the available options in the provided dropdown menu, Global Reader is the correct technical selection. The Global Reader role provides read-only access to all administrative features and directory objects, inherently granting the required permissions to list users for incident assignment. Conversely, the Security Reader role strictly limits read access to security-specific telemetry (e.g., Identity Protection, Defender alerts) and lacks the general directory enumeration rights needed to search the tenant for assignees.

Microsoft Learn: Roles and permissions in the Microsoft Sentinel platform

Section: Built-in Azure roles for Microsoft Sentinel & Playbook permissions (Specifically the "Guest users assign incidents" requirement).

Document Identifier: https://learn.microsoft.com/en-us/azure/sentinel/roles

Microsoft Learn: Microsoft Sentinel incident investigation in the Azure portal

Section: Prerequisites (Details the explicit requirement for guest users to possess directory reading capabilities to assign incidents).

Document Identifier: https://learn.microsoft.com/en-us/azure/sentinel/incident-investigation

Microsoft Learn: Microsoft Entra built-in roles

Section: Global Reader and Security Reader (Outlines the specific microsoft.directory/users/read permission scopes).

Document Identifier: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference

To adhere to the principle of least privilege, AKS1 requires only the ability to pull container images from the Azure Container Registry (ACR). The AcrPull built-in role provides exactly this specific permission without granting management or push rights. For the deployment automation managed identity (ID1) to successfully modify and deploy Azure resources across the environment, the Contributor role is required. Contributor grants the necessary rights to create and manage resources while restricting the ability to assign access rights to others (which would require the overly permissive Owner role).

Microsoft Learn, "Authenticate with Azure Container Registry from Azure Kubernetes Service (AKS)," Azure Kubernetes Service (AKS) Documentation. Specifies that granting the AcrPull role to the AKS managed identity is the standard and least-privilege method for ACR integration.

Microsoft Learn, "Azure built-in roles," Azure Role-Based Access Control (RBAC) Documentation. Defines the Contributor role as granting full access to manage all resources while explicitly denying the ability to assign roles in Azure RBAC, satisfying the deployment automation requirement under least privilege constraints.

Approval: When deploying partner-built agents from the Microsoft Security Store that require access to Microsoft products (such as Microsoft Entra, Sentinel, or Defender), the agent must receive tenant-wide admin consent. Microsoft explicitly requires a Global Administrator to approve and grant these necessary permissions. In this scenario, User2 is the Global Administrator and must complete the approval step.

Agent Setup: To enforce the principle of least privilege and strict role-based access control (RBAC), Microsoft Security Copilot agents are designed to run under either a user account or a managed identity. Using a managed identity allows administrators to strictly govern and restrict the data the agent can process without the risks associated with static credentials (which are often tied to traditional app registrations), thereby ensuring all automated actions are securely scoped and auditable.

Microsoft Learn: Setup and manage Security Copilot agents

Section: Set up partner-built agents

States: "When setting up a partner-built agent that accesses a Microsoft tool (skill) and accesses data from a Microsoft product... a Global Administrator within the tenant must approve to allow access of required permissions for the agent."

URL: [https://learn.microsoft.com/en-us/copilot/security/agents-manage](https://learn.microsoft.com/en-us/copilot/security/agents-manage)

Microsoft Learn: Application card for Microsoft Security Copilot agents

Section: Agent identity governance and Role-based access control (RBAC)

States: "Each Security Copilot agent runs under either a managed identity or a user account, enabling the administrator to govern the data it has access to. Each agent has RBAC controls, and the agents may be further restricted as to what data they process."

URL: [https://learn.microsoft.com/en-us/copilot/security/security-copilot-application-card-agents](https://learn.microsoft.com/en-us/copilot/security/security-copilot-application-card-agents)

To detect plaintext secrets—such as SSH private keys, API tokens, and credentials—stored on virtual machine disks while minimizing administrative changes (i.e., avoiding agent deployments), you must utilize agentless secret scanning. This out-of-band scanning method operates by taking snapshots of VM disks and analyzing them without impacting the workload. This capability is unlocked by enabling the Defender Cloud Security Posture Management (CSPM) plan (or Defender for Servers Plan 2) and subsequently toggling the "Agentless machine scanning" feature in the environment settings.

Microsoft Learn. "Agentless scanning for virtual machines." Microsoft Defender for Cloud Documentation, Section: How does agentless scanning work.

Microsoft Learn. "Discover and manage secrets in Microsoft Defender for Cloud." Microsoft Defender for Cloud Documentation, Section: Agentless secret scanning for virtual machines.

Creating a private endpoint establishes a private network path to the storage account but does not grant the necessary permissions for access. The virtual machines' managed identities must be granted an appropriate Azure RBAC role, such as 'Storage Blob Data Reader' or 'Storage Blob Data Contributor', on the storage account. Since public network access is already enabled, the primary missing component is authorization, not network connectivity. The private endpoint alone does not solve the access goal.

A. Yes: This is incorrect because a private endpoint only addresses network-level access. It does not configure the required identity-based permissions (Azure RBAC) for the VMs' managed identities to access the storage account's data.

1. Microsoft Learn: "Authorize access to data in Azure Storage". This document distinguishes between network security and authorization. It states, "Authorizing access to Azure Storage is a separate step from securing network access to the storage account... you must also authorize every request to a secured resource." This confirms that network configuration (like a private endpoint) and authorization (RBAC) are separate, required steps.

2. Microsoft Learn: "What is Azure Private Endpoint?". The documentation defines a private endpoint as "a network interface that provides a private and secure connection to a service powered by Azure Private Link." This highlights its function as a network component, not an identity or authorization tool.

3. Microsoft Learn: "Assign an Azure role for access to blob data". This guide details the necessary steps to grant permissions using RBAC, which is the action required to allow the managed identities to access the storage account. The proposed solution does not perform this critical step.

The tenant configuration explicitly disables user consent and requires an administrator to grant permissions. The application needs delegated permissions to access Microsoft Graph on behalf of the user. The only way to satisfy these conditions and prevent interactive consent prompts for users is for an administrator to grant tenant-wide admin consent. This action pre-approves the requested delegated permissions for all users in the organization, allowing them to sign in and use the application seamlessly without being blocked for consent they are not allowed to provide.

A. Requiring user assignment controls who can access the application but does not grant the necessary API permissions. The consent problem would still exist.

B. Using application permissions is incorrect because the requirement is for the app to act "on behalf of the signed-in user," which is the specific purpose of delegated permissions.

C. This option is not viable because the tenant is configured to prevent user consent. Relying on a disabled feature will result in sign-in failures.

1. Microsoft Learn: Grant tenant-wide admin consent to an application. This document states, "If user consent is disabled, your users can't grant consent for the applications they use. To make sure your users can still use applications you want to allow, you can grant tenant-wide admin consent to those applications." This directly supports the correct answer.

Source: Microsoft Entra ID Documentation, "Grant tenant-wide admin consent to an application," Introduction section.

2. Microsoft Learn: Permissions and consent in the Microsoft identity platform. This document clarifies the nature of delegated permissions. "For delegated permissions, the effective permissions of your app will be the least privileged intersection of the delegated permissions the app has been granted (via consent) and the privileges of the currently signed-in user." This confirms that consent is a prerequisite for delegated permissions to function.

Source: Microsoft identity platform documentation, "Permissions and consent in the Microsoft identity platform," section on "Delegated permissions."

3. Microsoft Learn: Configure how users consent to applications. This document explains the effect of disabling user consent. "When you choose this option [Do not allow user consent], admins must consent to any new application that users need." This confirms that admin action is the only path forward in the scenario.

Source: Microsoft Entra ID Documentation, "Configure how users consent to applications," section on "User consent settings."

To enforce advanced identity-based security controls like multi-factor authentication (MFA) or location-based access for an Azure SQL Database, two sequential steps are required. First, you must configure the parent SQL Server (SQLServer1) to use Microsoft Entra authentication. This enables the database to authenticate users based on their Entra ID identities instead of only SQL logins. Second, once Entra authentication is enabled, you can create a Conditional Access policy that targets the "Azure SQL Database" application. This policy is the mechanism used to enforce specific requirements, such as MFA, for users attempting to connect to SQLdb1.

A. Create a compliance policy.

A compliance policy (managed via Intune) defines rules for devices. While it can be used as a condition within a Conditional Access policy, it does not directly implement the authentication change on the SQL database.

D. Configure federated client identity for SQLdb1.

This is not a standard Azure configuration. Identity federation is configured between identity providers (like on-premises AD FS and Microsoft Entra ID), not directly on a specific Azure SQL database.

E. Configure a user-assigned managed identity for SQLdb1.

A managed identity is assigned to an Azure resource (like a VM or App Service) to allow it to authenticate to other services (like SQLdb1), not the other way around.

---

1. Microsoft Learn, Azure SQL Database Documentation. "Tutorial: Secure your Azure SQL Database". This official tutorial outlines the steps for securing a database, including the prerequisite of enabling Microsoft Entra authentication before applying advanced controls.

Reference: Section "Enable Microsoft Entra authentication". https://learn.microsoft.com/en-us/azure/azure-sql/database/secure-database-tutorial?view=azuresql#enable-microsoft-entra-authentication

2. Microsoft Learn, Azure SQL Database Documentation. "Conditional Access with Azure SQL Database and Azure Synapse Analytics". This document explicitly states the dependency between the two correct actions.

Reference: Under the "Prerequisites" section, it states: "You must configure your Azure SQL Database or Azure Synapse Analytics to support Microsoft Entra authentication. For a specific walkthrough, see Configure and manage Microsoft Entra authentication with Azure SQL." https://learn.microsoft.com/en-us/azure/azure-sql/database/conditional-access-configure?view=azuresql

3. Microsoft Learn, Microsoft Entra Documentation. "What are managed identities for Azure resources?". This document clarifies the purpose of managed identities, confirming they are assigned to client resources, not target databases.

Reference: "Overview" section. https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview

4. Microsoft Learn, Microsoft Intune Documentation. "Use compliance policies to set rules for devices you manage with Intune". This explains that compliance policies are used with Conditional Access to control access based on device state.

Reference: "How device compliance policies work with Conditional Access" section. https://learn.microsoft.com/en-us/mem/intune/protect/device-compliance-get-started#how-device-compliance-policies-work-with-conditional-access

To restrict access to assigned Microsoft Entra users and groups, you must first ensure the authentication method is utilizing Microsoft Entra ID. For Azure App Service built-in authentication, this is configured by selecting The Microsoft identity provider.

By default, when an application is registered in Microsoft Entra ID, any user within the tenant can authenticate to it. To lock down access to only authorized corporate users, you must configure the Enterprise app assignment required setting. This is done by navigating to the application's Enterprise Application properties in the Azure portal and toggling "Assignment required?" to "Yes". This enforces that only users or groups explicitly assigned to the application can successfully obtain an access token.

Microsoft Learn. "Configure your App Service or Azure Functions app to use Microsoft Entra sign-in." Microsoft, https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad. (Refer to the "Configure with Microsoft as the identity provider" section).

Microsoft Learn. "Restrict your Microsoft Entra app to a set of users in an Microsoft Entra tenant." Microsoft, https://learn.microsoft.com/en-us/entra/identity-platform/howto-restrict-your-app-to-a-set-of-users. (Refer to the "Require user assignment" section detailing the Enterprise Application property change).

To access Microsoft Graph as a background service or autonomous agent without a signed-in user, you must use application permissions. Delegated permissions are invalid here because they require active user consent and interaction. An administrator must grant these application permissions to the agent identity.

To allow the agent to read secrets from a single Azure Key Vault, the recommended approach is to assign an Azure role-based access control (RBAC) role (such as the Key Vault Secrets User role) to the agent's identity. This role assignment is scoped directly to the specific Key Vault, securely providing data-plane access without any runtime user interaction.

Microsoft Entra ID Documentation: Permissions and consent in the Microsoft identity platform. Section: "Types of permissions" (Paragraph detailing Application Permissions for background services and daemons running without a signed-in user).

Azure Key Vault Documentation: Provide access to Key Vault keys, certificates, and secrets with an Azure role-based access control. Section: "Overview" and "Best practices for Key Vault RBAC" (Detailing the assignment of data-plane roles directly to service principals and managed identities).

To securely expose specific virtual machines (VM1 and VM2) to a partner network (VNet2) residing in a different Microsoft Entra tenant without exposing the entire virtual network, Azure Private Link is the required architecture. You must configure an Azure Private Link service in VNet1, which utilizes an Azure Standard Load Balancer to route incoming traffic directly to the target VMs. In VNet2, you configure a private endpoint that establishes a secure connection to the Private Link service. This satisfies the requirement to deny access to other Sub1 resources by strictly isolating the connection to the approved service, whereas VNet peering would broadly route traffic between the entire networks by default.

Microsoft Corporation. "What is Azure Private Link?" Azure Virtual Network Documentation. Section: Key Benefits (Cross-tenant access and Data leakage protection). Available at: https://learn.microsoft.com/en-us/azure/private-link/private-link-overview

Microsoft Corporation. "Create an Azure Private Link service." Azure Virtual Network Documentation. Section: Prerequisites (Standard Load Balancer requirement for exposing IaaS resources). Available at: https://learn.microsoft.com/en-us/azure/private-link/create-private-link-service-portal