The managed identities in the previous lesson removed the secrets used to reach sttarjetascontosopro and db-reservas, and that is the best possible news: a secret that does not exist cannot leak. But not everything is solved that way. Contoso Airlines still needs the payment gateway key, the token for the weather data provider that feeds the delay forecasts, the connection string for the legacy billing system still running in Barcelona, and the TLS certificate for contosoairlines.example. None of those systems speaks Entra ID, so the secret exists and it has to be kept somewhere. From today, that somewhere is Azure Key Vault: a hardware-backed store with RBAC permissions, a closed network, versioning and an audit trail of every read. By the end, app-contoso-reservas-pro will read its secrets with the managed identity from 04-02 and there will not be a single password in the deployment.

Important warning: key and secret management bears directly on regulatory compliance — PCI DSS for payments, GDPR for passenger data — and a misconfiguration can cause both a breach and an irreversible loss of encrypted data. Before taking any Key Vault, rotation or customer-managed key design into production, it must be reviewed by a security professional or by your organization's compliance team.

1. Where Contoso's secrets live today
2. What Key Vault stores: secrets, keys and certificates
3. Standard, Premium and Managed HSM tiers
4. Creating kv-contoso-pro with soft delete and purge protection
5. The two permission models: access policies versus RBAC
6. Network access: firewall, private endpoint and trusted services
7. Storing, retrieving and versioning secrets
8. Rotating secrets with no downtime
9. Managed TLS certificates
10. Consuming secrets from App Service with Key Vault references
11. Customer-managed encryption keys
12. Auditing, limits and what NOT to put in the vault
13. Common Mistakes and Tips
14. Exercises
15. Conclusion

An honest inventory before fixing anything:

None of them has ever been rotated, nobody knows who has read them, and revoking them would mean hunting through five different places. Key Vault solves all four problems at once: centralized storage, identity-based access control, an audit trail of every operation and managed rotation.

The distinction between a secret and a key is the most important one and the most often confused. A secret is stored in order to be handed back: the application asks for the gateway key and receives the text. A key is never handed back: you send the data to Key Vault so that it encrypts, signs or decrypts it, and the private key never leaves the cryptographic module. That is why encryption keys are stored as keys and not as secrets: even if somebody stole the access token, they could not exfiltrate the key material.

A certificate is really three coordinated objects: the certificate, a key, and a secret holding the complete PFX. Key Vault also manages its lifecycle, including automatic renewal.

Contoso chooses Standard for kv-contoso-pro. That is the right decision unless a standard explicitly demands a Level 3 certified HSM, and it is worth knowing that the tier cannot be changed from Premium back to Standard once created (Standard to Premium can). Azure Managed HSM exists, it costs thousands of euros a month and it only makes sense when the auditor themselves demands it in writing.

Three options deserve a detailed explanation:

• Soft delete: it is always on and cannot be turned off. When you delete a secret, a key or the whole vault, the object moves to a deleted state and is kept for --retention-days (from 7 to 90). During that time it can be recovered with az keyvault recover.
• Purge protection: it prevents the object being permanently deleted during retention, not even by an Owner. Once enabled it cannot be disabled either. It is deliberately inconvenient: it turns a malicious or accidental deletion into something reversible.
• The practical consequence that catches everybody out: while a deleted vault is still in retention, its name stays reserved globally and no other vault can be created with it. If you delete kv-contoso-pro during a test, you will not be able to recreate it under that name for 90 days (or sooner by purging it, unless purge protection prevents that — which is exactly this case). That is why test vaults are created with disposable names and --retention-days 7.

With --enable-rbac-authorization true, data plane permissions are granted with the same roles as everywhere else in Azure. The ones you use:

That last one is 04-02's trap applied here: Key Vault Contributor does not let you read a single secret. It does, however, let you change the vault's configuration, which is why it is also a privileged role worth keeping under PIM.

Look at the scope of the first assignment: one specific secret, not the vault. If app-contoso-reservas-pro is compromised, the attacker gets that key and nothing else.

With --public-network-access Disabled the vault does not answer on the internet. Access arrives through a private endpoint in snet-datos, exactly like pe-sql-reservas and pe-storage-tarjetas in module 2:

And the name has to be registered in private DNS, or the client will carry on resolving the public IP: you create the zone privatelink.vaultcore.azure.net, link it to vnet-contoso-pro and associate it with the endpoint through a DNS zone group. Without that step the endpoint exists and nobody uses it: it is the most frequent Private Link mistake.

One operational nuance remains. Certain Azure services — App Service resolving references, Azure SQL decrypting with a customer key, Event Grid — do not go out through the virtual network. For those there is the Microsoft trusted services exception, which has to be enabled explicitly:

--bypass AzureServices lets that closed list of services through; --default-action Deny still rejects everything else. The exception is not an open hole: every service on the list must also have a role assigned.

Every secret has a versioned identifier, https://kv-contoso-pro.vault.azure.net/secrets/pasarela-pago-clave/a1b2c3..., and an unversioned one that always points at the current version. The practical rule: use the unversioned identifier so that rotation does not force a redeployment, unless you need to pin a specific version for reproducibility.

The --expires and --not-before attributes do not block reads on their own in every client: they are metadata that feed the expiry warnings and the audit queries. Always set them; ignoring them is what leaves a key unrotated for four years.

Rotating means replacing a secret with a new one without anything stopping working. Three mechanisms, from most to least automatic:

Fully managed rotation. For storage account keys, Key Vault can regenerate them by itself. You create a managed storage account secret, tell it how often to rotate, and Key Vault alternates between key1 and key2, regenerating whichever one is not in use:

Note the healthy irony: Contoso no longer uses those keys because it moved to a managed identity (04-02). This mechanism is for the legacy accounts that have not migrated yet.

Expiry notification through Event Grid. Key Vault publishes SecretNearExpiry (30 days beforehand) and SecretExpired events, which can trigger a function or a Logic App that calls the provider's API, obtains a new credential and writes the version into the vault. It is the pattern for third-party secrets such as the payment gateway.

The no-downtime rotation pattern, which is what matters conceptually and works for any secret:

The crux is step 1: the provider has to support two valid credentials at once. If it only supports one, no-downtime rotation is impossible and a maintenance window has to be planned. It is a question worth asking every provider before integrating with them.

Key Vault can issue and renew certificates automatically if it is integrated with a partner certificate authority (DigiCert, GlobalSign), or hold certificates imported from any other. You define a policy with the subject, the alternative names, the validity period and the percentage of lifetime at which it renews:

From there, app-contoso-reservas-pro imports the certificate with az webapp config ssl import --key-vault $KV --key-vault-certificate-name cert-contosoairlines, and when Key Vault renews it, App Service picks up the new version with no intervention. Application Gateway does the same by referencing the certificate's identifier, and that is where it will be used in lesson 04-04 when the web application firewall is built. The free alternative for simple cases is App Service managed certificates, which you already saw in 02-03; Key Vault is the option when the same certificate has to be shared across several services.

This is the moment when passwords disappear from the deployment. A Key Vault reference is an application setting whose value is not the secret but a pointer:

What happens underneath: at startup, App Service uses the managed identity from 04-02 to request the token, resolves the reference and exposes the value to the application as an ordinary environment variable. Consequences worth being clear about:

• The code does not change: it carries on reading ClavePasarelaPago exactly as before. There is no SDK to add.
• The secret is not in the configuration: whoever has config/list sees the pointer, not the value.
• Resolution happens at startup and is cached for 24 hours (or until a restart). After rotating a secret you have to restart the application or wait; if you used the unversioned URI, the reference picks up the new version.
• If the reference fails, the application starts without that setting and usually fails in a confusing way. Always check the status with az webapp config appsettings list, where a broken reference is shown along with its error.

When the application needs to read secrets at runtime (not just at startup), you use the SDK's SecretClient with DefaultAzureCredential, the same credential as in 04-02, and always with your own cache, for the reason given in section 12.

Everything Azure stores is encrypted at rest with Microsoft's keys, without you having to do anything. Customer-managed keys (CMK) change who controls the key: Contoso generates it in kv-contoso-pro, and the service uses it through its managed identity.

What it genuinely adds: the ability to revoke. If the key is disabled, sttarjetascontosopro immediately loses the ability to decrypt its data; it is the "red button" some auditors demand. And what it costs: if that key is deleted or lost, the data is unrecoverable, and there is nothing Microsoft can do. That is why purge protection is mandatory on vaults with CMK, and why Contoso applies them only to sttarjetascontosopro and db-reservas, where the personal data lives, and not to the rest. Rotating a CMK is transparent: the data key is re-encrypted, not the data.

Key Vault logs every data plane operation: who read which secret, from which IP and with what result. Those logs are not kept in the vault, they have to be sent somewhere:

With that, in Log Analytics (07-02) you can answer questions like "who read the gateway key outside working hours?" or "which identities have accessed this secret in the last 90 days?". It is a direct PCI DSS requirement and the reason the workspace lives in rg-contoso-seguridad-pro alongside the vault.

On performance limits: Key Vault applies throttling per vault and region (on the order of 2,000 secret operations per 10 seconds, fewer for RSA key operations). When you exceed it, it returns HTTP 429. Which is why the rule is non-negotiable: the application caches secrets in memory for hours and only re-reads them on rotation or after an authentication error. A service that requests the secret on every HTTP request takes down its own vault the moment real traffic arrives.

And what should not go into Key Vault:

• Configuration that is not secret (URLs, server names, feature flags): that belongs in App Configuration or in ordinary settings.
• Business data or personal data: it is not a database. A secret is 25 KB at most.
• Large files, even sensitive ones: encrypt them and store them in storage, with the key in Key Vault.
• End-user secrets (passengers' passwords): those live in Entra External ID (04-01), hashed, never here.

• Creating the vault with access policies "because that is what old tutorials show". Use --enable-rbac-authorization true from the start; migrating later is tedious.
• Expecting Key Vault Contributor to allow reading secrets. It does not: it manages the vault, not its data.
• Deleting a test vault and not being able to recreate it under the same name. The name stays reserved for the retention period. Use disposable names and 7-day retention in testing.
• Turning on purge protection without understanding it. It is irreversible. In production it is mandatory; on a course or in a test, avoid it.
• Forgetting the private DNS zone for the endpoint. The vault ends up unreachable with a network error that tells you nothing.
• Requesting the secret on every request. HTTP 429 guaranteed under load. Cache it.
• Typing the secret on the command line. It ends up in the shell history and in the pipeline logs. Read it from standard input or from a protected variable.
• Tip: one vault per environment and per trust boundary. kv-contoso-pro and kv-contoso-dev kept separate, never the same vault for production and development.
• Tip: put an alert on the audit log for reads from unexpected identities. It is one of the cleanest signals of compromise there is.

"Contoso Miles" (centro-coste=CC-2077) needs to store: the key for a commercial partners API, the TLS certificate for its subdomain, an encryption key for customer data, and the connection string for a legacy database.

1. Classify the four items as a secret, a key or a certificate, and justify it.
2. Write the vault creation command with the right options and explain each one.
3. Which roles would you assign to the application's managed identity and to the development group, and at what scope?

The payment gateway supports two active keys simultaneously and Contoso has to rotate every 180 days without interrupting ticket sales.

1. Describe the five steps of the process, saying what is done at the provider and what in Azure.
2. How would you automate the warning that expiry is approaching?
3. The application caches the secret for 12 hours. What does that imply for the revocation step?

1. After deploying, the application starts but fails when calling the gateway; in the settings, ClavePasarelaPago shows a reference error.
2. A batch process that reads 40 secrets at the start of each task starts receiving HTTP 429 as concurrency increases.
3. The team deleted kv-contoso-dev and, on recreating it with the same name, gets a conflict error.

Solution 1:

1. Partners API key: a secret, because its value has to be handed back to the application. TLS certificate: a certificate, so as to benefit from automatic renewal and the App Service integration. Encryption key: a key, because it must never leave the vault and is only used for cryptographic operations. Legacy connection string: a secret (and in the medium term, replace it with a managed identity if the engine supports it).
2. az keyvault create -n kv-contoso-millas-pro -g rg-contoso-seguridad-pro -l westeurope --sku standard --enable-rbac-authorization true --enable-purge-protection true --retention-days 90 --public-network-access Disabled plus the four mandatory tags with centro-coste=CC-2077. RBAC because it is the recommended model and it allows per-secret scope; purge protection because there is an encryption key and losing it would make the data unrecoverable; public network disabled plus a private endpoint; 90-day retention because it is production.
3. To the managed identity, Key Vault Secrets User scoped to the specific secret it needs, and Key Vault Crypto User on the encryption key if it operates with it. To the development group, no data role at all in the production vault: at most Key Vault Reader (metadata, no values) for diagnostics, and Secrets Officer only in kv-contoso-millas-dev.

Solution 2:

1. (a) Generate the secondary key in the gateway's portal, leaving the current one active. (b) Write the new version of the secret into Key Vault with az keyvault secret set, using the unversioned URI in the reference so as not to redeploy. (c) Restart the application or wait for the cache to expire on every instance. (d) Check in the provider's logs that traffic is arriving with the new key. (e) Revoke the old key at the provider.
2. With Event Grid: the SecretNearExpiry event is emitted 30 days before the --expires date, and it is wired to a Logic App (06-04) that opens a ticket and emails the owner named in the secret's tags. It requires the expiry date to have been set when the secret was created.
3. That the old one cannot be revoked until at least 12 hours after the new one was written, or until every instance has been restarted. Revoking sooner causes payment failures on the instances still serving the cached key. That is why step 4 — verifying at the provider — is mandatory and not a formality.

Solution 3:

1. The reference is not resolving. Causes in order: the managed identity does not have the Key Vault Secrets User role on that secret; the secret name is misspelled; the vault firewall is blocking App Service (--bypass AzureServices is missing); or the vault uses access policies rather than RBAC. It is diagnosed with az webapp config appsettings list, which shows the reference's specific error.
2. The vault's throttling limit is being exceeded. Fix: cache the 40 secrets in memory for hours instead of re-reading them per task, load them once at process startup rather than per task, and apply retries with exponential backoff on the 429. If that volume really is necessary, split it across several vaults by functional domain.
3. It is soft delete: the vault still exists in a deleted state and its name is reserved. The correct fix is az keyvault recover -n kv-contoso-dev, which restores it with all its secrets. If the intention really was to destroy it, az keyvault purge, which only works if it did not have purge protection and which requires the corresponding permission.

Contoso no longer has secrets scattered around. You have taken the uncomfortable inventory of the starting point — settings in clear text, a token in the Git history, a shared document, a PFX on a laptop — and centralized it in kv-contoso-pro, inside rg-contoso-seguridad-pro. You can tell the three object types apart: secrets, which are handed back; keys, which never leave the vault and are operated on inside it; and certificates, with their lifecycle and automatic renewal. You know that Standard is enough for almost everything, that Premium adds a certified HSM and that Managed HSM costs thousands of euros a month and is only justified when an auditor demands it.

You have created the vault with soft delete — always on, impossible to turn off — and purge protection, understanding that it is irreversible and that a deleted vault's name stays reserved for the retention period. You have chosen Azure RBAC over the legacy access policies, with the decisive nuance that it allows granting one specific secret to one specific identity, and you know the data roles and the Key Vault Contributor trap. You have closed the network with the private endpoint pe-kv-contoso, its DNS zone and the trusted services exception. You can handle secret versioning and its dates, the three rotation mechanisms — managed rotation for storage keys, Event Grid warnings and the five-step no-downtime pattern, which requires the provider to support two credentials at once — and the managed TLS certificates that App Service and Application Gateway consume on their own. Above all, you have reached the moment when passwords disappear from the deployment: @Microsoft.KeyVault(...) references resolve the settings with the managed identity from 04-02 without touching a line of code. The lesson closes with customer-managed keys and their power to revoke and their risk of definitive loss, the audit trail sent to Log Analytics, and the limits that force you to cache.

With governed identities, minimal permissions and no exposed secrets, the inside of the platform is reasonably healthy. The problem is that Contoso Bookings is a public website: anybody on the internet can throw requests at it, and neither RBAC nor Key Vault helps there. In the next lesson, DDoS Protection and Web Application Firewall, you will see what attacks genuinely reach a ticket-selling website — volumetric, protocol, application layer, and the bots that drain the seats into their carts — you will build a WAF policy on fd-contoso-global with the OWASP rule set, learn why you always start in detection mode, and compare exactly what each layer protects: NSG, Azure Firewall, WAF and DDoS.