{"id":3020,"date":"2026-10-08T12:09:15","date_gmt":"2026-10-08T12:09:15","guid":{"rendered":"https:\/\/www.examtopics.biz\/blog\/microsoft-az-305-azure-key-vault-architecture\/"},"modified":"2026-10-17T10:56:19","modified_gmt":"2026-10-17T10:56:19","slug":"microsoft-az-305-azure-key-vault-architecture","status":"publish","type":"post","link":"https:\/\/www.examtopics.biz\/blog\/microsoft-az-305-azure-key-vault-architecture\/","title":{"rendered":"Microsoft AZ-305: Azure Key Vault Architecture"},"content":{"rendered":"<p>Azure Key Vault removes sensitive cryptographic material from application code, configuration files, and deployment scripts, but a secure design requires more than creating a vault and uploading a few secrets. Architects must decide <strong>what belongs in the vault, how workloads authenticate, how authorization is scoped, how the network path is restricted, and how accidental or malicious deletion is handled<\/strong>.<\/p>\n<p>Those decisions matter in the current AZ-305 domain because Key Vault sits at the intersection of identity, application security, encryption, networking, and operational recovery. A vault can be technically reachable and still be poorly designed if applications use long-lived credentials, administrators have excessive data-plane access, public access is unnecessarily open, or recovery controls are missing.<\/p>\n<p>The best architecture treats Key Vault as protected infrastructure with its own trust boundary rather than as a convenient database for sensitive strings.<\/p>\n<h2>Match the object type to the operation<\/h2>\n<p>Key Vault stores three main object types: secrets, keys, and certificates. They are related but not interchangeable.<\/p>\n<p><strong>Secrets<\/strong> are opaque values such as passwords, connection strings, API tokens, or other sensitive configuration. An application normally retrieves a secret and then presents that value to another system.<\/p>\n<p><strong>Keys<\/strong> are cryptographic keys used for operations such as encryption, decryption, signing, verification, wrapping, and unwrapping. A key can remain inside the service while the application asks Key Vault to perform a cryptographic operation, which can reduce exposure of the key material itself.<\/p>\n<p><strong>Certificates<\/strong> add certificate lifecycle and management capabilities around public-key certificates. They are appropriate when workloads need TLS or other certificate-based identity rather than a generic secret value.<\/p>\n<p>The object distinction should shape authorization. A workload that reads one application secret does not automatically need permission to create certificates, rotate keys, or enumerate every object in the vault. Grant the smallest set of operations that supports the workload.<\/p>\n<h2>Authenticate with Microsoft Entra ID, preferably through managed identity<\/h2>\n<p>Key Vault uses Microsoft Entra ID to authenticate callers. Azure-hosted applications should normally avoid storing a separate credential merely to authenticate to the system that protects their credentials.<\/p>\n<p><a href=\"https:\/\/www.examtopics.biz\/blog\/microsoft-sc-300-managed-identities-vs-service-principals\/\">Managed identities<\/a> solve that circular dependency. An Azure resource such as a VM, App Service app, Function, or other supported service can obtain an Entra token without embedding a client secret in code or configuration. The application then presents that token to Key Vault and receives access only if authorization allows the requested operation.<\/p>\n<p>This design reduces several operational risks:<\/p>\n<ul>\n<li>no application password needs to be copied into a deployment pipeline<\/li>\n<li>no long-lived secret needs periodic manual rotation just for Key Vault authentication<\/li>\n<li>credential leakage in source control becomes less likely<\/li>\n<li>identity lifecycle follows the Azure resource more closely<\/li>\n<\/ul>\n<p>There are still cases where a service principal or certificate-based application identity is necessary, particularly outside Azure. The architecture should then minimize credential lifetime, protect the bootstrap credential carefully, and prefer certificate or federated approaches over static client secrets where practical.<\/p>\n<p>Infrastructure definitions also create a secret-handling boundary. <a href=\"https:\/\/www.examtopics.biz\/blog\/how-to-store-and-manage-secrets-safely-in-terraform-infrastructure\/\">Secret management in Terraform<\/a> must account for state, plan output, provider logs and the identity used to retrieve a value\u2014not just whether a credential appears in a source-code repository. Restrict access to the state backend and rotate exposed values; masking a console output does not remove a secret already stored in state.<\/p>\n<h2>Use Azure RBAC for new data-plane designs<\/h2>\n<p>Key Vault has historically supported both vault access policies and Azure role-based access control for data-plane authorization. Microsoft now recommends Azure RBAC for improved security and centralized permission management, while access policies are considered a legacy authorization model.<\/p>\n<p>This is an important 2026 design detail: when a new vault is created through <a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/key-vault\/general\/access-control-default\" rel=\"nofollow\">Key Vault API version 2026-02-01<\/a> or later, Azure RBAC is the default access-control model unless the caller explicitly selects access policies. Existing vaults keep their configured model unless the authorization setting is explicitly changed; simply using the newer API to update an existing vault does not migrate permissions.<\/p>\n<p>Azure RBAC helps separate the ability to manage a vault resource from the ability to read or manipulate secrets, keys, and certificates. Built-in roles can grant data-plane permissions without giving broad control-plane rights. The same boundary applies to <a href=\"https:\/\/www.examtopics.biz\/blog\/microsoft-sc-500-key-vault-rbac-secrets-rotation\/\">Key Vault RBAC and secret rotation<\/a>: a rotation service needs carefully scoped object operations, not permission to assign itself broader roles.<\/p>\n<p>The architecture should distinguish roles such as:<\/p>\n<ul>\n<li>platform administrators who configure networking and vault settings<\/li>\n<li>security administrators who manage access assignments<\/li>\n<li>applications that read a limited set of secret or cryptographic material<\/li>\n<li>certificate automation systems that require lifecycle operations<\/li>\n<li>auditors who need metadata or logs without secret values<\/li>\n<\/ul>\n<p>That separation is especially important with legacy access policies. A principal with permission to write Key Vault configuration, including some Contributor-level roles, can potentially grant itself data-plane access by modifying an access policy. With Azure RBAC-managed data-plane permissions, ordinary Contributor rights do not themselves grant permission to read secrets; role-assignment authority must be controlled and reviewed separately.<\/p>\n<h2>Decide vault boundaries deliberately<\/h2>\n<p>A common design question is whether to place everything in one vault or create multiple vaults.<\/p>\n<p>One very large vault can be simple to discover, but it also increases blast radius and makes authorization boundaries harder to reason about. Multiple vaults can align better with application, environment, subscription, region, regulatory, or administrative boundaries.<\/p>\n<p>Useful reasons for separate vaults include:<\/p>\n<ul>\n<li>production and nonproduction require different administrators<\/li>\n<li>a regulated workload needs stricter network and retention controls<\/li>\n<li>different applications should not share a data-plane permission boundary<\/li>\n<li>regional deployment patterns require local dependencies<\/li>\n<li>operational ownership is split across teams<\/li>\n<\/ul>\n<p>Do not create a vault per secret merely to maximize isolation. That creates management overhead without necessarily improving the threat model. The vault boundary should correspond to a meaningful security or operational boundary.<\/p>\n<h2>Restrict the network path as well as the identity path<\/h2>\n<p>Identity authorization remains mandatory even when network controls are present, but reducing network exposure adds defense in depth.<\/p>\n<p>Key Vault can be restricted with firewall rules, virtual network service endpoints, or Azure Private Link. For sensitive production designs, a private endpoint is often the strongest model because the vault can be reached through a private IP in the virtual network while public network access is disabled.<\/p>\n<p>Private endpoint architecture introduces a DNS requirement. The application must resolve the Key Vault service name to the correct private endpoint address from the networks that should use the private path. A private endpoint that exists but is paired with incorrect DNS can create confusing failures in which the identity and permissions are correct but the workload still reaches the public endpoint or cannot resolve the vault as intended.<\/p>\n<p>Network restrictions also need to account for deployment pipelines, break-glass administration, backup processes, and managed Azure services that legitimately require access. \u201cDisable public access\u201d is a strong control only when every required management and application path has been designed first.<\/p>\n<p>The authorization design also needs to separate the control plane from the data plane.<\/p>\n<p>Key Vault has two distinct security surfaces.<\/p>\n<p>The <strong>control plane<\/strong> manages the Azure resource: creating the vault, configuring networking, setting tags, enabling diagnostic settings, or changing certain resource properties.<\/p>\n<p>The <strong>data plane<\/strong> handles protected objects: reading a secret, signing with a key, importing a certificate, or listing keys.<\/p>\n<p>An architect should review these planes independently. A platform operator might need to configure private endpoints without needing to read secret values. An application might need to read one secret while having no permission to change vault networking or deletion settings.<\/p>\n<p>This separation is especially important during incident response. If one account can change permissions, disable protections, and retrieve every protected object, compromise of that account has a much larger impact.<\/p>\n<h2>Design for rotation and versioning<\/h2>\n<p>Key Vault maintains versions of secret, key, and certificate objects. Versioning is useful during rotation because applications can move to a new value while a previous version remains available for controlled rollback or transition.<\/p>\n<p>However, automatic rotation is not the same as application-safe rotation. A system must still answer questions such as:<\/p>\n<ul>\n<li>Can the downstream service accept two credentials during transition?<\/li>\n<li>Does the application cache the secret, and for how long?<\/li>\n<li>Will rotation trigger a restart or configuration reload?<\/li>\n<li>What happens if the new credential is rejected?<\/li>\n<li>How quickly can an exposed credential be revoked?<\/li>\n<\/ul>\n<p>For cryptographic keys, rotation policy must also consider existing encrypted data. Rotating a key used for new operations does not automatically re-encrypt all historical data. Applications need a strategy for identifying which key version protects which data and for preserving old versions as long as decryption requires them.<\/p>\n<h2>Protect against deletion and destructive administration<\/h2>\n<p>A secure vault must be recoverable from operational mistakes and resistant to intentional destruction.<\/p>\n<p>Soft delete allows deleted vaults and objects to remain recoverable for a configured retention period. Purge protection goes further by preventing permanent purge during that retention period. Microsoft recommends these controls because backups and data-plane security are not sufficient if an attacker with high privilege can simply destroy the vault and every object in it.<\/p>\n<p>Purge protection is especially important for encryption scenarios. If a key is permanently lost while data still depends on it, the data may effectively become unrecoverable.<\/p>\n<p>The design should therefore treat deletion protection as part of availability and ransomware resilience, not merely as an administrative convenience.<\/p>\n<h2>Monitor access and administrative change<\/h2>\n<p>Key Vault should participate in the same evidence architecture as other sensitive Azure services. Diagnostic settings can export audit and resource logs for investigation, alerting, and retention.<\/p>\n<p>Monitoring should make it possible to investigate events such as:<\/p>\n<ul>\n<li>unexpected secret reads<\/li>\n<li>repeated authorization failures<\/li>\n<li>permission changes<\/li>\n<li>firewall or public-access changes<\/li>\n<li>object deletion or recovery<\/li>\n<li>unusual certificate or key operations<\/li>\n<\/ul>\n<p>The logs are most valuable when they are routed to a destination that administrators of the protected workload cannot casually erase. Security evidence should not depend entirely on the same trust boundary it is meant to audit.<\/p>\n<h2>Build the vault around a clear trust model<\/h2>\n<p>A robust Key Vault architecture can be reviewed as a sequence of controls:<\/p>\n<ol>\n<li>Store only the secrets, keys, and certificates that belong in the vault.<\/li>\n<li>Give every workload a clear Microsoft Entra identity.<\/li>\n<li>Prefer managed identities for Azure-hosted workloads.<\/li>\n<li>Use Azure RBAC for new data-plane authorization and scope permissions narrowly.<\/li>\n<li>Choose vault boundaries that reflect real security and ownership boundaries.<\/li>\n<li>Restrict public network exposure when private connectivity is practical.<\/li>\n<li>Design private DNS together with private endpoints.<\/li>\n<li>Plan rotation, versioning, rollback, and dependency behavior.<\/li>\n<li>Enable soft delete and purge protection for destructive-event resilience.<\/li>\n<li>Export audit evidence to a protected monitoring destination.<\/li>\n<\/ol>\n<p>Key Vault protection comes from controls acting together: workload identity, authorization, network reachability, object lifecycle, and recovery. An independent <a href=\"https:\/\/www.examtopics.biz\/az-305\">AZ-305 Key Vault case<\/a> should test those boundaries together. A client may possess the right identity yet fail because the network path is blocked; an authorized workload may still become unusable when a deleted key cannot be recovered. Neither outcome is solved by assigning broader permissions.<\/p>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>Azure Key Vault removes sensitive cryptographic material from application code, configuration files, and deployment scripts, but a secure design requires more than creating a vault [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[125,29,30,47],"tags":[],"class_list":["post-3020","post","type-post","status-publish","format-standard","hentry","category-exam-az-305","category-certifications","category-cloud-computing","category-microsoft-certifications"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3020","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/comments?post=3020"}],"version-history":[{"count":2,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3020\/revisions"}],"predecessor-version":[{"id":4719,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3020\/revisions\/4719"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=3020"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=3020"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=3020"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}