📘 Free SC-500 Sample Questions
You have an Azure SQL Database logical server named Server1 that contains a database named DB1.
You need to configure authentication for Server1 to meet the following requirements:
SQL authentication cannot be used for any databases on Server1.
The solution must be enforced centrally at the server level.
What should you do?
A
Configure a Microsoft Entra administrator for Server1.
B
Enable a managed identity for Server1.
C
Enable Microsoft Entra-only authentication for Server1.
D
Remove SQL logins from DB1.
Correct Answer:
C. Enable Microsoft Entra-only authentication for Server1.
Explanation:
Technical Justification for Correct Answer (C)
To meet the specified requirements for Server1 (an Azure SQL Database logical server containing DB1), the
correct approach is to Enable Microsoft Entra-only authentication for Server1 (Option C). Here's why:
Requirement 1: SQL authentication cannot be used for any databases on Server1
Option C directly addresses this by enforcing Microsoft Entra (formerly Azure Active Directory, AAD) as the
sole authentication method, effectively disabling SQL authentication at the server level.
Requirement 2: The solution must be enforced centrally at the server level
Option C is applied at the server level (Server1), ensuring a centralized enforcement across all databases
(including DB1) under this server, aligning perfectly with this requirement.
Why Other Options are Less Suitable:
Option A: Configure a Microsoft Entra administrator for Server1
This sets up an administrator but does not inherently disable SQL authentication for all databases on the
server. It's a part of managing access but doesn't meet the first requirement on its own.
Option B: Enable a managed identity for Server1
Managed identities are primarily used for the server to authenticate to other Azure services, not for end-user
or application authentication to the database. This does not address the SQL authentication requirement.
Option D: Remove SQL logins from DB1
This option only affects DB1 and not all databases on Server1, failing to meet the centralized, server-level
enforcement requirement. Additionally, new SQL logins could potentially be created unless a server-level policy
prevents it.
Correct Action Summary:To ensure SQL authentication is disabled across all databases on Server1 and to
enforce this policy centrally at the server level, enabling Microsoft Entra-only authentication for Server1
(Option C) is the most appropriate and effective solution.
References:
Microsoft Entra (Azure AD) Authentication with Azure SQL
Azure SQL Database Authentication Modes
You have a Microsoft Entra tenant that has the following configurations:
User consent for applications is disabled.
Only administrators can grant permissions to applications.
You register an application named App1 that uses delegated Microsoft Graph permissions.
You need to configure App1 to meet the following requirements:
Enable user sign-ins without interactive consent prompts.
Enable App1 to access Microsoft Graph on behalf of the signed-in user.
What should you do?
A
Configure enterprise applications to require user assignment and assign users to App1.
B
Modify the app registration to use application permissions instead of delegated permissions.
C
Add the required delegated Microsoft Graph permissions to the app registration and rely on user consent during sign-in.
D
Grant admin consent to App1 for the required delegated permissions.
Correct Answer:
D. Grant admin consent to App1 for the required delegated permissions.
Explanation:
Technical Justification for Correct Answer D
Requirements Recap:
Why D is the Correct Answer:
1. Enable user sign-ins without interactive consent prompts.
2. Enable App1 to access Microsoft Graph on behalf of the signed-in user using delegated permissions.
Grant admin consent to App1 for the required delegated permissions directly addresses both requirements.
By granting admin consent, users are not prompted for consent during sign-in (meeting requirement 1), as
the organization (via an administrator) has already approved the permissions.
Delegated permissions are retained, allowing App1 to access Microsoft Graph on behalf of the signed-in user
(meeting requirement 2), which is essential for user-specific data access.
Why Other Options are Less Suitable:
A. Configure enterprise applications to require user assignment and assign users to App1
Inadequate for Requirement 2: User assignment is more commonly associated with application permissions,
not delegated permissions. This does not inherently solve the consent issue for delegated permissions.
Interactive Consent Still a Issue: Doesn't directly address the need to avoid interactive consent prompts for
delegated permissions.
B. Modify the app registration to use application permissions instead of delegated permissions
Fails Requirement 2: Switching to application permissions would allow App1 to access Microsoft Graph
without a user context, failing to meet the requirement of acting on behalf of the signed-in user.
Consent Not an Issue but Requirement Misalignment: While consent isn't an issue with app permissions, this
option misaligns with the functional requirement.
C. Add the required delegated Microsoft Graph permissions to the app registration and rely on user consent
during sign-in
Fails Requirement 1: Directly contradicts the need to avoid interactive consent prompts by relying on user
consent during sign-in.
Correct Approach for Permissions but Misaligned with Consent Requirement: Correctly retains delegated
permissions but fails to address the consent automation requirement.
appropriate and efficient solution.
References
Correct Action Summary:To meet both requirements without compromising on the functionality or
introducing unnecessary prompts, granting admin consent for the required delegated permissions is the most
1. Microsoft Documentation - Delegated and Application Permissions: https://docs.microsoft.com/en
us/azure/active-directory/develop/v2-permissions-and-consent
2. Azure AD: Admin Consent for Permissions: https://docs.microsoft.com/en-us/azure/active
directory/develop/v2-admin-consent-flow
You have a Microsoft Entra tenant that uses Privileged Identity Management (PIM).
You need to modify the AI Administrator role settings to meet the following requirements:
Elevated access must be evaluated by another administrator before it is granted.
Privileged access must be removed automatically after a fixed period.
Which two settings should you configure? Each correct answer presents part of the solution.
NOTE: Each correct selection is worth one point.
A
Require approval to activate
B
Require justification on activation
C
Expire eligible assignments after
D
Expire active assignments after
E
Activation maximum duration
Correct Answer:
A. Require approval to activate
Explanation:
Technical Justification for Correct Answer: B and E (BE)
To modify the AI Administrator role settings in Microsoft Entra's Privileged Identity Management (PIM) to
meet the specified requirements, the following settings are justified as the best choices:
Requirement 1: Elevated access must be evaluated by another administrator before it is granted.
Correct Setting: B. Require approval to activate
Justification: This setting ensures that when a user requests to activate their eligible AI Administrator role, the
request is sent for approval to another designated administrator, fulfilling the requirement for pre-grant
evaluation.
Why not C (Require justification on activation): While requiring justification adds an extra layer of scrutiny, it
does not guarantee evaluation by another administrator before grant, as justification can be reviewed post
facto or not thoroughly vetted.
Requirement 2: Privileged access must be removed automatically after a fixed period.
Correct Setting: E. Activation maximum duration
Justification: Setting a maximum duration for activation ensures that once a user's AI Administrator role is
activated, their privileged access automatically expires after the specified fixed period, aligning with the
requirement.
Why not A (Expire active assignments after) or D (Expire eligible assignments after):
A is less suitable because it implies the assignment is already active, and the setting might not apply
uniformly to all activation scenarios managed through PIM's just-in-time access model.
D is incorrect because it refers to expiring eligible assignments (before they are even activated), which does
Incorrect Options Briefly Addressed:
administrator.
access.
References
not directly address the automatic removal of active privileged access after a fixed period post-activation.
C. Require justification on activation: As mentioned, this does not guarantee pre-grant evaluation by another
A & D: Misaligned with the specific requirement for automatic removal post-fixed period of active privileged
For deeper dive and configuration steps:
1. Microsoft Learn - Privileged Identity Management in Microsoft Entra:
https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/
2. Microsoft Docs - Azure AD roles and administrators: https://docs.microsoft.com/en-us/azure/active
directory/roles/permissions-reference
You have two management groups named MG1 and MG2 that contain multiple Azure subscriptions. The
subscriptions are linked to a Microsoft Entra tenant.
You have a user named User1 and a global administrator named Admin1.
You are informed that User1 created an Azure subscription named Sub1 under the MG2 management group and is
the only owner of the subscription.
You need to ensure that Admin1 can remove the Owner role from User1 for Sub1.
What should you do first?
A
Move Sub1 to MG1.
B
Assign Admin1 the User Access Administrator role for Sub1.
C
Instruct Admin1 to use Privileged Identity Management (PIM) to request the Security Administrator role.
D
Instruct Admin1 to enable Access management for Azure resources.
Correct Answer:
D. Instruct Admin1 to enable Access management for Azure resources.
Explanation:
Technical Justification for Correct Answer (D)
To ensure Admin1 can remove the Owner role from User1 for Sub1, the most appropriate first step is D.
Instruct Admin1 to enable Access management for Azure resources. Here's why:
Why D is Correct:
Access Management for Azure Resources (also known as Azure Resource Access) is a feature that allows
global administrators in Microsoft Entra (formerly Azure AD) to manage Azure resources (like subscriptions)
without needing to be added as owners or have any direct role assignment on the Azure subscription itself.
By enabling this feature, Admin1 (as a global administrator) gains the capability to manage access (including
removing roles) for any Azure resource linked to the Microsoft Entra tenant, without prior direct access to
Sub1.
This approach does not require changing the management group structure (making it more straightforward
than A) or assigning specific roles to Admin1 for Sub1 (as in B and C), which would either alter the environment
unnecessarily or not directly solve the access management issue for the global administrator's capabilities.
Why Other Options are Less Suitable:
A. Move Sub1 to MG1:
Unnecessary Structural Change: Moving the subscription to a different management group does not
inherently grant Admin1 the ability to manage roles on Sub1 unless MG1 has specific access controls pre
access issue.
B. Assign Admin1 the User Access Administrator role for Sub1:
wide management.
configured to allow global administrators (or Admin1 explicitly) to manage subscriptions within it.
Additional Complexity: Introduces unnecessary movement of resources without directly addressing the
Role Assignment Overhead: Requires direct intervention on Sub1 to assign a role to Admin1, which might not
be desirable or could be seen as bypassing the intent of leveraging global administrator privileges for tenant
Scope: While this would work, it's more about direct assignment rather than leveraging the global admin's
capabilities for cross-resource management.
C. Instruct Admin1 to use Privileged Identity Management (PIM) to request the Security Administrator role:
Role Misalignment: The Security Administrator role does not grant the permissions necessary to remove an
Owner role from a subscription. PIM is useful for just-in-time access but doesn't apply here as the issue is
enabling the global admin's inherent capabilities.
Incorrect Role for the Task: Requesting a role that doesn't solve the problem (managing Azure resource
access) makes this option less suitable.
You have a management group named MG1 that contains two subscriptions named Sub1 and Sub2.
Sub1 contains a resource group named RG-Exception and a resource group named RG1 that hosts Microsoft
Foundry resources.
You need to assign an Azure policy to force new Foundry deployments in MG1 to use private endpoints. The
solution must NOT restrict deployments in RG-Exception.
How should you configure the policy?
A
Assign the policy to MG1 and exclude RG-Exception.
B
Assign the policy to Sub1 and RG-Exception.
C
Assign the policy to MG1 and RG-Exception.
D
Assign the policy to Sub1 and exclude RG-Exception.
Correct Answer:
A. Assign the policy to MG1 and exclude RG-Exception.
Explanation:
Technical Justification for Correct Answer (A)
Assigning the policy to MG1 (Management Group) and excluding RG-Exception is the most appropriate
approach for enforcing the requirement that new Foundry deployments in MG1 use private endpoints without
restricting deployments in RG-Exception. Here's why:
Scope of Policy Application: By assigning the policy to MG1, the scope encompasses all subscriptions under it
(Sub1 and Sub2), ensuring the policy applies broadly where intended (all of MG1) without needing to
individually target each subscription.
Exclusion Requirement: Excluding RG-Exception directly meets the requirement to not restrict deployments
in this specific resource group. This targeted exclusion ensures the policy's enforcement is nuanced, applying
to all relevant areas except where explicitly exempted.
Precision and Scalability: This approach is precise because it targets the exact scope needed (MG1 for broad
coverage, exclusion for RG-Exception) and is scalable. If new subscriptions are added under MG1, the policy
will automatically apply, maintaining compliance without additional configuration.
Why Other Options are Less Suitable:
B. Assign to Sub1 and RG-Exception:
Incomplete Scope: Only applies to Sub1, leaving Sub2 (also under MG1) unprotected/unenforced.
Incorrect Exclusion Approach: Assigning to RG-Exception would incorrectly target the exclusion as the
primary scope, rather than an exception to a broader rule.
C. Assign to MG1 and RG-Exception:
Exception, which is misleading in the context of needing an exclusion.
not clearly achieving the exclusion goal.
D. Assign to Sub1 and exclude RG-Exception:
leaving parts of the managed environment unchecked.
Correct Approach Recap (A):
Misinterpreted Exclusion: Suggests applying the policy to both MG1 broadly and then somehow "also" to RG
Logical Conflict: Implies both applying and not applying (through exclusion) the policy in a confusing manner,
Limited Scope: Similar to B, this only ensures compliance for Sub1, ignoring Sub2 under MG1.
Partial Compliance: While correctly excluding RG-Exception, it fails to address the broader MG1 scope,
Assign Policy To: MG1 (Broad Coverage)
Exclude: RG-Exception (Precise Exemption)
References
For deeper dives into Azure Policy assignments, scopes, and exclusions:
1. Azure Policy Documentation - Understanding Policy Scope: https://docs.microsoft.com/en
us/azure/governance/policy/concepts/scoping
2. Assigning Azure Policies with Exclusions: https://docs.microsoft.com/en
us/azure/governance/policy/tutorials/create-and-manage#exempt-objects-from-policy-effects
You have an Azure key vault named KV1 that uses role-based access control (RBAC) authorization. KV1 stores
database connection strings for an Azure App Service web app named App1.
You enable a firewall on KV1 and allow access to KV1 from only the virtual network that contains App1.
You need to ensure that App1 can retrieve secrets from KV1 without using credentials stored in the application
configuration.
What should you create?
A
an access policy for KV1
B
an app registration for App1
C
a private endpoint for KV1
D
a managed identity for App1
Correct Answer:
D. a managed identity for App1
Explanation:
Technical Justification for Correct Answer: D
To ensure Azure App Service web app (App1) can retrieve secrets from Azure Key Vault (KV1) without storing
credentials in the application configuration, the most appropriate solution involves leveraging managed
identities. Here’s why:
Correct Answer: D - a managed identity for App1
Why Other Options are Less Suitable:
A. an access policy for KV1
complementary step, not a standalone solution.
B. an app registration for App1
C. a private endpoint for KV1
Reason: Managed Identities for Azure Resources (previewed as Managed Service Identities) allows App1 to
authenticate to Azure services, including Key Vault, without storing credentials in the app configuration.
Technical Justification: By assigning a managed identity to App1, you enable it to obtain an access token for
KV1 through Azure Active Directory (AAD) without explicitly coding credentials. KV1's RBAC authorization
then grants access based on the managed identity's role, ensuring secure, credential-less authentication.
References
Limitation: While an access policy is necessary for granting permissions to the managed identity, creating an
access policy alone does not address the requirement of avoiding credentials in the app configuration. It's a
Inappropriateness: Registering the app would be the first step if you were manually managing service
principals and credentials, which is exactly what you're trying to avoid. Managed identities simplify this
process without needing to explicitly manage app registrations for this specific use case.
Irrelevance to Credential Management: A private endpoint enhances the security of the network connection
to KV1 by providing a private IP address, but it does not solve the problem of authenticating to KV1 without
storing credentials in the application configuration.
Managed Identities for Azure Resources
Azure Key Vault Authentication
DRAG DROP -
You have a Microsoft Entra tenant.
You need to implement passwordless authentication. The solution must meet the following requirements:
Users can sign in without a password by using a mobile device.
New users that sign in for the first time must use a helpdesk-issued sign-in method that expires.
Which authentication method should you enable for each requirement? To answer, drag the appropriate methods
to the correct requirements. Each method may be used once, more than once, or not at all. You may need to drag
the split bar between panes or scroll to view content.
NOTE: Each correct selection is worth one point.
A
Correct Answer:
A.
Explanation:
1. Passwordless sign-in \(\rightarrow \) Microsoft Authenticator.
Why it is correct: Microsoft Authenticator enables full passwordless authentication via phone sign-in. It allows
users to authenticate using biometric data (face or fingerprint) or a PIN, completely eliminating the
vulnerability of traditional passwords.
Why others are incorrect: Hardware OATH tokens, SMS, and Voice calls are legacy multi-factor
authentication (MFA) mechanisms. They require a primary password first before entering the verification code.
2. First-time sign-in for new users \(\rightarrow \) Temporary Access Pass.
Why it is correct: A Temporary Access Pass (TAP) is a time-limited passcode configured by administrators. It
serves as a secure onboarding standard that allows new hires to log in for the very first time and register their
passwordless methods without needing a permanent password.
Why others are incorrect: Standard methods like SMS, Voice, or Authenticator cannot be used for an initial
new-user sign-in because those authentication methods must first be registered inside the account by an
already logged-in user.
You have a Microsoft Entra tenant that has user consent for applications disabled.
You register an application named App1 that requests the following Microsoft Graph delegated permissions:
User.Read -
Mail.Read -
You need to configure tenant permissions to meet the following requirements:
Enable users to grant consent for low-risk permissions without administrator interaction.
Ensure that applications requesting higher-privilege permissions require administrator approval.
What should you do?
A
Grant tenant-wide admin consent to App1.
B
Configure application assignments for App1.
C
Configure Privileged Identity Management (PIM) role assignments.
D
Create an app consent policy.
Correct Answer:
D. Create an app consent policy.
Explanation:
Technical Justification for Correct Answer: D
Requirements Recap:
Why D (Create an App Consent Policy) is the Correct Answer:
1. Enable user consent for low-risk permissions (e.g., User.Read, Mail.Read) without administrator
interaction.
2. Ensure higher-privilege permissions require administrator approval.
Why Other Options are Less Suitable:
Meets Requirement 1: An app consent policy allows you to specify which permissions can be consented to by
users without administrator intervention, aligning with the need for user consent on low-risk permissions like
User.Read and Mail.Read.
Meets Requirement 2: The same policy can be configured to require administrator consent for higher
privilege permissions, ensuring an additional security layer for more sensitive access.
Precision and Flexibility: App consent policies provide a targeted approach to managing consent workflows
based on permission types, making it the most suitable choice for the specified requirements.
A. Grant Tenant-Wide Admin Consent to App1
Overly Broad: Grants admin consent for all requested permissions, bypassing the requirement for user
consent on low-risk permissions and not distinguishing between permission risks.
Security Risk: Automatically approves higher-privilege permissions without the desired administrator review.
B. Configure Application Assignments for App1
Purpose Misalignment: Application assignments are more about controlling access to the app itself rather
than managing permission consent flows.
Does Not Address Consent Requirements: Fails to differentiate between user and admin consent needs
based on permission risk.
C. Configure Privileged Identity Management (PIM) Role Assignments
Scope Misalignment: PIM is designed for managing access to privileged roles, not for controlling application
permission consent flows.
References
Indirect Approach: Does not directly address the requirements for user vs. admin consent based on
permission type.
Microsoft Documentation: App Consent Policies
https://learn.microsoft.com/en-us/azure/active-directory/develop/app-consent-policies
Microsoft Graph Permissions Reference
https://learn.microsoft.com/en-us/graph/permissions-reference
You have an Azure management group named MG1 that contains two subscriptions named Sub1 and Sub2. Both
subscriptions are linked to a Microsoft Entra tenant that contains a security group named Group1.
You need to ensure that the members of Group1 can assign roles to the resources in Sub1 and Sub2. The solution
must follow the principle of least privilege.
Which role should you assign to Group1?
A
Contributor at the MG1 scope
B
Contributor at the Sub1 and Sub2 scopes
C
User Access Administrator at the MG1 scope
D
Owner at the MG1 scope
Correct Answer:
C. User Access Administrator at the MG1 scope
Explanation:
Technical Justification for Correct Answer (C)
Why C (User Access Administrator at the MG1 scope) is the best option:Assigning the User Access
Administrator role to Group1 at the MG1 scope is the most appropriate choice for several technical reasons
aligned with the principle of least privilege:
Scope Alignment: Assigning the role at the MG1 scope ensures that the permissions are applied uniformly
across all resources within both Sub1 and Sub2, which are contained within MG1, without needing to manage
permissions at each subscription individually.
Least Privilege: The User Access Administrator role is specifically designed for managing user access,
allowing Group1 to assign roles to others without granting unnecessary permissions for creating, modifying, or
deleting resources (which roles like Contributor or Owner would provide).
Role Purpose: This role directly supports the requirement to assign roles to resources, fitting the need
precisely without over-privileging.
Why other options are less suitable:
A. Contributor at the MG1 scope:
Over-Privilege: Grants the ability to manage resources, which is not required for the task of assigning roles.
Scope: While the scope is correct for unified management, the role itself does not follow the principle of least
privilege for the specified task.
B. Contributor at the Sub1 and Sub2 scopes:
D. Owner at the MG1 scope:
Management Overhead: Requires managing permissions at each subscription level, increasing administrative
complexity.
Over-Privilege (same as A): Allows resource management, deviating from the principle of least privilege.
Significant Over-Privilege: Provides full control over resources, drastically exceeding the permissions needed
for role assignment.
Security Risk: Introduces a higher security risk due to the broad permissions granted.
DRAG DROP -
You have an Azure key vault named KV1 that uses role-based access control (RBAC) for data plane authorization.
You have a user named User1 and an Azure App Service web app named App1 that has a system-assigned managed
identity.
You need to configure authorization to meet the following requirements:
App1 must be able to retrieve secrets from KV1.
User1 must manage the KV1 settings without accessing secret values.
The solution must follow the principle of least privilege.
Which role should you assign to each identity for KV1? To answer, drag the appropriate roles to the correct
identities. Each role may be used once, more than once, or not at all. You may need to drag the split bar between
panes or scroll to view content.
NOTE: Each correct selection is worth one point.
A
Correct Answer:
A.
Explanation:
User1 \(\rightarrow \) Key Vault Administrator.
Why it is correct: The Key Vault Administrator role provides complete data plane management rights across
all keys, secrets, and certificates within Azure Key Vault. It grants User1 full authorization to assign Azure
role-based access control (RBAC) permissions to other corporate identities, manage metadata, and modify full
security profiles.
App1 \(\rightarrow \) Key Vault Secrets User.
powers to delete or modify them.
Why others are incorrect:
Why it is correct: The Key Vault Secrets User role is a restricted, read-only data plane role. It follows the
security principle of Least Privilege by allowing automated background workloads (like applications or
managed identities) to retrieve (Get) and list secret values securely without granting them administrative
Key Vault Contributor only permits management of the Key Vault resource itself via the management plane
(such as changing resource tags or deleting the vault), but completely blocks data plane object modifications
(like reading or altering secrets). Key Vault Secrets Officer only manages secrets and cannot manage
permissions or cryptographic keys.
Giving App1 the Key Vault Secrets Officer or Key Vault Administrator role would introduce massive security
flaws by over-provisioning a service identity with write or full administrative administrative permissions it does
not require.
Questions: 1-10 out of 129
Continue Full Practice..
GET ALL 129 QUESTIONS