Vault Associate: Explain Vault Architecture

The request path

A request flows: client → HTTP API (TLS) → Vault core → router → target auth method or secrets engine → barrier → storage backend. The barrier is the heart of the design: it holds the encryption key and encrypts or decrypts everything written to storage with AES-256-GCM. Consequently the storage backend only ever sees ciphertext, so Vault does not trust storage - a compromised disk or bucket does not expose secrets. The barrier also supplies the check-and-set mechanism used for consistency.

Seal and unseal

On startup Vault is sealed: no key in memory, and it will only answer unseal and status requests. The master key is split with Shamir's Secret Sharing into key shares; a threshold of shares reconstructs it. vault operator init prints the shares once, and vault operator unseal supplies them. Unsealed, Vault decrypts the encryption key and serves traffic. Auto-unseal delegates the key to a KMS, HSM, or Transit engine, removing manual unseal but shifting trust to that service.

HA and replication

With integrated storage (Raft) or a supported backend, Vault runs active/standby; standbys redirect clients to the active node. Enterprise adds performance replication (scales reads, replicates mounts) and DR replication (a failover copy).

Traps

• Storage backends never see plaintext; they are not trusted.
• Vault never stores unseal key shares.
• A sealed node can do almost nothing - /sys/seal-status reports state.

Rule of thumb: memorize the request path - API, core, engine, barrier, storage - because most architecture questions are really asking where encryption happens.