Design security operations, identity, and compliance capabilities
Identity and Access Architecture
CoreDesign a Zero Trust identity plane for people, partners, workloads, and agents across cloud, SaaS, on-premises, and multicloud resources, with modern policy signals and protected secrets.
Aligned to SC-100 skills measured as of October 21, 2026; candidates testing earlier should review the transition note in the lane overview.
Why this matters
Identity is a control plane for every other plane. The architect must distinguish identity types, authentication contexts, resource enforcement points, network dependencies, lifecycle governance, and the failure modes of legacy directories and credentials.
Must Know
- Microsoft Entra Agent ID gives AI agents purpose-built identities, blueprints, sponsors, logging, governance, and agent-aware protection instead of disguising autonomous agents as people.
- Conditional Access policies for agent identities, workload identities, and users have different targeting and signal capabilities; design from the principal and token flow actually used.
- An enterprise access design combines identity policy, network reachability, application authorization, and resource-native controls across SaaS, PaaS, IaaS, private, and other-cloud targets.
- Hybrid identity requires protected synchronization or federation dependencies, resilient authentication, emergency access, and clear authority for identities and attributes.
- Modern authorization uses least privilege, strong authentication, risk signals, continuous access evaluation where supported, authentication context for protected actions, and session controls.
- AD DS hardening prioritizes tier-zero assets, administrative separation, protocol reduction, patching, monitoring, recoverability, and removal of unnecessary privilege.
- Secrets, keys, and certificates require authoritative inventory, managed identities where possible, protected stores, scoped access, rotation, expiry monitoring, recovery, and separation of duties.
Compare and Distinguish
- Agent identities represent AI agents with agent-specific lifecycle and policy; workload identities represent applications or services; user identities represent people and should not be shared with automation.
- Conditional Access decides whether a token request may proceed under evaluated conditions; application and resource authorization still decide what the token can do.
Scenario examples
- Scenario: Autonomous agents need distinct accountability and must be blocked when risky. Think: use Entra Agent ID, sponsors, least privilege, agent logging, and Conditional Access based on agent risk.
- Scenario: A partner needs one application without broad tenant access. Think: use governed B2B access, cross-tenant settings, application assignment, Conditional Access, and recurring lifecycle review.
Exam traps
- Naming a human user account after an agent does not provide agent-specific discovery, governance, or protection.
- A network allowlist cannot replace identity and application authorization for hybrid resources.
Key takeaways
- Trace the principal and token to the policy and resource that actually enforce access.
- Users, partners, workloads, and agents require distinct identity lifecycles.
- Remove a stored credential when a managed or federated identity can carry the trust.
How it works
- The identity provider issues tokens after authentication and policy evaluation; applications and resources enforce scopes, roles, claims, and network conditions.
- Agent blueprints provide a scalable identity pattern while individual agent identities preserve instance-level accountability.
Objects and administrative surfaces
- Agent identity blueprints, agent identities, sponsors, app registrations, service principals, managed identities, users, groups, external identities, and Conditional Access policies.
- AD DS forests and privileged groups, synchronization components, Key Vaults, managed HSMs, certificates, secret inventories, and protected actions.
When to use it
- Use this architecture whenever multiple actor types and resource planes must share one explicit trust model.
Security and governance implications
- Assign owners and sponsors, prohibit identity sharing, monitor exceptions, and make deprovisioning part of every identity lifecycle.
Troubleshooting signals
- If a policy appears bypassed, trace the principal type, token flow, target resource, exclusions, and actual enforcement support.
- If credential rotation breaks workloads, verify version references, overlap windows, dependency inventory, and rollback ownership.
More detail
- Select agent, workload, human, and external identity patterns correctly.
- Validate Conditional Access coverage against real access paths and exclusions.
- Design directory hardening and credential management as enterprise control-plane safeguards.
Ready for the quiz?
- Which policy signals apply to an autonomous agent rather than its sponsor?
- Where is authorization enforced after Conditional Access grants a token?
- What makes an AD DS dependency part of the cloud identity threat model?
Related objectives
- D2.2.S1 — Design a solution for agent identities using Microsoft Entra Agent ID and conditional access policies
- D2.2.S2 — Design a solution for access to software as a service (SaaS), platform as a service (PaaS), infrastructure as a service (IaaS), hybrid/on-premises, and multicloud resources, including identity, networking, and application controls
- D2.2.S3 — Design a solution for Microsoft Entra ID, including hybrid and multi-cloud environments
- D2.2.S4 — Design a solution for external identities, including business-to-business (B2B) and decentralized identity
- D2.2.S5 — Design a modern authentication and authorization strategy, including Conditional Access, continuous access evaluation, risk scoring, and protected actions
- D2.2.S6 — Validate the alignment of Conditional Access policies with a Zero Trust strategy
- D2.2.S7 — Specify requirements to harden Active Directory Domain Services (AD DS)
- D2.2.S8 — Design a solution to manage secrets, keys, and certificates