Hands-on preparation for SC-300 should make identity state and policy evaluation visible. The exam expects candidates to implement and troubleshoot users, devices, hybrid identity, strong authentication, Conditional Access, risk, workload identities, enterprise applications, privileged access, governance, logs, and KQL. A useful lab therefore reuses one Microsoft Entra tenant and introduces controlled changes rather than treating every objective as a separate demo.
Use the current SC-300 blueprint as the boundary. The goal is not to configure every Microsoft Entra feature available in the portal. It is to understand the exact current objectives well enough that you can predict access, create a failure, inspect evidence, and restore the intended state.
Lab one: build a delegated administration model
Create several test users and groups, then assign built-in or custom roles with different scopes. If your lab permits it, use administrative units to limit delegated administration. Test what each administrator can and cannot change.
Record effective permissions rather than trusting the role name. A role that sounds narrow can still have broad effect at tenant scope. The lab should teach the difference between role capability and assignment scope.
Lab two: run a joiner, mover, and leaver lifecycle
Create a new user, assign groups, licenses, and a registered or joined device. Then simulate a role change by altering attributes and group membership. Finally, disable the account, revoke sessions, remove access, and reclaim licenses.
Use the same user in later Conditional Access and application labs. This makes lifecycle changes visible downstream and demonstrates why identity administration cannot be separated from access policy.
Lab three: test external collaboration and cross-tenant controls
Invite an external user and document the guest lifecycle. If you have access to two tenants, test cross-tenant settings or synchronization. If not, at least design the expected ownership and trust relationships.
Experiment with an external identity provider only if your environment supports it. The important skill is identifying which tenant authenticates, which tenant authorizes, and who is responsible for removing access when collaboration ends.
Lab four: compare authentication methods and recovery paths
Configure several methods such as Microsoft Authenticator, FIDO2 or passkeys, Temporary Access Pass, certificate-based authentication where possible, and SSPR. Test enrollment and recovery. Disable or revoke a method and observe the user’s next sign-in.
The lab should show that strong authentication includes bootstrapping and recovery. A method that is secure but impossible to recover operationally can create support failures.
Lab five: create and troubleshoot Conditional Access safely
Build policies using test users, report-only mode, exclusions, and staged rollout. Combine assignments and controls such as MFA, authentication strength, device conditions, session restrictions, or protected actions. The Conditional Access material can reinforce policy logic.
Then create a policy conflict or unexpected block and use sign-in logs to understand the evaluation. The lab succeeds when you can identify which policy applied and why, not merely when the user eventually signs in.
Lab six: simulate risk and investigate the response
Where your tenant and licensing allow, inspect risky users, risky sign-ins, and Identity Protection policies. Practice the administrative workflow even if generating real risk is impractical. Review remediation options and how risk can be consumed by Conditional Access.
Add a registration campaign or stronger-method requirement to show how identity protection and authentication readiness interact. Risk policy is useful only if users can satisfy the required remediation.
Lab seven: create a workload identity and remove its secret dependency
Create an app registration or service principal and grant a narrowly scoped permission. Then, for a supported Azure resource, configure a managed identity and compare the authentication model. Observe which credentials or tokens the workload needs.
Keep the permissions minimal. The value of workload identity is reduced if the service principal or managed identity receives tenant-wide access for convenience. Practice diagnosing “authentication succeeded but API access failed” as a permission problem rather than a credential problem.
Lab eight: integrate an enterprise application and inspect consent
Add or configure an enterprise application, assign users or groups, review app roles, and inspect user or admin consent. If possible, test Application Proxy or SaaS SSO. Create a failure where the user is authenticated but unassigned or lacks the required app role.
This reinforces the distinction between directory identity and application authorization. A successful Entra sign-in is not proof that every application will grant access.
Lab nine: exercise entitlement management, access reviews, and PIM
Create an access package or model its components: catalog, resources, request policy, approval, expiration, and review. Configure an access review and inspect the result. Then use PIM for a role, Azure resource, or group where available, including activation, approval, duration, and audit history.
Add a break-glass account design and make sure normal Conditional Access testing never removes the emergency path. This is where Zero Trust and operational resilience meet.
Lab ten: reconstruct an incident from logs and KQL
Send diagnostics to Log Analytics if your lab supports it. Use sign-in, audit, and provisioning logs to reconstruct a failed access event or configuration change. Write simple KQL queries to narrow by user, application, result, or time range.
Before the first configuration change, create a tenant baseline. Record test users, group memberships, role assignments, enabled authentication methods, Conditional Access policies, enterprise applications, and diagnostic settings. This makes later failures easier to interpret because you know what changed. A lab without a baseline can teach bad habits if the environment already contains hidden policies or inherited assignments.
Add a session-revocation exercise. Sign in as a test user, then disable the account or revoke sessions and observe the difference between existing and new access. If continuous access evaluation is in scope for the application, note whether the session responds immediately or at a later token event. This turns “revoke user sessions” from a menu option into an operational behavior.
Add one consent exercise to the application lab. Request a delegated or application permission, observe the user or admin consent path, and then remove or modify consent. Compare this with simple user assignment. The two controls solve different problems: assignment controls who may use the application, while consent controls what permission the application is authorized to exercise.
Where Global Secure Access licensing and lab access are available, create a narrow test that distinguishes Private Access from Internet Access. If the feature cannot be configured in the lab, at least design the identity, client, policy, and target flow on paper and identify what telemetry you would need to prove the path. The objective is conceptual and operational understanding, not ownership of a large network test environment.
Add a governance cleanup drill. Create a temporary entitlement or privileged assignment with an expiration, then verify that access disappears at the expected point and that the event is recorded. Time-bound access is only useful if the lifecycle actually closes without manual cleanup.
Finish by exporting or documenting the evidence for one successful and one failed sign-in. Include authentication method, Conditional Access status, application, device or client context, risk if present, and final result. The ability to narrate a sign-in from evidence is one of the best hands-on indicators of SC-300 readiness.
Add a hybrid-identity tabletop exercise even if the lab lacks on-premises Active Directory. Draw the Connect Sync or Cloud Sync path, authentication choice, health monitoring, and failure dependencies. Simulate an attribute change that is edited in the wrong source and predict what synchronization will do. This keeps source-of-authority reasoning in the hands-on plan.
Add an Application Proxy design exercise for an on-premises web application. Identify connector placement, application registration, assignment, authentication method, Conditional Access, and external reachability. Then contrast it with a SaaS enterprise application. The lab can be partly conceptual as long as the identity and access path is explicit.
Add one risky workload identity case. Create or model a service principal with broader permission than necessary, then reduce its scope and document the intended API or Azure resource calls. The exercise reinforces that workload identities need the same least-privilege discipline as human administrators.
Add one Defender for Cloud Apps tabletop. Start with cloud discovery, classify an application as sanctioned or risky, then decide whether access policy, session policy, OAuth-app policy, or application-enforced restrictions fit the scenario. The purpose is to understand control placement even if the full licensing stack is unavailable in the lab.
Finally, keep a rollback plan for every Conditional Access and privileged-access lab. Write which emergency account remains available, how the test user can be recovered, and which change can be reverted first. Identity labs can lock administrators out, so safe-change discipline is part of the technical exercise.
Use a test naming convention so lab identities, applications, groups, and policies are easy to recognize in logs. Clean up after each exercise and verify that temporary role assignments, guest accounts, app permissions, and policies are removed. Identity labs can leave behind broad access if cleanup is treated as optional.
Add a small PowerShell exercise for bulk identity work. Create or modify several test users or groups through scriptable administration, then compare the resulting audit evidence with portal-based changes. The objective is not advanced scripting; it is understanding that repeatable identity operations can be automated and audited.
Record each lab result with the exact user, device, application, policy, and time so the corresponding log evidence can be found later without guessing.
Use the same documentation to confirm cleanup after the exercise.
Finish by creating a short incident timeline: identity state, authentication, Conditional Access, application assignment, risk, privileged activity, and the final fix. The broader SC-300 preparation context is useful, but the most valuable hands-on skill is being able to prove why access succeeded or failed.