Azure Key Vault for secrets, certificates, and connection settings

Overview

Azure Key Vault is a managed service for protecting secrets, cryptographic keys, and X.509 certificates. It centralizes sensitive material, authenticates callers through Microsoft Entra ID, authorizes data access, versions stored objects, records audit events, and supports lifecycle features such as rotation, renewal, soft delete, and purge protection.

Typical Key Vault content includes:

• Database passwords and connection strings that cannot yet be replaced by token authentication.
• Third-party API keys.
• Client credentials for legacy integrations.
• TLS and client-authentication certificates.
• Encryption and signing keys.
• Storage or messaging access keys when a managed identity cannot be used.

Key Vault should not become the general configuration database for an application. Nonsecret values such as service endpoints, feature flags, retry limits, and display settings belong in application settings or Azure App Configuration. When possible, an application should use managed identity and Microsoft Entra authentication directly instead of storing a connection string or access key at all.

For interviews, candidates should be able to explain:

• The differences among Key Vault secrets, keys, and certificates.
• How control-plane and data-plane permissions differ.
• Why Azure RBAC is preferred over legacy vault access policies.
• How managed identity, SDK clients, platform references, and App Configuration references retrieve values.
• How secret versioning, caching, rotation, and application reload behavior interact.
• How certificate policies, exportable private keys, and renewal work.
• Why soft delete, purge protection, network restrictions, monitoring, and vault boundaries matter.
• How to avoid turning Key Vault into a runtime bottleneck or a single broad blast radius.

Core Concepts

Secrets, Keys, and Certificates

Key Vault manages three related but distinct object types:

• Secret: An opaque value returned to an authorized caller, such as a password, API key, token, or connection string.
• Key: Cryptographic key material used through operations such as encrypt, decrypt, wrap, unwrap, sign, and verify. Applications can use a nonexportable key without retrieving the private key material.
• Certificate: An X.509 certificate lifecycle object containing certificate metadata, a related key, and a related secret representation.

Choose the object type based on how the application uses the material:

Storing a certificate merely as an arbitrary secret loses certificate policy and lifecycle capabilities. Storing ordinary configuration as secrets adds latency, cost, permissions, and operational complexity without improving security.

Secret Values and Metadata

Key Vault treats secret values as opaque data. It encrypts and stores them but does not understand whether a string is a database password, JSON credential, or connection string.

Useful secret metadata includes:

• Content type.
• Enabled state.
• Not-before and expiration dates.
• Tags for owner, rotation policy, environment, or dependency.
• Created and updated timestamps.

Expiration metadata does not rotate the external credential. A complete process must update the credential at its source, publish a new Key Vault version, update or refresh consumers, validate the new credential, and retire the old one.

Do not put sensitive information in secret names, tags, diagnostic messages, or deployment outputs. Callers with metadata permissions may be able to list these values even when they cannot read the secret content.

Key Vault Is Not General Configuration Storage

Separate sensitive and non-sensitive configuration:

App Configuration or application settings:
  Database:Host
  Database:Name
  Payments:Endpoint
  Features:EnableExpressCheckout

Key Vault:
  Database--Password
  Payments--ApiKey

This improves:

• Runtime performance.
• Configuration discoverability.
• Permission boundaries.
• Rotation workflows.
• Failure isolation.
• Cost and service-limit usage.

If a service supports Microsoft Entra authentication, prefer an endpoint plus managed identity:

Storage:ServiceUri = configured value
Credential = managed identity

This is better than storing a storage account key in a connection string because no reusable secret needs to be retrieved or rotated.

Vault Boundaries

A key vault is a security and operational boundary. Current guidance favors separate vaults by application, environment, and often region.

Benefits include:

• A workload reads only its own secrets.
• Production access is isolated from development access.
• Network policies can differ by environment.
• Rotation and incident response affect fewer systems.
• Audit events are easier to attribute.
• Role assignments remain understandable.

Avoid one organization-wide vault containing unrelated application secrets. Individual object-level role assignments are possible, but a large number of per-secret exceptions becomes difficult to govern. Use separate vaults when applications have different trust boundaries.

Multitenant systems may require separate vaults per tenant when vault-level isolation is part of the security model. The operational cost and service limits must be included in the design.

Authentication with Managed Identity

Applications should authenticate to Key Vault with a managed identity when hosted on Azure.

The flow is:

1. The Azure resource has a system-assigned or user-assigned managed identity.
2. The identity receives the required Key Vault data-plane role.
3. The application requests a Key Vault access token through Azure.Identity.
4. The Key Vault SDK sends that token with the request.
5. Key Vault authorizes the requested operation.

No Key Vault credential should be stored in the application. The vault URI is configuration, not a secret.

builder.Services.AddSingleton(sp =>
{
    var configuration = sp.GetRequiredService<IConfiguration>();
    var vaultUri = new Uri(configuration["KeyVault:Uri"]!);

    return new SecretClient(vaultUri, new DefaultAzureCredential());
});

DefaultAzureCredential can use a developer identity locally and managed identity in Azure. Production systems may use a more explicit credential when deterministic credential selection is important.

Azure RBAC and Data-Plane Roles

Key Vault has two authorization planes:

• Control plane: Creates, configures, networks, tags, or deletes the vault resource.
• Data plane: Reads and manages secrets, keys, and certificates inside the vault.

A control-plane role does not necessarily grant access to secret values. For example, Key Vault Contributor manages the vault resource but does not read secrets, keys, or certificates.

Common data-plane roles include:

• Key Vault Secrets User: Read secret values.
• Key Vault Secrets Officer: Manage secrets.
• Key Vault Certificate User: Read certificate content, including the related private-key secret when exportable.
• Key Vault Certificates Officer: Manage certificates.
• Key Vault Crypto User: Perform cryptographic key operations.
• Key Vault Crypto Officer: Manage keys.
• Key Vault Reader: Read metadata but not sensitive values.
• Key Vault Administrator: Perform all data-plane operations.

Applications normally need a narrow user role, not an officer or administrator role. Assign roles at the vault scope for a vault dedicated to the application. Avoid broad subscription assignments.

Azure RBAC is preferred over legacy access policies because it integrates with centralized role management, Privileged Identity Management, conditions for delegated role administration, and standard auditing. Changing an existing vault from access policies to RBAC invalidates the old data-plane grants, so migration requires equivalent role assignments before switching.

Direct SDK Retrieval

An application can retrieve a secret explicitly:

public sealed class PaymentCredentialProvider
{
    private readonly SecretClient _client;

    public PaymentCredentialProvider(SecretClient client)
    {
        _client = client;
    }

    public async Task<string> GetApiKeyAsync(
        CancellationToken cancellationToken)
    {
        KeyVaultSecret secret = await _client.GetSecretAsync(
            "Payments--ApiKey",
            cancellationToken: cancellationToken);

        return secret.Value;
    }
}

Direct retrieval is useful when the application needs:

• Explicit version selection.
• Custom caching and refresh behavior.
• Detailed failure handling.
• Runtime access to a small number of secrets.
• Certificate or key operations through SDK clients.

Do not call Key Vault for every incoming request. Reuse SDK clients and cache values appropriately.

Platform Key Vault References

Azure App Service and Azure Functions can resolve Key Vault references in app settings and connection-string settings. Application code reads the resolved value as ordinary configuration:

Payments__ApiKey =
  @Microsoft.KeyVault(VaultName=orders-prod-kv;SecretName=Payments--ApiKey)

Advantages:

• Little or no application code change.
• Secret values remain outside deployment templates and app settings.
• The platform uses the application's managed identity.
• Existing libraries can continue reading configuration keys.

Trade-offs:

• Resolution and caching are controlled by the platform.
• A reference without a version tracks the latest version, but refresh is not immediate.
• App Service commonly caches resolved values and periodically refetches them.
• A configuration change or explicit refresh operation can force refetching.
• Startup may fail or expose the unresolved reference string when identity, network, name, or permission configuration is wrong.

Use a user-assigned identity when the reference must work during initial resource creation before a system-assigned identity can be granted access.

Azure App Configuration Key Vault References

Azure App Configuration can store a reference to a Key Vault secret. It stores the secret URI, not the secret value. The application-side configuration provider recognizes the reference and retrieves the value from Key Vault.

The application must authenticate to both services:

var credential = new DefaultAzureCredential();

builder.Configuration.AddAzureAppConfiguration(options =>
{
    options.Connect(
        new Uri(builder.Configuration["AppConfig:Endpoint"]!),
        credential);

    options.ConfigureKeyVault(keyVault =>
    {
        keyVault.SetCredential(credential);
    });
});

This pattern keeps:

• General settings in App Configuration.
• Sensitive values in Key Vault.
• References and refresh behavior in one configuration pipeline.

App Configuration does not retrieve the secret on behalf of the application. The application identity still needs direct access to Key Vault.

Connection Settings

A connection string can contain:

• A service endpoint.
• A database name.
• A username.
• A password or access key.
• Protocol and client options.

Do not assume the entire string must always be a secret. Prefer secretless authentication when supported:

var credential = new DefaultAzureCredential();

var blobClient = new BlobServiceClient(
    new Uri(configuration["Storage:ServiceUri"]!),
    credential);

For Azure SQL, prefer managed identity or another Microsoft Entra authentication mode where practical. For Service Bus, Storage, Key Vault, and other Azure services, use token-aware SDK constructors.

Store a connection string in Key Vault when:

• The target does not support Microsoft Entra authentication.
• A third party requires a password or API key.
• Migration away from shared credentials is not yet possible.

Treat the connection string as one credential when components must rotate atomically. If username and password have separate lifecycles, separate secrets may be appropriate, but the application must handle consistency during rotation.

Secret Versioning

Updating a secret creates a new version. Consumers can request:

• A specific version.
• The latest enabled version by omitting the version.

Version pinning provides deterministic deployment but does not automatically adopt rotation. Using the latest version enables rotation but requires a refresh strategy and compatibility window.

A safe rotation sequence is:

1. Create or enable the new credential at the target service.
2. Store it as a new Key Vault secret version.
3. Refresh consumers.
4. Confirm successful use of the new credential.
5. Disable or revoke the old credential.
6. Retain recovery information according to policy.

For services with two credentials, alternate between them to support zero-downtime rotation.

Caching and Resilience

Key Vault is a remote dependency with quotas and transient failure modes. Applications should not make secret retrieval part of every business request.

Use:

• Reused, thread-safe SDK clients.
• In-memory caching for appropriate secrets.
• Bounded exponential-backoff retries.
• Jitter for distributed workloads.
• A refresh process aligned with rotation.
• Metrics for failures, throttling, age, and refresh outcomes.

Caching reduces latency and throttling but extends how long an old or revoked value remains in process memory. Select a cache duration based on:

• Rotation frequency.
• Revocation requirements.
• Expected Key Vault availability.
• Number of instances.
• Impact of stale credentials.

Never write cached secret values to logs, distributed caches without equivalent protection, crash dumps, or health-check responses.

Certificate Objects

A Key Vault certificate is a compound object. Creating one also creates:

• Certificate metadata.
• A Key Vault key with the same name.
• A Key Vault secret with the same name.

The certificate policy controls:

• Subject and subject alternative names.
• Issuer.
• Key type and size.
• Whether the private key is exportable.
• Validity and renewal settings.
• Lifetime actions such as automatic renewal or notifications.

If the certificate key is nonexportable, applications use supported Key Vault key operations rather than retrieving the private key. Exportable certificates can be retrieved through the related secret in PFX or PEM form when authorized.

Granting certificate metadata access is not the same as granting access to the private key content. Select roles based on whether the caller must manage the certificate, read the public certificate, download an exportable private key, or perform cryptographic operations.

Certificate Renewal and Consumer Reload

Renewing a certificate creates a new version. Renewal is only complete operationally when consumers begin using it.

Plan for:

• Certificate policy and issuer support.
• Renewal lead time.
• Notifications and Event Grid events.
• Application or platform reload behavior.
• TLS binding synchronization.
• Trust-chain compatibility.
• Validation before the old certificate expires.

Automatic issuance does not guarantee automatic application reload. A process that loads a certificate once at startup may need a restart or dynamic reload mechanism.

Soft Delete and Purge Protection

Soft delete retains deleted vaults and objects for a configured retention period so they can be recovered. Purge protection prevents permanent deletion until that retention period ends.

Use both for production vaults because:

• Accidental deletion is recoverable.
• A compromised administrator cannot immediately destroy protected material.
• Customer-managed encryption keys may be essential to decrypt dependent data.

Purge privileges should be highly restricted and separated from ordinary secret administration. Recovery procedures must be tested; a feature that has never been exercised is not a complete recovery strategy.

Deleting a resource group does not eliminate Key Vault retention semantics. Infrastructure automation must handle vault-name reuse, recovery, and cleanup deliberately.

Network Security

Identity authorization and network access are independent controls. A caller may have the correct role but still be blocked by the firewall or private endpoint configuration.

Protection options include:

• Disable public network access and use private endpoints.
• Restrict public access through the Key Vault firewall.
• Use virtual network integration from the application.
• Configure private DNS correctly.
• Use a Network Security Perimeter where appropriate.

Private endpoints reduce public exposure but add:

• DNS dependencies.
• Virtual network routing.
• Deployment ordering.
• Local-development complexity.
• Additional failure modes.

Do not assume "Allow trusted Microsoft services" includes every Azure service or every access path.

Monitoring and Alerting

Enable diagnostic settings and send audit events to an appropriate destination such as Log Analytics.

Monitor:

• Secret, key, and certificate reads.
• Repeated forbidden responses.
• Deletions, recoveries, and purge attempts.
• Role assignment changes.
• Network configuration changes.
• Objects nearing expiration.
• Certificate renewal failures.
• Unexpected callers or access locations.
• Throttling and latency.

Use Event Grid for lifecycle events and Azure Monitor alerts for operational and security signals. Avoid including secret values in telemetry.

Failure Diagnosis

A structured diagnosis separates:

1. Identity: Is the intended human or workload identity being used?
2. Authorization: Does it have the required data-plane role at the correct scope?
3. Network: Can the client reach the vault endpoint and resolve private DNS?
4. Object: Does the named secret, version, key, or certificate exist and remain enabled?
5. Refresh: Is the consumer still using a cached value or pinned version?
6. Target credential: Was the underlying password, key, or certificate changed correctly?

Common symptoms:

• 401: Token or authentication problem.
• 403: RBAC, access model, network rule, or tenant problem.
• 404: Wrong vault, object name, version, or intentionally concealed unauthorized lookup.
• 429: Excessive calls or service throttling.
• Application still uses old value: Cache or refresh behavior.

Common Mistakes

• Storing all application configuration in Key Vault.
• Storing a reusable Azure access key when managed identity is supported.
• Granting Key Vault Administrator to an application that only reads one class of secrets.
• Confusing Key Vault Contributor with secret-value access.
• Using one vault for unrelated applications and environments.
• Calling Key Vault on every request.
• Rotating the Key Vault value without rotating the target credential.
• Enabling certificate autorenewal without reloading consumers.
• Disabling public access without configuring private DNS and application routing.
• Pinning a secret version and expecting automatic rotation.
• Omitting soft delete, purge protection, audit logs, or recovery tests.
• Logging resolved secrets, connection strings, or certificate private keys.

Interview Design Checklist

For a Key Vault design, explain:

1. Whether the value should exist as a secret at all.
2. Which workload identity retrieves or uses it.
3. Which narrow data-plane role is required.
4. Where the vault boundary sits.
5. How the application reaches the vault.
6. Whether retrieval uses SDK code, a platform reference, or App Configuration.
7. How values are cached and refreshed.
8. How credentials or certificates rotate without downtime.
9. How deletion, purge, backup, and recovery are controlled.
10. Which audit signals trigger alerts.