LEARN. PRACTICE. GROW.1. Design the lifecycle before assigning permissions
A reconciliation application can have several instances, deployment slots and environments with different change schedules. The identity it uses to call another service is part of that architecture. A system-assigned identity follows the lifecycle of its containing resource. A user-assigned identity is an independent resource that can be associated with several compatible resources. Independence lets permissions be prepared before compute replacement, but also requires deciding who can attach the identity and when it should be removed. Do not choose solely by the number of identities to create. Record who shares permissions, who can assume that identity through a workload and which team responds if an instance is compromised. Removing compute alone does not demonstrate withdrawal of an independent identity.
2. Separate token acquisition from operation authorization
Managed identity removes application-managed credentials for obtaining supported tokens. It does not automatically grant target access. A valid token for the right resource still needs operation authorization and the necessary network path. In a fictional exercise, an application obtains a token but is denied secret access: confirm the effective identity, audience, grant scope and vault access model. If the service has multiple user-assigned identities, explicitly select the intended one through supported client configuration. The service identity is also not the identity of every end user invoking the application. Record that distinction in auditing so that an operation performed under the workload principal is not attributed to an individual merely because that person triggered the request.
3. Model Key Vault permissions by plane
Key Vault separates resource management from operations on secrets, keys and certificates. Under Azure RBAC, administering the vault does not imply reading secret values. Key Vault Reader allows metadata observation without revealing contents; Key Vault Secrets User permits secret reading within its assigned scope. Choose the least capability meeting the use case rather than grant data administration where only reading is needed. For vaults still using access policies, a principal with sufficient management permissions can change those policies and grant itself access. This difference matters when reviewing separation of duties. Current documentation makes Azure RBAC the default for new vaults starting with API 2026-02-01; confirm the actual model in every existing vault and deployment template.
4. Treat propagation and withdrawal as operational requirements
A group change must not be presented as instant managed-identity revocation. Infrastructure caches tokens and membership changes can take hours to appear; the documented mechanism does not allow forced early refresh. Direct identity assignments can avoid dependency on group claims, but do not promise zero delay for every authorization mechanism. Define the business-required withdrawal deadline and authorized containment at the destination resource or application. Deleting an identity prevents new tokens being obtained, but issued tokens can remain valid until expiry depending on destination checks. A rehearsal should include an existing consumer and a new attempt, distinguishing authentication, authorization and actual ability to access the protected resource. Record the residual-access window and who owns its mitigation.
5. Recover the vault and rebuild dependencies
Soft delete and purge protection address different risks. Soft delete retains deleted resources during retention; purge protection prevents early purging while that protection applies. The team needs to know who can recover, the configured period and which operations cannot be reversed simply at an administrator’s request. Recovering a vault does not automatically rebuild every integration. Recovery documentation requires checking, among other dependencies, Azure RBAC assignments and Event Grid subscriptions deleted with the vault. Acceptance must go beyond the vault reappearing in the portal. Test authorized application reads, denial for an unprivileged principal and required event delivery. Keep real secrets out of exercise examples and reports. Recovery is a service-level responsibility spanning more than the restored resource.
6. Hand production a verifiable matrix
Prepare a matrix of principal, operation, scope, authorization model, owner and expected outcome. Add network dependencies and revocation or recovery criteria. The local model below evaluates only a fictional matrix: it separates metadata permissions from secret reading and preserves explicit denials. It does not interpret Azure RBAC, inheritance, deny assignments, tokens or real conditions. Use it to discuss tests needed before cutover rather than declare a subscription secure. During a vault-loss rehearsal, an application can authenticate correctly yet fail because a grant was not restored. RUN should be able to identify that distinction without granting the application Owner as a generic troubleshooting attempt. Also record how temporary recovery access will be removed once normal operation returns.
grants = {
("funds-worker", "vault-a"): {"secret.read"},
("platform-reader", "vault-a"): {"metadata.read"},
}
def permitted(principal, vault, operation):
return operation in grants.get((principal, vault), set)
assert permitted("funds-worker", "vault-a", "secret.read")
assert not permitted("platform-reader", "vault-a", "secret.read")
assert permitted("platform-reader", "vault-a", "metadata.read")
assert not permitted("funds-worker", "vault-b", "secret.read")
assert not permitted("funds-worker", "vault-a", "roles.assign")
print("five fictional access-contract checks passed; no Azure RBAC evaluation")
Fictional case: a funds application vault was recovered and its endpoint responds. The application still cannot read its secret. The team compares principal, scope and grants with the previous inventory, restores only required access and also tests a principal that must remain denied.
Common pitfalls
Confusing a token with permission; treating vault management as data reading; assuming instant group-based revocation; recovering the resource without its authorizations and integrations.
Related topics: Least privilege · Secrets and certificates · Operational recovery
Identity reduces credential management, but access and recovery contracts still need design and evidence.
Reference: Managed identities overview · AZ-305 objectives 2026-04-17