Troubleshooting SC-300 is about locating the first incorrect identity or access state. A user-visible symptom such as “I cannot access the app” can be caused by directory state, authentication method, Conditional Access, risk, device compliance, application assignment, consent, a workload identity, governance, or session control. Randomly editing policies is dangerous because it can widen access while hiding the original cause.
The current SC-300 blueprint explicitly includes testing and troubleshooting Conditional Access, investigating risk, monitoring applications, PIM audit history, sign-in and audit logs, provisioning logs, Log Analytics, KQL, workbooks, and reporting. Those objectives make evidence-led diagnosis a core exam skill.
Start every investigation with scope and the last known working state
Determine whether the issue affects one user, one group, one device, one application, one tenant, or many users. Ask whether the failure began after a policy, application, group, sync, or authentication change. Scope narrows the likely layer before you open any log.
A single user’s failure after device replacement suggests a different path from every external user failing after a cross-tenant configuration change. Time and scope are diagnostic evidence, not administrative trivia.
If sign-in fails, separate identity existence from authentication method
Confirm the account is enabled, the correct tenant is being used, the user can satisfy the configured authentication method, and the account or session has not been revoked. Check passkey, certificate, Microsoft Authenticator, SSPR, Temporary Access Pass, or Windows Hello state as relevant.
Do not assume MFA is the only authentication control. A certificate can fail validation, a passkey can be unavailable on the new device, or a user may need a Temporary Access Pass to bootstrap a strong method.
If authentication succeeds but access fails, inspect Conditional Access next
Sign-in logs show Conditional Access evaluation and policy outcomes. Review assignments, controls, authentication strength, device requirements, risk, session settings, authentication context, and protected actions. The Conditional Access perspective is useful, but the log should tell you which policy actually affected the sign-in.
Test changes safely. Report-only analysis, pilot groups, exclusions, and emergency access are operational safeguards. Never “fix” a policy problem by broadly excluding users without understanding why the intended policy produced the result.
If the problem is intermittent, check risk and continuous evaluation
User risk, sign-in risk, risky workload identities, and continuous access evaluation can change the access outcome as conditions change. A session that was originally valid may be revoked or challenged later.
Correlate risk events with sign-in timing and remediation. A user’s complaint that “it worked this morning” can be meaningful if a new risk detection or session revocation occurred after the earlier successful access.
If only one application fails, move from tenant policy to app-specific authorization
Check enterprise-application assignment, app roles, user/admin consent, API permissions, SSO settings, Application Proxy, and application-level configuration. The identity can be healthy while the application is misconfigured or the user is simply not authorized.
If Defender for Cloud Apps is involved, check connected-app state, app control, access/session policies, OAuth-app policy, or application-enforced restrictions. Successful authentication does not prove the session is unrestricted.
If a workload fails, distinguish credential failure from resource authorization
Managed identities and service principals can authenticate correctly while lacking the target resource permission. App registrations can have valid credentials but missing API permissions or admin consent. Troubleshoot token acquisition and authorization separately.
This prevents a common operational mistake: rotating or replacing credentials when the real problem is access scope. Least privilege is easier to maintain when engineers know which permission is actually missing.
If hybrid users are wrong, check source of authority and synchronization health
For synchronized identities, inspect Connect Sync or Cloud Sync, source attributes, password-hash or pass-through authentication configuration, seamless SSO, and Connect Health. An attribute edited in the cloud may be overwritten if the source remains on premises.
The troubleshooting question is “where should this value be changed?” before “which portal should I use?” Hybrid identity remains manageable when source and sync path are explicit.
If external collaboration fails, inspect both trust and lifecycle settings
Guest invitation, external collaboration settings, cross-tenant access, cross-tenant synchronization, external identity providers, terms of use, entitlement policies, and connected organizations can all affect external users.
Check whether the user exists, whether the home tenant or identity provider authenticated correctly, whether the resource tenant accepts the trust, and whether the entitlement is still active. External access crosses administrative boundaries, so one tenant’s “healthy” view is not enough.
If privilege or entitlement is missing, inspect governance before granting access manually
PIM eligibility, activation rules, approval, duration, group configuration, access-package policy, expiration, and access-review decisions may explain why access is not active. Bypassing those controls with a direct permanent assignment can solve the immediate symptom while defeating governance.
The right fix preserves the intended lifecycle. If a review removed access correctly, the solution may be a new request rather than undoing the review. If PIM activation failed, fix the activation condition instead of assigning the role permanently.
Use KQL and audit evidence to reconstruct what changed
Send diagnostics to Log Analytics and query sign-in, audit, or provisioning data by time, user, app, result, or operation. Workbooks can reveal patterns, while raw logs can show exact events. Identity Secure Score can highlight posture opportunities but does not replace incident-specific evidence.
Keep a troubleshooting matrix that maps symptom to evidence source. “User cannot sign in” points first to identity and sign-in logs; “account did not provision” points to provisioning logs; “role disappeared” points to audit or PIM history; “user can sign in but app blocks access” points to Conditional Access, application assignment, consent, or session control. Choosing the correct evidence source early saves time.
Be cautious with caching and propagation assumptions. Directory changes, policy updates, token issuance, group membership, and application behavior do not always become visible to every component at the same instant. Before declaring a configuration wrong, understand whether the expected change requires a new token, a new sign-in, synchronization, or another lifecycle event.
For Conditional Access, distinguish “not applied,” “applied and satisfied,” and “applied and failed.” A policy that does not apply may indicate a scope or condition mismatch, while a failed policy indicates the user matched but could not satisfy a grant or session requirement. Those states lead to different corrections.
For application access, use consent and assignment history as evidence when a recent configuration change is suspected. Removing admin consent, changing an app role, or altering group assignment can break access without changing the user’s authentication experience. The timing of the application change can be more relevant than the user’s password or MFA method.
For privileged access, inspect whether the user is eligible, active, approved, within the activation window, and meeting activation conditions such as MFA or justification. PIM failures are often workflow-state problems rather than missing role definitions. The audit trail should show which stage stopped.
After every fix, retest the original failing path with the original user, device, application, and context. A simpler success test may prove only that some access exists, not that the intended policy now behaves correctly. Troubleshooting is complete when the original business requirement is restored without weakening unrelated controls.
Add device identity to the matrix. Device join or registration state, client type, and policy conditions can change an access outcome even when the user and password are unchanged. Compare a working managed-device sign-in with a failing unmanaged-device sign-in and look for the first policy condition that differs.
For Global Secure Access incidents, separate identity policy from network-path health. Confirm the client is deployed, the user is targeted, the correct Private or Internet Access profile applies, and the destination is part of the intended policy. A sign-in log may explain identity evaluation while separate product telemetry explains traffic forwarding.
For consent incidents, verify whether the application requests delegated or application permissions, whether consent was granted at the required level, and whether the tenant blocks or restricts user consent. A consent error can look like application misconfiguration even when redirect URIs and credentials are correct.
For access reviews and entitlement issues, use history to distinguish deliberate removal from technical failure. If access expired according to policy or a reviewer denied continued access, the correct action is a new governed request or policy change—not an emergency direct assignment that bypasses the lifecycle.
Build a post-incident step into troubleshooting. After restoring access, ask whether the design needs a monitoring alert, safer deployment process, clearer ownership, stronger documentation, or narrower permission. Good identity operations reduce the chance that the same failure returns.
Keep emergency recovery separate from normal troubleshooting. If a policy has locked out ordinary administrators, the priority may be restoring control through the protected emergency path before investigating the root cause. Once administrative access is stable, analyze the policy and evidence rather than leaving the emergency account as the permanent workaround.
For cross-tenant failures, record which side owns each setting. Home-tenant authentication, resource-tenant cross-tenant access, synchronization, enterprise-application assignment, and entitlement can all influence the final result. Troubleshooting is faster when responsibility is mapped before logs are collected.
A strong final habit is to write the root cause in one sentence after every practice incident. If the sentence cannot identify the exact identity, policy, permission, or lifecycle state that failed, the investigation probably stopped at a symptom rather than the cause.
That precision is what makes the repair repeatable and auditable.
Recheck the original failing workflow after the fix.
That confirms recovery.
Verify it fully.
The broader Microsoft security, compliance, and identity foundation helps explain why identity matters across security, but SC-300 troubleshooting must stay operational. The strongest diagnosis names the layer, proves the cause with evidence, makes the smallest safe correction, and verifies the original access path.