← SC-300: identity, access, and operations
13 / 13 · 60 MIN

Workload identities: risk, policies, and containment

Investigate application identities, check policy scope, and coordinate remediation with consumer evidence.

Start with the object that actually authenticates

For a reconciliation application, keep tenant, client ID, registration Object ID, and service principal Object ID in separate inventory fields. The name Funds-Batch might appear in production and staging; it is insufficient to select an identity. Suppose the ticket requests protection for sp-prod while the configuration references app-object-test. Resolve that mapping with the owner before debating thresholds. Enterprise applications shows the local representation. Use this distinction to verify policy selection and correlate logs. A well-formed identifier can still identify the wrong object. Also record consuming resources and who can authorize changes. This makes support handover actionable when the original project engineer is unavailable.

Separate detection coverage from control coverage

An alert can identify suspicious activity without proving that a policy prevented access. Here, detection can cover third-party multitenant applications, while the workload identities policy supports single-tenant service principals registered in the tenant. Managed identities are outside these documented scopes. In our exercise, the coverage matrix has three columns: available signal, applicable control, and observed effect. A row with detection but no applicable control needs a different response rather than a green mark. The project team should identify the gap owner and the supported mechanism to rehearse at the resource or integration. Lack of support in this feature does not demonstrate lack of risk.

Build a change that RUN can accept

For this mechanism, select the service principal directly: membership in a targeted group is insufficient. The available control is Block access; an unattended batch cannot complete user MFA. Report-only observes the predicted decision without applying that block. In the NAT-change example, the job finishes but observation predicts failure outside the approved range. Job success alone therefore cannot justify enabling enforcement. The plan needs approved traffic, a controlled negative test, stop criteria, and rollback ownership. Also confirm editing capability: loss of Workload Identities Premium does not turn existing policies off, although it prevents creating or modifying these policies. Record the operational consequence before scheduling the change.

Investigate changes without confusing coincidence with cause

The shift receives three fictional timestamps: NAT changed at 21:00, credential added at 21:03, and alert at 21:05. The first change was approved; the second remains unexplained. Correlate the principal, resources, actors, and administrative events, preserving references for the next team. A behavioral alert should not be reduced to the last visible sign-in. Look for grants, configuration changes, and vault access that could widen impact. The network ticket supports a hypothesis for the different IP but does not legitimize all nearby activity. Communicate facts, hypotheses, and authorized actions separately. Closure needs evidence supporting the chosen explanation and treatment of the remaining observations.

Rotate credentials and follow dependencies

In the guided case, the team installed a new certificate and the batch ran. The exposed credential remains valid: the result confirms the new path but does not close the old one. Inventory credentials on relevant objects and address compromised-credential removal through authorized containment. Then follow dependencies: if the principal could read a vault password, exposure can extend to the service accepting that password. Coordinate rotation with consumers and confirm the outcome. Keep secrets out of the report. Use version identifiers, owners, outcomes, and pending work. Dismiss risk records a risk decision; it should not be presented as a substitute for technical remediation of credentials and access.

Bound what the CAE pilot demonstrates

Documented workload identity CAE support is limited to Microsoft Graph and supported identity types. The client declares cp1 and must handle claims challenges rather than indefinitely repeating the same token. In our design, the daemon calls Graph and a custom reconciliation API. The Graph pilot does not establish the custom API behavior. Acceptance records should separate both consumers, their session or token mechanisms, and collected evidence. A configured library or log field is part of investigation, not a rehearsal of every flow. Validate authorized failure and recovery behavior on each path before promising universal continuous revocation. The project report should make these boundaries clear to application and operations owners.

Local exercise on policy selection and mode

The local model in this lesson receives synthetic data: identity type, identifier, direct selection, mode, and risk level. For a supported directly selected principal with matching risk and mode On, it returns block. In Report-only it returns would-block. With group-only selection, it returns not-targeted. These results describe only the exercise simplified policy. No-match does not authorize global access. The model rejects unknown data, does not interpret tokens, and does not query Entra. Locations, exclusions, other policies, licensing, and consumer mechanisms are omitted. Predict each result before execution and explain which real evidence would still be needed to accept the same design in an authorized lab tenant.

Hand evidence and responsibility to the next shift

Write the credential-leak handover in four parts: affected identity, observed containment, untreated dependencies, and the next decision point. A useful example states that the new certificate works, the exposed credential was removed, but the dependent-service password awaits rotation coordinated with the DBA and two consumers. Add log and change references, expected impact, and the owner deadline. Do not close the incident merely because batch authentication recovered. This workshop trains decisions and synthetic models; it performs no Azure changes. Cases are fictional and do not describe the procedures of an institution. Specialist review and rehearsal in an isolated tenant remain necessary before treating a production design as validated.

IN PRACTICE

Fictional inventory: appId=app-17, applicationObjectId=app-object-8, servicePrincipalObjectId=sp-object-3. Group selection does not protect the batch through this policy; correct direct selection still needs observed conditions, mode, and outcome.

Common pitfalls

Alert as block evidence; group as direct selection; registration Object ID as principal; new certificate as old-credential removal; Graph success as revocation across every API.

Related topics: Application identities · Conditional Access · Incident management

Take this idea with you

Identify the correct principal, check coverage and mode, follow each exposure to consumers, and distinguish observation, containment, and remediation.

Create account

Reference: Conditional Access for workload identities · SC-300 objectives effective 2026-04-27; product documentation reviewed 2026-10-01; 2026-10-28 English update compared separately

Microsoft is a trademark of the Microsoft group of companies. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by Microsoft. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.