5.6 Bastion and Key Vault for Administration and Secrets

Secure the Administration Path with Azure Bastion

Azure Bastion and Azure Key Vault are frequently tested as product-matching controls, and they solve different problems. Bastion is about how administrators connect to virtual machines. Key Vault is about where applications and administrators store sensitive values.

Azure Bastion is a fully managed platform-as-a-service (PaaS) service for RDP and SSH connectivity to virtual machines over TLS (port 443). You deploy it into the VM's virtual network, and you connect to VMs directly in the Azure portal using the VM's private IP address. The headline exam points: the VMs do not need public IP addresses, no agent runs inside them, and (for portal access) no special client software is required — just a browser.

Because there is no public RDP/SSH port open to the internet, Bastion materially shrinks the attack surface that brute-force and port-scanning attacks target, supporting Zero Trust principles.

Bastion comes in tiers of increasing capability:

For SC-900 you do not memorize SKU feature lists, but knowing Bastion = private-IP RDP/SSH over TLS without public VM IPs is essential.

Centralize Secret Material with Azure Key Vault

Azure Key Vault centralizes sensitive material so it is not scattered through source code or app settings that many people can read. Microsoft documents three problem areas Key Vault solves — and recognizing all three is a common exam point:

Access control is central. A caller must be authenticated and authorized before touching stored material. Authentication is always done through Microsoft Entra ID. Authorization can use either Azure role-based access control (RBAC) or legacy Key Vault access policies — RBAC is the recommended model. Tie this to Zero Trust and least privilege: store sensitive values centrally, grant only the access each identity needs, and audit access rather than distributing secrets freely.

Key Vault has two tiers that map to a frequently tested compliance distinction:

• Standard — software-protected keys; validated to FIPS 140-2 Level 1.
• Premium — HSM (hardware security module)-backed keys in a hardware boundary; validated to FIPS 140-3 Level 3.

For stricter single-tenant HSM isolation, Microsoft also offers Azure Key Vault Managed HSM, but Standard versus Premium is what SC-900 expects you to recognize.

Encryption at Rest and in Transit, and the Selection Trap

Key Vault underpins encryption, a CIA-triad confidentiality control. Encryption at rest protects stored data: Azure encrypts data at rest by default (for example, Azure Storage Service Encryption for blobs and files, and Transparent Data Encryption for Azure SQL). Customers can supply customer-managed keys (CMK) stored in Key Vault instead of using Microsoft-managed keys, giving control over the key lifecycle. Encryption in transit protects data moving across networks, primarily via TLS — the same protocol Bastion uses for its RDP/SSH sessions.

SC-900 expects you to know both states of data must be protected and that Key Vault is where customer-managed encryption keys and certificates live.

Bastion and Key Vault frequently combine with the chapter's network controls. A VM might sit in a private subnet protected by NSGs, be administered through Bastion, draw secrets from Key Vault, and route egress through Azure Firewall. A web app might use Key Vault for its TLS certificate while WAF inspects its HTTP requests.

Avoid the matching trap:

• Do not choose Bastion when the prompt is about SQL injection (WAF), DDoS mitigation (DDoS Protection), or storing secrets (Key Vault).
• Do not choose Key Vault when the prompt asks how admins can RDP/SSH to a VM without a public IP (Bastion).
• Bastion protects the administrative access path; Key Vault protects secret material.
• Microsoft Entra ID authenticates Key Vault access; RBAC or access policies authorize it.
• Both support defense in depth but neither replaces a firewall or an NSG.

Soft Delete, Purge Protection, and Managed Identities

Key Vault includes resilience features that protect against accidental or malicious loss. Soft delete retains deleted vaults and objects for a recoverable retention period (default 90 days) so they can be restored. Purge protection goes further: while enabled, even a soft-deleted vault or object cannot be permanently purged until the retention period elapses, blocking an attacker (or a mistake) from immediately erasing keys. These are commonly enabled together for production vaults and are worth recognizing as data-protection controls.

A related identity concept is the managed identity. Rather than storing a Key Vault credential inside the application (which would defeat the purpose), an Azure resource can be given a managed identity in Microsoft Entra ID and granted access to the vault via RBAC. The app then authenticates as itself with no secret in code — a clean illustration of Zero Trust and least privilege that the exam likes to pair with Key Vault.

A Combined Worked Scenario

Consider a regulated web application. Its TLS certificate lives in Key Vault Premium (HSM-backed, FIPS 140-3 Level 3); its database password is a Key Vault secret retrieved at runtime via the app's managed identity. Administrators patch the backend VMs through Azure Bastion over TLS on the VMs' private IPs — no public RDP/SSH exposure. The VMs sit in NSG-filtered subnets, egress through Azure Firewall, and the public web tier is fronted by WAF.

Each control answers a different exam clue: certificate/secret storage → Key Vault; VM admin without public IP → Bastion; subnet filtering → NSG; central egress → Azure Firewall; web exploits → WAF. Mapping the clue to the control is the entire skill this chapter builds.