Design identity, governance, and monitoring solutions
Identity, Access, and Secret-Management Design
CoreSeparate authentication, identity lifecycle, resource authorization, hybrid access, and secret custody when designing least-privilege solutions.
Aligned to the current AZ-305 study guide, skills measured as of April 17, 2026, verified August 25, 2026.
Why this matters
Identity is the preferred security perimeter, but a sound design still distinguishes who proves identity, who manages the identity, which plane authorizes the action, and where credentials are held.
Must Know
- Keep identity verification in Microsoft Entra ID distinct from permission enforcement through Azure RBAC.
- For workload access, favor managed identities or federated credentials over application-held secrets.
- Choose between hybrid identity and managed domain services according to the existing directory and domain-protocol requirements.
- Apply resource roles at the narrowest durable scope, and keep Key Vault administration separate from access to protected material.
Compare and Distinguish
- Microsoft Entra ID authenticates cloud identities; Azure RBAC authorizes Azure resource operations at a scope.
- Managed identities remove application credential handling for supported Azure resources; workload identity federation avoids stored secrets for external workloads.
- Microsoft Entra Domain Services supplies managed domain capabilities, while hybrid identity synchronizes or federates existing identities.
Scenario examples
- Scenario: An Azure-hosted application needs Storage access without credentials in configuration. Think: managed identity plus a narrow data-plane role.
- Scenario: An external CI system needs short-lived Azure access. Think: workload identity federation rather than a client secret.
- Scenario: Branch applications must continue using Kerberos against managed domain controllers. Think: design the appropriate hybrid or managed-domain boundary, not Azure RBAC.
Exam traps
- Authentication success does not imply resource authorization.
- Contributor cannot assign roles merely because it can manage resources.
- Key Vault is not useful if applications still copy secrets into deployment variables.
Key takeaways
- Design authentication, lifecycle, authorization, and secret custody as separate decisions.
- Prefer identities and short-lived tokens over stored credentials.
- Assign the least privilege at the narrowest durable scope.
How it works
- After Microsoft Entra ID authenticates a principal, a resource request carries a token; Azure RBAC evaluates the principal, role definition, and assignment scope before the resource permits an authorized operation.
- A managed identity obtains Microsoft Entra tokens without an application-managed credential, but the target resource still enforces its assigned control-plane actions or data-plane data actions.
- Key Vault receives authenticated requests at the vault endpoint and applies the configured authorization model before allowing secret retrieval or cryptographic operations; applications can use keys without exporting the key material.
Objects and administrative surfaces
- Tenant and Conditional Access scope govern sign-in decisions.
- Management group, subscription, resource group, resource, and data-plane scopes govern Azure RBAC decisions.
- Azure Key Vault separates vault management from access to keys, secrets, and certificates.
When to use it
- Use managed identity for supported Azure-hosted workloads and federation for supported external workloads that need short-lived Azure access.
- Use Key Vault when secrets, keys, or certificates require centralized custody, rotation, or nonexportable cryptographic operations.
- Use hybrid identity or managed domain services only when the existing directory and required domain protocols make that boundary necessary.
Security and governance implications
- Assign resource and data roles at the smallest durable scope, separating vault administration from access to protected material.
- Apply Conditional Access and strong authentication to governed users while preventing applications from copying secrets into deployment variables.
How to validate and revise the design
- For an authorization failure, inspect the token audience, principal, role definition, assignment scope, inheritance, DataActions, and deny assignments.
- For secret access, trace managed identity token acquisition, network reachability, vault authorization model, object permission, and current secret version.
More detail
- A management-plane role on a resource does not automatically grant access to its stored data; exam scenarios often turn on whether the required permission appears in Actions or DataActions.
- Effective RBAC access can come from several assignments and nested group memberships, so adding a narrower assignment does not subtract permissions granted at a broader inherited scope.
- Conditional Access governs the conditions under which sign-in tokens are issued, while resource roles and Key Vault data permissions still decide what an authenticated identity can do.
Ready for the quiz?
- Which system authenticates the principal, and which separate control authorizes the requested resource or data operation?
- Can the workload obtain a short-lived identity instead of storing a secret, and what target permission must still be assigned?
- Does the scenario require hybrid identity, managed domain protocols, resource roles, or protected secret and key custody?
Related objectives
- D1.2.S1 — Recommend an authentication solution
- D1.2.S2 — Recommend an identity management solution
- D1.2.S3 — Recommend a solution for authorizing access to Azure resources
- D1.2.S4 — Recommend a solution for authorizing access to on-premises resources
- D1.2.S5 — Recommend a solution to manage secrets, certificates, and keys