Microsoft SC-300: Hands-On Identity Exercises

Microsoft SC-300 is best rehearsed by building access paths that cross identity, authentication, authorization, applications, workload identities, Conditional Access, governance, and monitoring. Practical work should produce evidence and troubleshooting decisions, not just screenshots showing that a setting exists.

Microsoft SC-300 remains current as of October 6, 2026. Microsoft’s current English blueprint is dated April 27, with a published update effective October 28. Use the pre-update scope until then and re-check the official guide for any lab you publish or use after the change date.

Build identities and authentication assurance

Hybrid identity should be tested with a failure that occurs before and after synchronization. A source attribute error, delayed synchronization, authentication failure, and Conditional Access denial can all look like ‘the user cannot access the app.’ The exercise should prove that you can tell those states apart from the available evidence.

Create users, groups, administrative units, devices, external identities, and role assignments for a small organization with two departments and delegated support. Document source of authority, object owner, lifecycle trigger, license or assignment dependency, and the audit evidence created by each administrative action.

The exercise is successful when the directory structure explains access responsibility rather than merely containing objects.

Configure or model synchronization for one on-premises identity and trace attribute flow, authentication, health monitoring, and failure handling. Break one dependency conceptually—source attribute, synchronization, authentication path, or health state—and write the evidence that would locate the fault.

This separates synchronization from sign-in and prevents hybrid identity from becoming a single vague topic. Vary identity types deliberately.

Design authentication for ordinary staff, privileged administrators, onboarding users, and a high-risk sign-in using passwordless methods, MFA, authentication strengths, or recovery controls. For each case, state why the assurance level is appropriate and how a user safely recovers when the primary method is unavailable.

The objective is controlled assurance, not maximum friction.

Control application and contextual access

Application exercises should distinguish app registration, enterprise application, service principal, consent, assignment, app roles, and downstream resource authorization. A successful sign-in is only one stage of the access path; the lab should show where permission is actually enforced.

Exercise 4: design Conditional Access safely

SC-300 Conditional Access design should be practiced with policies for unmanaged devices, risky sign-ins, privileged administration, and sensitive applications. Run them in report-only mode, inspect overlapping conditions and exclusions, and predict the effective result before enforcement so policy composition remains understandable.

A safe design includes emergency access and a troubleshooting path for unexpected denials.

Exercise 5: integrate an enterprise application

Model SSO, assignment, consent, app roles, delegated versus application permissions, and administrative ownership for one SaaS app or custom application. Explain how a user is authenticated, how the application is authorized, which tenant object represents it, and how excessive permissions are reviewed.

The exercise should reveal whether you truly understand the difference between app registration, enterprise application, and the resource being accessed. A useful exercise 5: integrate an enterprise application summary therefore records why the choice fits the SC-300 identity-lab requirement and which assumption would trigger a redesign.

Include one consent and assignment mistake in the application lab. A user can authenticate successfully while the enterprise application is unassigned, the tenant has not granted the required consent, or the downstream API rejects the token. Trace those states separately so application access is not reduced to a single sign-in result.

Secure workload identities and governance

Workload identities need their own exercises because interactive-user assumptions do not always apply. Compare a service principal with a managed identity, review permission scope, rotate or remove a credential, and inspect sign-in or audit evidence. The goal is to understand how non-human access is governed and recovered.

Repeat at least one exercise with a different identity type. A control that behaves sensibly for a workforce user may need a different pattern for a guest, service principal, or managed identity. That comparison exposes whether you understand the identity model or only memorized one user-centric configuration path.

Identity exercises should include ownership and cleanup from the beginning. Create a workforce user, a guest, and a workload identity, then record who owns each object, what event should update it, and what event should remove it. Stale objects are easier to prevent when lifecycle is part of the original design.

Exercise 6: replace a reusable workload credential

For an Azure-hosted workload, compare a client secret with a managed identity and redesign the access path where the hosting model supports it. Record identity creation, permission assignment, scope, deployment dependency, monitoring, and what recovery looks like if access fails.

The goal is not simply ‘managed identity is better’; it is to understand why removing reusable secrets changes the risk model.

Exercise 7: govern time-limited access

Create an access package or equivalent governance model for a contractor who needs an application for a limited project and an administrator who needs temporary privilege. Define request, approval, assignment, expiration, review, extension, revocation, and external-user cleanup.

This connects governance to lifecycle instead of treating access reviews as an isolated feature.

Governance exercises should include time. Give a contractor access for a limited project and an administrator just-in-time privilege. Then simulate project end, role change, or missed review. The control should remove or challenge access without relying on manual memory.

Troubleshoot and connect neighboring roles

Troubleshooting exercises should begin with evidence rather than configuration. Use sign-in logs, audit logs, provisioning state, policy evaluation, and application assignment to locate the first state that differs from expectation. Restoring access without understanding the failure does not complete the exercise.

Keep a lab evidence folder rather than a screenshot folder. Save the sign-in result, policy evaluation, audit event, assignment state, provisioning result, or KQL output that proves the expected behavior. For each artifact, write one sentence explaining what it confirms and what it cannot confirm. That habit turns practical work into troubleshooting skill instead of a record that you successfully followed instructions once.

Document the lab evidence in a way another administrator can inspect: sign-in result, audit event, assignment state, consent, provisioning result, or policy evaluation. Screenshots of settings are weaker than evidence showing how the identity path actually behaved.

An access investigation should end with a clear ownership decision. If authentication and Conditional Access succeeded but the application rejects the action, the next step may belong to application authorization rather than identity policy. If suspicious behavior appears, the evidence may need to move to security operations. SC-300 depth includes knowing where the identity administrator should stop.

Preserve the evidence before changing access.

End the lab set with one access failure that crosses identity, application, and security boundaries. Confirm source identity and provisioning, authenticate the actor, inspect Conditional Access, verify application assignment and consent, then check downstream resource authorization. If the technical path is correct but suspicious activity remains, hand the evidence to security operations instead of weakening identity policy. The exercise is complete when you can identify the first incorrect state and the team that owns the next decision.

Exercise 8: investigate an access failure

Start with a user who cannot access an application. Use sign-in, audit, provisioning, risk, policy, and assignment evidence to find the first state that differs from expectation. Work from identity state through authentication, Conditional Access, application assignment, authorization, and resource access rather than changing settings randomly.

The evidence trail is the lab outcome; a restored login without diagnosis is not enough.

Exercise 9: connect SC-300 to neighboring roles

A useful final exercise gives the identity administrator, security operations analyst, and cybersecurity architect different responsibilities inside the same risk. The Microsoft cloud security certification path helps mark those handoffs, but the lab should still show which evidence each role produces and consumes.

The final exercise is successful when each role can act on the evidence produced by the others without duplicating ownership.

After completing the exercises individually, combine them into one tenant storyline. Onboard a hybrid user, assign an enterprise application, require stronger authentication, apply Conditional Access, grant time-limited privileged access, and then investigate a failed sign-in. The value of the integrated scenario is that each control produces state consumed by the next one. It becomes much easier to see where authentication ends, authorization begins, and governance closes the lifecycle.

External collaboration should include cleanup. Add a guest or cross-tenant user, grant application access, then simulate project completion. Review sponsorship, membership, access packages, sign-in activity, and removal. A collaboration design is incomplete if access has no defined end condition.

Permission exercises should include over-privilege as well as missing access. Grant an application or administrator a role that is broader than necessary, identify the reachable actions, then reduce the scope while preserving required behavior. That exercise makes least privilege measurable instead of a slogan.

Finish one lab by removing the identity or application cleanly. Revoke access, remove credentials or assignments, verify dependent services, and check audit evidence. Decommissioning is part of identity administration because abandoned objects and permissions are long-lived attack surface.

For each lab, note which tenant object or policy owns the final decision. That single sentence keeps identity, application, and resource authorization from collapsing into one generic access concept.