A hospital runs a public appointment API, a batch billing job, and an administrator portal across separate Azure subscriptions. All three call a database, and the security team wants to eliminate password strings from deployment files. The proposed fix is to put every password in Key Vault and give each application team broad read access. That protects the original config file but creates a new shared authorization risk. An architect must separate who the workload is, which secret or key it may access, what network path reaches the vault, and how recovery works when a credential rotates.
Microsoft AZ-305 evaluates authentication, authorization, identity governance, and designs for keys, secrets, and certificates. This article focuses on workload identity and cryptographic boundaries rather than the broad tenant model already covered by multi-tenant application identity. Human sign-in, managed workload credentials, vault access, and key lifecycle are related design layers that cannot be replaced by one administrator role.
Name every principal and sensitive operation
Draw a principal-to-resource matrix for the API, billing worker, administrator, CI/CD service, and emergency responder. Include read-secret, encrypt, decrypt, rotate, delete, create certificate, and change access policy separately. The appointment API may require a database credential during migration; it should not be allowed to disable the vault’s deletion protection or list unrelated application secrets. Resource-graph and subscription ownership belong in the same decision record.
Distinguish Microsoft Entra authentication from Azure resource authorization. A token identifying an application does not mean that application can access a vault, blob, or SQL endpoint. Consider Azure RBAC, relevant resource data-plane roles, explicit denies or policy constraints, and the resource’s networking controls. A 403 can be the correct denial even when identity authentication succeeded.
Prefer managed identities for Azure-hosted workloads
System-assigned managed identities are tied to the lifecycle of one supported Azure resource. User-assigned managed identities exist separately and can be associated with supported resources. Both help supported workloads obtain short-lived tokens without storing a static client secret in application code. The choice is operational: a one-to-one identity can be easy to clean up, while a separately managed identity may be useful for controlled lifecycle or shared responsibility across deployments.
Do not share one identity across unrelated tenants or services merely because it is convenient. A batch worker that performs payments should not inherit permissions needed by a public read-only API. Use distinct identities when they need different permissions, recovery ownership, or audit interpretation. Where Azure Workload Identity or supported federated credentials are appropriate, avoid replacing managed identity with a long-lived password in the build pipeline.
Design Key Vault as a distinct authorization boundary
Azure Key Vault stores secrets, keys, and certificates but they represent different operations. Reading a secret is not the same as requesting a cryptographic operation with a protected key; certificate lifecycle involves issuance, renewal, deployment, and trust. The Key Vault overview establishes the service model. Choose vault organization and access control from data sensitivity, tenancy, regional deployment, and administrative separation.
Use role assignments that grant the smallest required data-plane operations where the configured permissions model supports them. Separate human vault administrators from application data readers and from security auditors. Avoid giving deployment automation blanket permission to delete vaults or rotate every application key. A security policy that blocks public network access does not automatically make a secret unreadable to a compromised identity with privileged access.
Combine resource access with private network reachability
If workloads connect to vaults over private endpoints, design VNet routing, private DNS, endpoint approval, and network segmentation before denying public traffic. An endpoint that exists but resolves incorrectly can break application startup after a scaling event. Conversely, allowing any public source to reach the vault may violate a policy even when identity restrictions remain correct. Transport and authorization should reinforce one another rather than substitute for each other.
The hub-and-spoke networking design helps define shared-service access, but shared networking does not require a shared vault for every customer. Document how a workload in a spoke resolves the vault hostname and how a disaster-recovery deployment reaches the replacement service without granting an entire enterprise address range unrestricted access.
Handle rotation as an application transaction
A password rotation is incomplete if the target database is updated while a long-running application continues using a stale cached value. Document who initiates rotation, how both credentials remain usable or transition safely, which application instances refresh credentials, and how failures are detected. For API keys held at a partner service, you may need a two-key overlap or coordination with the partner; Key Vault cannot force that external system to update itself.
Prefer identity-based access to services such as Azure SQL where supported when the workload can avoid a password entirely. Secrets remain useful for integrations that still require them, but each dependency adds a rotation and recovery procedure. Test the actual client libraries and connection pools; an architecture that says “managed identity” but still starts from a connection string with an embedded secret has not met its requirement.
Design certificates for the complete TLS route
List every TLS termination point: customer browser, global edge, regional ingress, internal API, and database connection. Determine where certificates are managed, how renewal occurs, and which client trusts the issuer. An auto-renewed certificate in a vault does not prove the production gateway has loaded the renewed version. Application Gateway, Front Door, or an app host may have separate integration and propagation rules.
Use synthetic expiration exercises and health checks to prove the active listener serves the expected certificate. Test the hostname, expiration, and chain from both external and internal clients. Never “repair” trust failures by disabling certificate validation; instead find whether the problem is DNS, chain, listener binding, expired certificate, or workload runtime trust store.
Make deletion protection and recovery real
Protect critical keys and secrets from accidental or malicious deletion using available soft-delete, purge-protection, access control, and retention mechanisms aligned with policy. Do not present recovery of an encrypted database as complete until the restore identity can use the necessary encryption keys and secrets in the destination environment. Cross-region recovery may need independently planned key availability and authorization.
The paired-region disaster-recovery analysis examines application failover boundaries. Add the identity dependency to that plan: Can a service start in the recovery Region? Can it resolve and reach its vault? Can responders assume approved emergency access if federation is impaired? Does the old production identity still have a narrow permitted path? Rehearsing these answers is a security test, not just a continuity test.
Verify positive and negative identities in a controlled lab
Create two test workloads with different managed identities, two test secrets, and a constrained vault. Demonstrate that each workload can retrieve only its authorized secret. Attempt a forbidden read and record the denial without broadening the role. Rotate one credential and verify old application instances recover correctly. Next, change DNS or an endpoint rule in a nonproduction environment and confirm the observable symptom differs from an RBAC denial.
The final design should show who can authenticate, which exact operations each principal may perform, how private traffic reaches the resource, how credentials and certificates change, and how recovery happens if the normal identity provider or vault path fails. AZ-305 architecture is defensible when security controls remain precise during ordinary deployments, operational emergencies, and intentional negative tests.