Java / Azure Key Vault Interview questions

Azure Key Vault is a managed Azure service for storing and controlling access to secrets, cryptographic keys and TLS certificates. Applications call it over HTTPS instead of keeping connection strings, passwords or private keys in code, config files or pipelines.

Microsoft runs the infrastructure, patching and HSM hardware. You decide who can read what, every caller is authenticated through Microsoft Entra ID, and requests can be logged for audit.

Typical uses are database passwords, API keys, encryption keys for storage and databases, and certificates for web endpoints.

All three live in the same vault, but they behave differently when you read them.

The key point is that an application never needs to hold a key's private material. It asks Key Vault to do the cryptographic work.

Both tiers store secrets, keys and certificates with the same APIs. The difference is how keys are protected.

Choose Premium when a compliance rule says keys must be generated and used inside hardware. For everything else Standard is enough.

A vault name must be globally unique because it becomes part of the public DNS name <name>.vault.azure.net.

• 3 to 24 characters long
• Only letters, digits and hyphens
• Must start with a letter and end with a letter or digit
• No two hyphens in a row

Names of soft-deleted vaults stay reserved until the vault is purged or the retention period ends, so you cannot reuse the name straight after deleting.

Create a resource group first, then the vault. For new vaults, turn on RBAC authorization and purge protection from day one.

az group create --name rg-demo --location eastus

az keyvault create \
  --name contoso-kv-01 \
  --resource-group rg-demo \
  --location eastus \
  --enable-rbac-authorization true \
  --enable-purge-protection true

az keyvault secret set --vault-name contoso-kv-01 --name DbPassword --value "S3cr3t!"

Creating the vault does not give you data access automatically. Assign a role such as Key Vault Secrets Officer before running the last command.

A secret is any small piece of text you want to keep out of source control: a password, token, connection string or even a base64 certificate. Key Vault stores it encrypted and returns the same value to authorised callers.

Every set creates a new version. The identifier looks like this:

https://contoso-kv-01.vault.azure.net/secrets/DbPassword/3f9a1c...  (specific version)
https://contoso-kv-01.vault.azure.net/secrets/DbPassword            (latest)

Each secret can also carry a content type, tags, an activation date, an expiry date and an enabled flag.

A single secret can hold up to 25 KB of data. That is plenty for passwords, tokens and connection strings, but not for files.

If you need to protect something bigger, such as a large config file, encrypt it yourself, keep the ciphertext in Blob Storage, and store only the encryption key (or a key reference) in Key Vault. Splitting a big payload across many secrets is possible but makes versioning and rotation messy.

A key is a cryptographic key managed by the vault. Unlike a secret, you normally cannot read its private part. You send data to the vault and it returns the result.

• Encrypt / decrypt small payloads
• Sign / verify hashes or tokens
• Wrap / unwrap other keys (used for envelope encryption)

Keys can be created in the vault or imported, and can be software-protected or HSM-protected on Premium. Services such as Storage, SQL and disk encryption use Key Vault keys as customer-managed keys.

RSA 2048 is the usual minimum for new work. Use EC when you need smaller signatures and faster operations.

A Key Vault certificate is an X.509 certificate plus a policy that describes how it is created, exported and renewed.

When you create one, the vault actually produces three linked objects: the certificate itself, an addressable key and an addressable secret that holds the full certificate with its private key (PKCS#12 or PEM).

The policy can name an issuer (self-signed, DigiCert, GlobalSign or a non-integrated CA), key type and size, subject and SANs, and lifetime actions such as auto-renew.

Key Vault is billed on usage, not on the number of secrets you store. The main meters are:

• Operations: charged per block of 10,000 transactions (secret reads, key operations, and so on)
• Certificates: a charge per renewal request
• HSM-protected keys on Premium: a monthly charge per key, plus operations
• Managed HSM: hourly charge per pool

Rates change and differ by region, so check the Azure pricing page or calculator. In practice, caching secrets in the app keeps both cost and throttling low.

A versioned identifier ends with a version ID and always points to one immutable value. A versionless identifier omits it and resolves to whatever version is currently latest and enabled.

Use versionless for anything that should pick up rotation automatically, such as App Service references or storage encryption keys. Use versioned only when you must pin an exact value.

Each secret version carries metadata: enabled, nbf (not before), exp (expiry), created and updated times, plus a content type and tags.

enabled set to false switches that version off. The nbf and exp dates are mainly informational: the vault does not rotate or delete the secret for you. They exist so you can raise alerts and so consumers know a value is meant to be retired.

az keyvault secret set --vault-name contoso-kv-01 --name ApiKey --value abc123 --expires 2027-03-31T00:00:00Z

Soft delete keeps a deleted vault or vault object (secret, key, certificate) recoverable for a retention period instead of removing it immediately. It is always on for vaults and cannot be turned off.

You pick a retention of 7 to 90 days at creation, default 90. During that window the item is in a deleted state: you can list it, recover it, or purge it (unless purge protection is on).

One side effect: while a vault is soft-deleted its name stays reserved, so you cannot create a new vault with the same name.

Purge protection blocks permanent deletion of soft-deleted vaults and objects until the retention period ends. Even an owner cannot purge early.

Once enabled it cannot be disabled. That is the point: an attacker or a careless admin cannot wipe keys and then purge them to make the data unrecoverable.

It is mandatory when you use a Key Vault key as a customer-managed key for services like Storage or SQL, because losing the key would mean losing the data.

If soft delete retention has not expired, list the deleted items and recover the one you need. You need the right permission, such as Key Vault Secrets Officer.

az keyvault secret list-deleted --vault-name contoso-kv-01
az keyvault secret recover --vault-name contoso-kv-01 --name DbPassword

# whole vault
az keyvault recover --name contoso-kv-01

Recovery restores the object with all its versions. If purge protection was on, you simply wait; nothing can remove it before retention ends.

Key Vault exposes two separate surfaces, each with its own authorization.

A person with the plain Contributor role can manage the vault but has no data access under the RBAC model. This split is a main reason to prefer RBAC over access policies.

Both control data-plane access, but they work very differently. Access policies are the original per-vault model; Azure RBAC is the recommended model that uses the same role system as the rest of Azure.

Both models cannot be active at once. Setting enableRbacAuthorization to true makes the vault ignore its access policies, which is a common cause of sudden 403 errors after migration.

Microsoft ships separate data-plane roles so you can give an app just the access it needs.

A running app that only reads a password should get Secrets User, scoped to the vault or the specific secret.

A managed identity is an Entra ID identity that Azure creates and rotates for a resource (VM, App Service, Function, AKS pod). The app gets tokens without any stored credential, which solves the classic chicken-and-egg problem: you need a secret to fetch secrets.

sequenceDiagram
    participant App as App Service
    participant ID as Entra ID / identity endpoint
    participant KV as Key Vault
    App->>ID: Request token for vault.azure.net
    ID-->>App: Access token (managed identity)
    App->>KV: GET secret + Bearer token
    KV-->>App: Secret value

System-assigned identities live and die with the resource. User-assigned identities are separate objects you can share across resources. Grant the identity a role like Secrets User on the vault.

Use Azure.Security.KeyVault.Secrets with Azure.Identity. The credential finds the identity automatically, so no password appears in code.

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

var client = new SecretClient(
    new Uri("https://contoso-kv-01.vault.azure.net/"),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync("DbPassword");
string value = secret.Value;

Create the client once and reuse it, and cache the value for a sensible time. The identity running the code needs at least the Secrets User role.

DefaultAzureCredential tries several credential sources in order and uses the first that works. That lets the same code run on a laptop and in Azure.

1. Environment variables (service principal)
2. Workload identity (AKS)
3. Managed identity (Azure-hosted)
4. Developer sign-ins: Visual Studio, VS Code, Azure CLI, Azure PowerShell, azd

In Azure, the managed identity step succeeds. On a developer machine, the az login account is used. Because this chain can pick an unexpected credential, many teams use ManagedIdentityCredential directly in production for predictability.

Managed HSM is a fully managed, single-tenant pool of FIPS 140 Level 3 validated hardware security modules. You get dedicated HSMs, and only you control the keys.

• Stores keys only (no secrets or certificates)
• Uses its own local RBAC for the data plane, no access policies
• Initial admins are set at creation, then you download a security domain to activate it
• Always has soft delete and purge protection

The security domain is the root of trust used to recover the HSM. Lose it and you cannot restore the pool, so store it safely, split under a quorum such as 3 of 5 keys.

Many teams use both: a normal vault for app secrets and a Managed HSM for the root encryption keys of regulated data.

By default a vault is reachable over the public endpoint, protected only by authentication. You can tighten that in layers:

1. Firewall: set default action to Deny and allow specific IP ranges.
2. Virtual network rules: allow subnets that use the Microsoft.KeyVault service endpoint.
3. Private endpoint: give the vault a private IP in your VNet, then disable public network access.
4. Trusted services bypass: let selected Azure services through even when the firewall denies.

az keyvault update --name contoso-kv-01 --default-action Deny
az keyvault network-rule add --name contoso-kv-01 --ip-address 203.0.113.10/32

Network rules add to identity checks, they do not replace them.

A private endpoint is a network interface in your VNet with a private IP that maps to your vault through Azure Private Link. Traffic stays on the Microsoft backbone and never uses the public endpoint.

flowchart LR
    A["App in VNet"] --> B["Private DNS zone privatelink.vaultcore.azure.net"]
    B --> C["Private endpoint 10.0.1.5"]
    C --> D[(Key Vault)]

You must create a private DNS zone so that contoso-kv-01.vault.azure.net resolves to the private IP. If DNS still returns the public address and public access is disabled, calls fail with 403.

It sets the bypass option to AzureServices. Even when the firewall denies public traffic, certain first-party Azure services are allowed through, for example Azure Backup, Azure Disk Encryption, Azure Storage and SQL when using customer-managed keys.

The service must still be authorized with a role or policy. The bypass only skips the network check.

networkAcls: {
  defaultAction: 'Deny'
  bypass: 'AzureServices'
}

Not every Azure service is trusted this way. Generic compute like a normal VM or App Service needs a VNet rule, private endpoint or IP rule.

Add a diagnostic setting on the vault and send the AuditEvent log category to Log Analytics, a storage account or Event Hubs. Each data-plane request is recorded with caller identity, operation, IP and result code.

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName == "SecretGet"
| summarize count() by CallerIPAddress, identity_claim_appid_g, ResultSignature

Metrics such as ServiceApiHit, ServiceApiLatency and Availability help spot throttling and outages. Alert rules on 403/429 results catch misconfiguration early.

Key Vault publishes events to Azure Event Grid. The relevant ones are SecretNearExpiry (fires about 30 days before expiry), SecretExpired and SecretNewVersionCreated. Similar events exist for keys and certificates.

flowchart LR
    KV["Key Vault"] --> EG["Event Grid"]
    EG --> F["Azure Function / Logic App"]
    F --> N["Email, Teams or rotate secret"]

Subscribe a Function or Logic App to the event, then notify the owner or run a rotation. This only works for secrets that have an expiry date set.

A Key Vault reference lets an App Service or Function app setting point at a secret instead of containing it. The platform resolves it at runtime using the app's managed identity, so your code just reads an ordinary environment variable.

@Microsoft.KeyVault(SecretUri=https://contoso-kv-01.vault.azure.net/secrets/DbPassword/)
@Microsoft.KeyVault(VaultName=contoso-kv-01;SecretName=DbPassword)

Requirements: a managed identity on the app with Secrets User on the vault, and network path to the vault. Without a version, the value is refreshed periodically (roughly daily), so a new secret version appears without redeploying. If resolution fails, the setting shows the error in the portal.

The Azure Key Vault provider for Secrets Store CSI Driver mounts secrets into pods as files. You describe what to fetch in a SecretProviderClass, and the pod authenticates with workload identity (recommended) or a managed identity.

sequenceDiagram
    participant Pod
    participant CSI as Secrets Store CSI driver
    participant KV as Key Vault
    Pod->>CSI: Mount volume (SecretProviderClass)
    CSI->>KV: Get secret using workload identity
    KV-->>CSI: Secret value
    CSI-->>Pod: File at /mnt/secrets

Optionally the driver can also sync the value into a Kubernetes Secret. Enable the add-on with az aks enable-addons --addons azure-keyvault-secrets-provider.

The safe approach is to make both the old and new values valid for a while, then retire the old one.

1. Create the new credential in the target system (a second password or key).
2. Set it as a new version of the secret in Key Vault.
3. Consumers using a versionless reference pick up the new version as they refresh.
4. After all clients have switched, disable or revoke the old credential and old version.

Services with two interchangeable credentials, such as storage account keys, make this easy. Automate it with an Event Grid trigger on SecretNearExpiry and an Azure Function. Apps should also retry once by re-reading the secret when authentication fails.

You attach a rotation policy to a key. It defines when to create a new key version and when to send a notification, based on time after creation or time before expiry.

az keyvault key rotation-policy update --vault-name contoso-kv-01 --name data-kek --value policy.json
az keyvault key rotate --vault-name contoso-kv-01 --name data-kek

Rotation creates a new version, it does not delete the old one, so existing ciphertext can still be decrypted. Services using a versionless key URI, like Storage CMK, switch to the new version automatically. Event Grid fires KeyNewVersionCreated.

A certificate policy can contain lifetime actions: at a set percentage of lifetime (default 80%) or a number of days before expiry, the vault either AutoRenews or emails the contacts.

Renewal creates a new certificate version. Consumers using a versionless certificate URI get the new one, but services that cache the certificate must reload it.

Envelope encryption uses two layers of keys. A fast data encryption key (DEK) encrypts the data. A key encryption key (KEK) kept in Key Vault encrypts, or wraps, the DEK.

flowchart LR
    A["Generate DEK locally"] --> B["Encrypt data with DEK"]
    A --> C["Wrap DEK with KEK in Key Vault"]
    B --> D["Store ciphertext"]
    C --> E["Store wrapped DEK next to data"]

To read the data, the app sends the wrapped DEK to Key Vault's unwrapKey operation, gets the DEK back and decrypts locally. Only small DEKs travel to the vault, so you avoid RSA size limits and heavy traffic. The KEK itself never leaves the vault.

Customer-managed keys (CMK) let you own the root key that protects a service's data at rest, instead of relying on Microsoft-managed keys. The key lives in your Key Vault or Managed HSM, and the service uses it to wrap its own data keys.

• Azure Storage (blobs, files)
• Azure SQL and Managed Instance (TDE)
• Managed disks via Disk Encryption Sets
• Cosmos DB, Azure Data Factory, Azure Monitor and many others

Benefits: control of rotation, ability to revoke access to data by disabling the key, and audit of every use. The cost is operational: if you lose or disable the key, the data becomes unreadable.

Storage always encrypts data at rest. With CMK, the account's data keys are wrapped by your vault key instead of a Microsoft-managed key.

1. Give the storage account a managed identity.
2. Grant that identity Key Vault Crypto Service Encryption User on the vault (or get, wrapKey, unwrapKey policies).
3. Make sure the vault has soft delete and purge protection.
4. Point the account at the key URI, ideally versionless.

With a versionless URI, storage checks for new versions (around daily) and starts using them automatically. With a pinned version you must update the setting manually after each rotation.

Azure SQL encrypts database files with a database encryption key (DEK). In BYOK TDE the DEK is protected by a TDE protector, an asymmetric RSA key that lives in your Key Vault.

• The SQL server needs an identity with get, wrapKey and unwrapKey (or the Crypto Service Encryption User role).
• The vault must have soft delete and purge protection.
• The server unwraps the DEK at startup and when it needs it.

If the server cannot reach or use the key, the databases become inaccessible after a short while. That is why you monitor key health and keep backups of the key.

BYOK (bring your own key) means you generate the key in your own on-premises HSM and transfer it to Key Vault without it ever appearing in clear text. It needs a Premium vault (or Managed HSM) for HSM-protected keys.

1. Create a key exchange key (KEK) in the vault with import-only operations.
2. Download the KEK public key.
3. Use your HSM vendor's tool to wrap your key into a BYOK package for that KEK.
4. Upload the package and import.

az keyvault key create --vault-name contoso-kv-01 --name kek --kty RSA-HSM --ops import --protection hsm
az keyvault key import --vault-name contoso-kv-01 --name imported --byok-file package.byok

Software keys can also be imported from a PEM file when no HSM transfer is needed.

Services that depend on it lose the ability to unwrap their data keys, so the data becomes inaccessible. Reads and writes start failing, usually within minutes up to an hour depending on the service and caching.

Fix by re-enabling or recovering the key, and the service resumes. Purge protection prevents the unrecoverable case, and a key backup is the last line of defence.

You back up individual secrets, keys or certificates. The result is an opaque, encrypted blob that only Key Vault can restore.

az keyvault secret backup --vault-name contoso-kv-01 --name DbPassword --file dbpassword.bak
az keyvault secret restore --vault-name contoso-kv-01 --file dbpassword.bak

• Restore must go to a vault in the same subscription and the same Azure geography.
• All versions of the object are included.
• There is no one-click whole-vault backup for standard vaults; script it per object. Managed HSM does support full backups.

Store backup files securely, since they are encrypted for the vault but still sensitive.

Key Vault keeps your data replicated inside the region, across availability zones where the region has them, so a single datacenter failure does not take it down.

It is also replicated to the paired region. If the whole primary region fails, requests are routed to the paired region, where the vault is read-only (get, list, crypto operations work; creating or changing items does not) until the primary recovers.

Design apps to cache secrets at startup so a short outage or read-only period does not stop them. For stricter needs, keep separate vaults per region and replicate secrets yourself.

Each vault has request-rate limits per operation type and region. When an app exceeds them, Key Vault returns HTTP 429 Too Many Requests. Limits are per vault, so many apps sharing one vault can starve each other.

1. Cache secrets in memory instead of reading per request.
2. Use exponential backoff and honour the Retry-After header (SDKs already do basic retries).
3. Reuse clients and avoid chatty listing calls.
4. Split workloads across vaults, for example per app or environment.
5. For Key Vault key operations in hot paths, use envelope encryption and unwrap the DEK once.

Track ServiceApiResult and 429 counts in Azure Monitor to see problems early.

A 403 means the caller was identified but not allowed. Work through the usual causes in order:

1. Firewall: is the caller's IP or subnet allowed, and does DNS resolve to the private endpoint?
2. Permission model: if RBAC is on, access policies are ignored. Check the role assignment instead.
3. Right role and scope: Contributor gives no data access. Add Secrets User or similar.
4. Propagation: new role assignments can take several minutes.
5. Wrong identity: the app may be running as a different identity than you think.

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT" and httpStatusCode_d == 403
| project TimeGenerated, OperationName, CallerIPAddress, identity_claim_appid_g, ResultDescription

The audit log shows the exact caller and reason, which usually points straight at the cause.

Read the certificate's addressable secret, not the certificate object. The secret contains the full certificate and private key in PKCS#12 (or PEM, depending on policy).

az keyvault secret download --vault-name contoso-kv-01 --name my-cert --file my-cert.pfx --encoding base64

This only works if the certificate policy marks the key as exportable. A non-exportable certificate keeps the private key inside the vault, which is safer. Use az keyvault certificate download when you only need the public part.

The caller needs permission to read secrets (Secrets User or Certificate-specific roles), so treat that access carefully.

Almost always. Microsoft's guidance is one vault per application, per environment, per region.

• Blast radius: a leaked dev identity cannot touch production secrets.
• Access control: roles are assigned at vault scope, so separate vaults make least privilege simple.
• Throttling: limits are per vault, so a noisy dev workload cannot starve prod.
• Network rules: prod can be private-only while dev is relaxed.

A single shared vault is acceptable for tiny systems, but it mixes access boundaries and quickly becomes hard to audit. Use a naming convention like kv-app-prod-eus to keep things tidy.

They work together: App Configuration can hold a Key Vault reference. The app reads the setting, sees the reference, and fetches the actual secret from Key Vault using its identity. That keeps ordinary settings and secrets in the right place.

Declare a Microsoft.KeyVault/vaults resource and set the security properties explicitly.

resource kv 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'kv-orders-prod-eus'
  location: resourceGroup().location
  properties: {
    tenantId: subscription().tenantId
    sku: { family: 'A', name: 'standard' }
    enableRbacAuthorization: true
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enablePurgeProtection: true
    publicNetworkAccess: 'Disabled'
  }
}

Then add Microsoft.Authorization/roleAssignments resources to grant roles to identities. Keep secrets out of the template: set them from a pipeline step or reference existing ones.

These vault properties allow specific Azure services to pull material from the vault, independently of normal user access.

Leave them off unless you need that scenario. Each flag widens who can touch the vault, so enable only the ones your workflow uses.

Azure Pipelines: use the AzureKeyVault@2 task with an Azure service connection. It downloads chosen secrets and exposes them as masked pipeline variables. A variable group linked to Key Vault does the same.

- task: AzureKeyVault@2
  inputs:
    azureSubscription: 'my-service-connection'
    KeyVaultName: 'contoso-kv-01'
    SecretsFilter: 'DbPassword,ApiKey'

GitHub Actions: sign in with azure/login using OIDC federation (no stored password), then call az keyvault secret show and mask the output. Grant the pipeline identity only Secrets User, scoped to the vault it needs.