12 real SC-300 sample questions, each with a worked explanation and a rationale for every option, right and wrong. No account, no card. This is the reasoning the SC-300 tests: knowing why the tempting answer is wrong, not just spotting the right one.
The real SC-300 is Typically 40 to 60 questions questions in 120 minutes, pass mark 700 / 1000. For a domain-by-domain breakdown and a study plan, read the SC-300 study guide. The full bank has 284 questions.
lock_openFree sampleImplement and Manage User Identitieshard
A company has three disconnected Active Directory forests acquired through mergers, each managed by a separate IT team, and wants to synchronise all of them to one Microsoft Entra tenant. The architecture team requires a lightweight, Microsoft-managed provisioning service that avoids deploying a full synchronisation server per forest. Which synchronisation technology meets this requirement?
- ADeploy Microsoft Entra Cloud Sync with a lightweight provisioning agent in each forest, because the service is Microsoft-managed and supports disconnected multi-forest topologies.check_circle Correct
- BDeploy Microsoft Entra Connect Sync on a server in each forest, because only the full sync engine can read objects from multiple disconnected Active Directory forests.
- CDeploy a single Microsoft Entra Connect Sync server with a custom rule set that reaches across all three disconnected forests over the public internet.
- DDeploy Microsoft Entra Connect Health agents in each forest, because the health service can provision identities from disconnected forests into the tenant.
Microsoft Entra Cloud Sync uses lightweight Microsoft-managed agents and is the preferred choice for synchronising disconnected multi-forest Active Directory environments. Cloud Sync places a lightweight provisioning agent in each forest and performs the synchronisation logic in a Microsoft-managed cloud service, so disconnected forests with no trust between them are supported without a full sync server per forest. Connect Sync requires a server and network reachability, and Connect Health only monitors.
Why A is correct: Cloud Sync uses lightweight agents that report to a Microsoft-managed cloud service and natively supports disconnected forests, matching the lightweight multi-forest requirement exactly.
Why B is wrong: Connect Sync can serve multiple forests, but it requires a full synchronisation server and is not the lightweight Microsoft-managed agent service the architecture team asked for.
Why C is wrong: Disconnected forests have no shared trust path for one Connect Sync server to reach them, and reaching across forests over the internet is not a supported synchronisation design.
Why D is wrong: Connect Health only monitors the health and performance of identity synchronisation; it does not provision or synchronise any directory objects into the tenant.
lock_openFree sampleImplement and Manage User Identitieshard
An organisation must let on-premises users sign in to Microsoft 365 with their Active Directory password, but a security mandate forbids any password hashes, even hashed twice, from being stored in the cloud. Authentication must succeed even if a single authentication agent is offline. Which sign-in method satisfies the mandate?
- AConfigure password hash synchronisation, because the synchronised hash is itself hashed again before upload, which the mandate treats as acceptable cloud storage.
- BConfigure pass-through authentication and install at least two authentication agents, because passwords are validated against on-premises Active Directory and no hashes are stored in the cloud.check_circle Correct
- CConfigure federation with Active Directory Federation Services as the only authority and rely on a single federation server for password validation.
- DConfigure seamless single sign-on with no other sign-in method, because Kerberos-based seamless single sign-on validates the Active Directory password without storing a hash.
Pass-through authentication validates passwords against on-premises Active Directory and stores no password hash in the cloud, with multiple agents giving high availability. Pass-through authentication uses on-premises agents to validate each sign-in against Active Directory in real time, so no password hash is ever placed in Microsoft Entra ID, and deploying additional agents removes the single point of failure. Password hash synchronisation uploads a credential, federation alone needs redundant servers, and seamless single sign-on is only a convenience feature.
Why A is wrong: Password hash synchronisation does upload a re-hashed credential into the cloud, which directly violates the mandate forbidding any password hashes from being stored in the cloud.
Why B is correct: Pass-through authentication validates each password directly against on-premises Active Directory and stores no password hash in Microsoft Entra ID, and multiple agents provide resilience if one is offline.
Why C is wrong: Federation keeps authentication on-premises, but a single federation server has no resilience, so it fails the requirement that authentication survive one component being offline.
Why D is wrong: Seamless single sign-on only removes the prompt on domain-joined devices; it is an add-on and cannot validate passwords on its own as a sign-in method.
lock_openFree sampleImplement and Manage User Identitieshard
A hybrid tenant already uses password hash synchronisation. Users on domain-joined corporate devices on the internal network must reach Microsoft 365 without typing their username and password again after their Windows sign-in, with no extra client software deployed. Which capability should the administrator enable to deliver this experience?
- AEnable pass-through authentication alongside password hash synchronisation, because switching the validation path automatically suppresses the cloud sign-in prompt for domain users.
- BEnable federation with Active Directory Federation Services, because redirecting authentication on-premises is the supported way to remove the prompt for internal devices.
- CEnable Microsoft Entra seamless single sign-on, because it uses Kerberos to silently authenticate domain-joined devices on the corporate network with no client software.check_circle Correct
- DDeploy a third-party single sign-on client to each corporate device so that the cached Windows credential is forwarded to Microsoft Entra ID during sign-in.
Seamless single sign-on uses Kerberos to silently authenticate domain-joined devices on the corporate network and pairs with password hash synchronisation or pass-through authentication. Seamless single sign-on creates a computer account that represents Microsoft Entra ID in Active Directory and uses Kerberos so corporate domain-joined devices obtain a token without re-entering credentials, needing no client deployment. It complements password hash synchronisation, whereas federation needs server infrastructure and a third-party client breaks the constraint.
Why A is wrong: Pass-through authentication changes where the password is validated; it does not by itself silently sign domain-joined users in, so the prompt would still appear.
Why B is wrong: Federation can provide single sign-on but requires a federation server farm and infrastructure, which exceeds the no-extra-software constraint and is heavier than needed.
Why C is correct: Seamless single sign-on issues Kerberos tickets for the Microsoft Entra service so domain-joined devices on the corporate network are signed in silently, with no client agent required.
Why D is wrong: Deploying a client agent to every device contradicts the requirement for no extra client software and is not the native Microsoft approach for this scenario.
lock_openFree sampleImplement Authentication and Access Managementhard
A finance team accesses a sensitive payroll web app. The security lead wants users to reauthenticate every hour while inside the app, without forcing reauthentication for any other application. Which Conditional Access configuration meets this requirement with the least administrative effort?
- ACreate a policy scoped to the payroll app and configure the sign-in frequency session control to a periodic value of one hour.check_circle Correct
- BCreate a policy targeting all cloud apps and set the sign-in frequency session control to one hour for every user in the tenant.
- CCreate a policy scoped to the payroll app and enable the persistent browser session control so the browser session expires after one hour.
- DCreate a policy scoped to the payroll app and set the grant control to require multi-factor authentication on every single sign-in event.
Sign-in frequency is the Conditional Access session control that forces periodic reauthentication, and it can be scoped to a single application. Sign-in frequency is a session control that defines how long a token is valid before the user must reauthenticate. Scoping the policy to the payroll app alone limits the hourly interval to that resource, whereas persistent browser session and grant controls address different problems.
Why A is correct: Scoping the policy to the single payroll app and using the sign-in frequency session control enforces hourly reauthentication only where required, satisfying the precise scope.
Why B is wrong: Targeting all cloud apps applies the hourly reauthentication far beyond the payroll app, which breaks the stated requirement to leave other applications untouched.
Why C is wrong: Persistent browser session controls whether cookies survive browser closure; it does not impose a periodic one-hour reauthentication interval inside an active session.
Why D is wrong: Requiring MFA defines the strength of a grant, not a timed reauthentication interval, so it does not deliver the hourly cadence the requirement specifies.
lock_openFree sampleImplement Authentication and Access Managementhard
An administrator must validate a new Conditional Access policy that blocks legacy authentication before enforcing it, so that no production sign-ins are interrupted while the impact is measured. Which approach captures the policy impact in sign-in logs without affecting users?
- ASet the policy state to On but exclude all users with a directory-wide exclusion group while reviewing the Microsoft Entra audit logs.
- BSet the policy state to report-only, then review the report-only result columns in the Microsoft Entra sign-in logs over several days.check_circle Correct
- CLeave the policy Off and instead model the outcome by running the What If tool repeatedly for each affected user account.
- DSet the policy state to On but apply it only to a small pilot group, then compare blocked counts in usage analytics dashboards.
Report-only mode evaluates a Conditional Access policy against live sign-ins and logs the result without enforcing any grant or block control. Report-only is a dedicated policy state that runs the full evaluation against real sign-ins and writes the would-be result into the sign-in logs, so administrators can size impact safely. Off performs no evaluation, and any On state enforces the control and disrupts users.
Why A is wrong: Excluding every user disables enforcement entirely and produces no evaluation results, so it cannot measure the realistic impact of the policy on production sign-ins.
Why B is correct: Report-only mode evaluates the policy and records what would have happened in the sign-in logs, giving impact data without blocking any user, which exactly fits the requirement.
Why C is wrong: The What If tool models a single hypothetical sign-in at a time and does not collect ongoing impact data from real traffic, so it does not measure live impact.
Why D is wrong: Turning the policy on actively blocks the pilot users, which contradicts the requirement that no sign-ins be interrupted during measurement.
lock_openFree sampleImplement Authentication and Access Managementhard
Company policy states that a particular line-of-business app may only be opened from corporate devices enrolled and marked compliant in Microsoft Intune. The security team also wants the simplest grant control that enforces device health. Which Conditional Access grant control should be applied to the app?
- ARequire multi-factor authentication, because verifying the user identity with a second factor confirms the request comes from a managed corporate device.
- BRequire approved client app, because only managed mobile applications can read the device compliance signal from Microsoft Intune at sign-in.
- CRequire the device to be marked as compliant, because this grant control checks the Microsoft Intune compliance state of the device during evaluation.check_circle Correct
- DRequire a named location match, because designating the corporate office network as a trusted location restricts the app to managed devices only.
The require device marked as compliant grant control evaluates the Microsoft Intune compliance state to limit access to managed, healthy devices. Device compliance is signalled by Microsoft Intune, and the require device marked as compliant grant control reads that signal during Conditional Access evaluation. MFA, approved client app, and named locations each test a different attribute and cannot enforce device compliance on their own.
Why A is wrong: MFA proves identity, not device state; a user can complete MFA from any personal device, so it does not restrict access to compliant corporate devices.
Why B is wrong: The approved client app control limits which applications may connect, but it does not evaluate whether the underlying device is marked compliant in Intune.
Why C is correct: Require device marked as compliant reads the Intune compliance status at sign-in and blocks access from non-compliant devices, directly meeting the corporate-device requirement.
Why D is wrong: A named location evaluates the network the request originates from, not the compliance state of the device, so an unmanaged device on that network would still pass.
lock_openFree samplePlan and Implement Workload Identitiesmedium
An Azure virtual machine runs a single application that must read secrets from Azure Key Vault without any credentials stored on the host. The identity team requires that the application's identity be created when the virtual machine is created and removed automatically when the virtual machine is deleted, with no separate object to clean up. Which workload identity should be configured on the virtual machine?
- AA system-assigned managed identity enabled directly on the virtual machine so its lifecycle is tied to the virtual machine resource.check_circle Correct
- BA user-assigned managed identity created in a resource group, then attached to the virtual machine so the application can request tokens for Key Vault.
- CAn app registration with a client secret stored in Key Vault, with the secret read by the application at start-up to authenticate.
- DA service principal created manually with a certificate credential, then referenced by the application running on the virtual machine.
A system-assigned managed identity is bound to a single Azure resource and is created and deleted automatically with that resource, requiring no managed credentials. A system-assigned managed identity is provisioned in Microsoft Entra ID directly on the Azure resource and shares its lifecycle: it appears when the resource is enabled and is removed when the resource is deleted. The platform rotates the underlying credential, so the application acquires tokens without any secret on disk. User-assigned identities, app registrations, and manual service principals all have independent lifecycles or managed credentials, so none satisfy the tie-to-the-resource and no-cleanup requirements.
Why A is correct: A system-assigned managed identity is created with the virtual machine and deleted automatically when the virtual machine is deleted, giving credential-free token access bound to that one resource's lifecycle.
Why B is wrong: A user-assigned managed identity has an independent lifecycle and is not deleted with the virtual machine, so it leaves a standalone object to clean up, which the requirement forbids.
Why C is wrong: An app registration relies on a client secret the team must manage and rotate, which contradicts the no-stored-credentials requirement and is not tied to the virtual machine lifecycle.
Why D is wrong: A manually created service principal with a certificate is an independent object whose credential and lifecycle must be maintained separately, so it is neither credential-free nor automatically removed with the virtual machine.
lock_openFree samplePlan and Implement Workload Identitiesmedium
A platform team runs a fleet of virtual machines and Azure Functions that must all authenticate to the same storage account and Azure SQL database with one identity, so that a single role assignment grants access to every workload. They also want to provision the identity and grant its permissions before any of the compute resources exist. Which workload identity meets these requirements?
- AA separate system-assigned managed identity enabled on each virtual machine and function, with the same role assignment repeated for every identity.
- BA single user-assigned managed identity created first, granted the required roles, then attached to each virtual machine and function.check_circle Correct
- CAn app registration shared across the workloads, with its client secret distributed to each virtual machine and function for authentication.
- DA workload identity federation trust on each function and virtual machine that maps to one external service principal in another tenant.
A user-assigned managed identity has an independent lifecycle, can be created before resources exist, and can be shared across many Azure resources with a single role assignment. A user-assigned managed identity is a standalone Microsoft Entra resource that lives independently of any compute. Because it exists on its own, it can be created and granted Azure role-based access control permissions before the virtual machines or functions are deployed, and the same identity can be attached to many resources. That lets one identity and one role assignment serve the whole fleet, which a per-resource system-assigned identity cannot do, and avoids the shared secret an app registration would require.
Why A is wrong: System-assigned identities are unique per resource and cannot be shared, so the team would manage many identities and many role assignments rather than one, and none can exist before its resource.
Why B is correct: A user-assigned managed identity is a standalone object that can be created and granted roles before any compute exists, then assigned to many resources so one identity and one role assignment cover the whole fleet.
Why C is wrong: An app registration can be shared, but distributing a client secret to every workload reintroduces credential management and rotation, which managed identities are designed to remove.
Why D is wrong: Workload identity federation establishes trust for external workloads to use a service principal without secrets, but it does not provide one shared Azure identity provisioned ahead of the compute resources for an internal fleet.
lock_openFree samplePlan and Implement Workload Identitiesmedium
A scheduled script runs on an on-premises server and must authenticate to a Microsoft Entra tenant to call an Azure resource. The identity team wants to avoid storing a long-lived client secret on the server and asks which workload identity approach is appropriate for a workload that does not run on an Azure resource. What should the team implement?
- AA system-assigned managed identity for the on-premises server, enabled from the Microsoft Entra admin centre against the server object.
- BA user-assigned managed identity created in Azure and then downloaded as a credential file that the on-premises script loads at start-up to authenticate.
- CAn app registration with a service principal that uses workload identity federation, so the on-premises workload exchanges a trusted external token for a Microsoft Entra token.check_circle Correct
- DAn app registration with a client secret stored in an encrypted file on the on-premises server and rotated by the script every ninety days.
Managed identities only serve Azure-hosted resources, so external workloads should use a service principal with workload identity federation to avoid stored secrets. Managed identities are issued only to resources running in Azure, so a workload on an on-premises server cannot use one. The secret-free pattern for an external workload is workload identity federation on an app registration: the workload obtains a token from a trusted external issuer and exchanges it for a Microsoft Entra token via the service principal. This removes the long-lived client secret while still giving the script an identity that can be granted access to the Azure resource.
Why A is wrong: Managed identities are available only for resources hosted in Azure, so a system-assigned managed identity cannot be enabled for an on-premises server and is not an option here.
Why B is wrong: Managed identity credentials are never exported; the platform manages them internally and they are usable only from Azure resources, so they cannot be downloaded to an on-premises host.
Why C is correct: Workload identity federation lets a non-Azure workload present a token from a trusted issuer and exchange it for a Microsoft Entra token, granting access through the service principal without any stored client secret.
Why D is wrong: This works but keeps a long-lived secret on the server, exactly the credential the team wants to avoid, so it does not meet the no-stored-secret goal even with rotation.
lock_openFree samplePlan and Automate Identity Governancemedium
A company has an access package for a sensitive finance application whose members are external guests. The governance team wants the guests themselves to attest each quarter that they still need access, and any guest who does not respond should automatically lose access. Which access review configuration meets this requirement?
- ACreate a recurring quarterly access review of the access package assignments, set the reviewer to users review their own access, and set the action to apply results so non-responders have access removed.check_circle Correct
- BCreate a recurring access review of the access package assignments, set the reviewer to group owners, and configure the action on completion to remove access for unreviewed members.
- CCreate a one-time access review of the finance application's enterprise application assignments, assign the application owner as reviewer, and notify guests by email to confirm their access.
- DCreate a recurring access review of the access package assignments, set the reviewer to a designated manager, and leave the action on completion set to no change so access is preserved.
Choosing users review their own access as the reviewer makes members self-attest, and applying results with removal handles non-responders automatically. An access review's reviewer setting decides who attests, and selecting users review their own access requires each member to confirm their own continued need. Combining this with a quarterly recurrence and an apply-results action that removes unreviewed access enforces self-attestation and automatically revokes access from guests who do not respond.
Why A is correct: Selecting users review their own access makes each guest attest to their own need, a quarterly recurrence matches the cadence, and applying results with removal for non-responders enforces loss of access for anyone who does not reply.
Why B is wrong: Group owners as reviewers would have the owners attest on behalf of the guests rather than the guests attesting for themselves, so this misses the self-attestation requirement even though the recurrence and removal action are right.
Why C is wrong: A one-time review does not repeat each quarter and an application owner is not the guest, so neither the recurrence nor the self-attestation requirement is satisfied despite reviewing the right resource.
Why D is wrong: A manager reviewing is not self-attestation, and an action of no change would never remove access from non-responders, so this fails both the attestation and the automatic removal requirements.
lock_openFree samplePlan and Automate Identity Governancemedium
An identity governance lead configures an access review for a privileged group and wants reviewers to see a system-generated suggestion next to each user indicating whether that user has signed in recently, so that stale accounts are easy to identify. Which access review feature provides this guidance?
- AEnable automatic apply results so the review uses each user's sign-in activity to remove inactive accounts without any reviewer having to make a decision at all.
- BEnable decision helpers so reviewers receive recommendations based on each user's sign-in activity, such as approve for recently active users and deny for users inactive for the configured period.check_circle Correct
- CEnable the require reason on approval setting so that reviewers must justify each approval, which prompts them to check whether the user has signed in recently.
- DEnable multi-stage review so a second reviewer can verify the first reviewer's decision against the user's recent sign-in history before access is finalised.
Decision helpers in access reviews give reviewers per-user approve or deny recommendations based on recent sign-in activity to flag stale accounts. Decision helpers analyse each user's sign-in activity over a defined window and present a recommendation, approving recently active users and recommending denial for inactive ones, directly beside the reviewer's decision. This guidance assists reviewers, unlike automatic apply results which enforce decisions, or settings that only require justification or add review stages.
Why A is wrong: Automatic apply results enforces the decisions after the review ends; it does not display a per-user recommendation for reviewers to consider during the review, so it does not provide the requested guidance.
Why B is correct: Decision helpers surface sign-in-activity recommendations beside each user, advising approval for recently active accounts and denial for inactive ones, which is exactly the stale-account guidance the lead wants.
Why C is wrong: Requiring a justification forces reviewers to type a reason but supplies no sign-in-based recommendation, so it nudges behaviour without giving the system-generated activity guidance described.
Why D is wrong: Multi-stage review adds an extra approval layer but does not generate any per-user sign-in recommendation, so reviewers still lack the inactivity suggestion the scenario asks for.
lock_openFree samplePlan and Automate Identity Governancemedium
A governance team created an access review for a group and selected the reviewers' manager as the reviewer. After the review starts, several users are not assigned a reviewer because their manager attribute in Microsoft Entra ID is empty. The team wants these orphaned users still to be reviewed by a named person rather than left unreviewed. Which setting addresses this?
- AChange the reviewer type to group owners, because group owners always receive any users whose manager attribute is not populated in the directory.
- BEnable automatic apply results so users without a manager have their access removed automatically when the review completes, clearing the orphaned entries.
- CConfigure a fallback reviewer on the access review so that users whose manager is not found are routed to that designated fallback reviewer instead of being left unassigned.check_circle Correct
- DExtend the review duration so that Microsoft Entra ID has additional time to populate the missing manager attribute and reassign the orphaned users automatically.
A fallback reviewer handles users whose manager attribute is empty when manager is chosen as the reviewer, preventing unassigned, unreviewed members. Manager-based reviewer assignment requires each user to have a populated manager attribute. A fallback reviewer is the designated backstop that receives any user whose manager cannot be determined, so those users are still reviewed. Changing reviewer type, applying results, or extending duration none of them route orphaned users to a named person.
Why A is wrong: Switching the reviewer type to group owners replaces manager-based assignment entirely rather than providing a backstop for missing managers, so it changes who reviews everyone instead of handling only the orphaned users.
Why B is wrong: Automatic apply results enforces decisions after the review but does not ensure orphaned users are reviewed by a person; it would act on a review that no one completed for them, which is not what the team wants.
Why C is correct: When the reviewer is set to manager, a fallback reviewer catches users whose manager attribute is empty and assigns those users to the named fallback, ensuring every user is reviewed by a person.
Why D is wrong: Extending the duration does not populate any manager attribute, because Microsoft Entra ID does not infer managers, so the orphaned users would remain unassigned no matter how long the review runs.
Examworthy is not affiliated with or endorsed by Microsoft. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. SC-300 and related marks belong to their respective owners.
