4 of the 10 questions we have for this objective, shown with the answer and the reasoning.
Secure secrets and keys by using Azure Key Vault
Fenwick Apps runs a web app named app-fenwick in Azure App Service with regional virtual network integration into a subnet named snet-app in vnet-hub. A Key Vault named kv-fenwick-prod is configured to allow public access from specific virtual networks and IP addresses only. The web app receives 403 Forbidden errors when it reads secrets. The security team wants to fix the error while keeping the vault reachable from the smallest possible set of sources and without deploying private endpoints.
What should you do?
- AEnable the Microsoft.KeyVault service endpoint on snet-app and add snet-app as an allowed virtual network in the kv-fenwick-prod firewall.With a service endpoint on the integrated subnet, the web app's outbound traffic to Key Vault carries the subnet identity, so a single virtual network rule admits exactly that subnet.
- BAdd all of the possible outbound IP addresses of app-fenwick to the kv-fenwick-prod firewall as allowed IP addresses.App Service outbound addresses are shared by other tenants' apps in the same scale unit and can change, so this admits far more than the web app and requires ongoing maintenance.
- CEnable the setting to allow trusted Microsoft services to bypass the kv-fenwick-prod firewall.App Service appears on the Key Vault trusted services list only for deploying App Service certificates from a vault; application code reading secrets is not covered by the bypass, so the web app would still receive 403.
- DChange the kv-fenwick-prod firewall to allow public access from all networks.Opening the vault to all networks resolves the error but removes the network boundary entirely, which contradicts the smallest-possible-set requirement.
Why: The Key Vault firewall can admit traffic by IP range, by virtual network subnet through service endpoints, or through the trusted-services bypass for a specific list of Microsoft services. The deciding constraints are the narrowest possible allow list and no private endpoints, which makes a service endpoint plus a virtual network rule for the integrated subnet the right fit. Adding App Service outbound IPs is a widely used shortcut that is both broader and brittle, and the trusted-services bypass is a trap because App Service is trusted only for deploying App Service certificates, not for application code reading secrets.
Secure secrets and keys by using Azure Key Vault
Verity Logistics has a Key Vault named kv-verity-prod that uses the Azure role-based access control permission model. An API named api-billing runs in Azure Container Apps with a system-assigned managed identity and must read the values of all secrets in the vault. It must not be able to create, modify, or delete secrets, and it does not need keys or certificates. The design must follow least privilege.
Which role should you assign to the managed identity, and at which scope?
- AKey Vault Secrets User at the kv-verity-prod scope.Key Vault Secrets User grants read access to secret contents and nothing more, and vault scope covers all current and future secrets without touching keys or certificates.
- BKey Vault Reader at the kv-verity-prod scope.Key Vault Reader can read vault metadata and list objects but cannot read secret values, so the API would fail to retrieve secrets.
- CKey Vault Secrets Officer at the kv-verity-prod scope.Secrets Officer can create, update, and delete secrets in addition to reading them, which exceeds the read-only requirement.
- DContributor at the resource group that contains kv-verity-prod.Contributor is a management-plane role; under the RBAC permission model it cannot read secret values at all, and it grants broad rights to every resource in the group.
Why: Under the Azure RBAC permission model, Key Vault data-plane access is granted through purpose-built roles that separate reading from managing and separate secrets, keys, and certificates. The deciding constraints are read-only access to secret values across the whole vault and least privilege, which is exactly Key Vault Secrets User at vault scope. Key Vault Reader is the most common trap because its name suggests reading data when it only exposes metadata, and Contributor is a management-plane role that cannot see secret contents when RBAC is in use.
Secure secrets and keys by using Azure Key Vault
Danforth Media stores an RSA key named key-sql-tde in a Key Vault named kv-dan-prod; the key is used for customer-managed transparent data encryption. A new standard requires that a new key version be generated automatically every 90 days and that the platform team be notified 30 days before the current version expires. The team wants to minimize administrative effort and avoid custom scripts.
What should you configure?
- AA key rotation policy on key-sql-tde that automatically rotates the key 90 days after creation, sets an expiry time on each version, and sends a near-expiry notification through Azure Event Grid 30 days before expiry.Key Vault key rotation policies natively create new versions on a schedule and raise an Event Grid near-expiry event at a configurable lead time, with no custom code.
- BAn Azure Automation runbook that runs every 90 days to create a new version of key-sql-tde and sends an email.A runbook works but is custom automation that must be maintained and monitored, which contradicts the minimal-effort and no-scripts constraints.
- CA calendar reminder for the platform team to create a new key version manually each quarter.Manual rotation depends on people remembering and fails the automation requirement.
- DA certificate in kv-dan-prod issued by an integrated certificate authority with auto-renewal set to 90 days.Certificate auto-renewal applies to certificate objects, not to a standalone RSA key used for encryption.
Why: Azure Key Vault has a built-in rotation policy for keys that handles both the schedule and the notification, which is the lowest-effort way to meet a periodic rotation standard. The deciding constraints are automation without custom scripts and a 30-day advance notice, both of which are properties of the rotation policy. Runbooks and reminders are legitimate but higher-effort approaches, and certificate auto-renewal is the trap because it is a similar-sounding lifecycle feature that applies to a different object type.
Secure secrets and keys by using Azure Key Vault
Orwell Pharma has a Key Vault named kv-orwell-prod and a virtual network named vnet-prod that hosts the application servers. Compliance requires that the vault be reachable only over the private network, that it have no public endpoint at all, and that the servers in vnet-prod resolve the vault's standard hostname to a private IP address without any change to application configuration.
Which three actions should you perform? Each correct answer presents part of the solution.
- ACreate a private endpoint for kv-orwell-prod in a subnet of vnet-prod with the vault sub-resource.The private endpoint provides a network interface with a private IP in vnet-prod that fronts the Key Vault data plane.
- BSet public network access on kv-orwell-prod to Disabled.Disabling public network access ensures the vault accepts connections only through private endpoints, satisfying the no-public-endpoint requirement.
- CCreate a private DNS zone named privatelink.vaultcore.azure.net, link it to vnet-prod, and register the private endpoint's A record in it.The private DNS zone makes the vault's standard hostname resolve to the private endpoint IP inside vnet-prod, so applications keep using the same URL.
- DEnable the Microsoft.KeyVault service endpoint on the application subnet and add a virtual network rule for it in the vault firewall.Service endpoints still route to the vault's public endpoint and would be useless once public network access is disabled.
- EEnable the setting to allow trusted Microsoft services to bypass the firewall on kv-orwell-prod.The trusted-services bypass admits specific Microsoft services through the public firewall and does nothing for private connectivity or name resolution.
Why: Fully private Key Vault access has three parts: a private endpoint for the vault, disabling public network access so the private path is the only path, and private DNS so the public hostname resolves privately. The deciding constraints are no public endpoint and no application changes, which rule out service endpoints (they use the public endpoint) and make DNS mandatory (without it, clients resolve to the public IP and are refused). The trusted-services bypass is a public-firewall feature and is irrelevant once the public endpoint is closed.