Unit 1 — The Mental Model

Vault uses a client/server architecture. The server hosts an API that clients communicate with over HTTP/HTTPS; through client requests to the API, data is read from or written to the storage backend.

Four consequences worth internalizing before anything else:

• Every capability is mounted at a path. Secrets engines, auth methods, and the system backend all occupy path space.
• Logical operations in Vault are path-based, and policies provide a declarative way to grant or forbid access to certain paths and operations.
• Vault provides authentication to a client by the use of auth methods, and authorization by the use of policies. Understanding how Vault surfaces these is the key to understanding how to configure and manage it.
• The CLI is a client of the API. When CLI docs are thin, read the API reference — it is what customers integrate against.

Integrated storage is based on the Raft consensus algorithm and built directly into the Vault binary. Because of this, the API and storage layers of Vault run on the same machine. There is no need to install additional software. Vault Enterprise has two storage backends available; the validated design uses integrated storage.

When using integrated storage, the cluster is bootstrapped during initialization. Initial bootstrapping results in a cluster of 1 node — the active node (leader). Additional nodes are then joined as standby nodes (followers). Once a standby has successfully joined, data from the active node begins replicating to it.

Only the active node performs write operations against the storage backend. Standby nodes can perform reads against storage and forward writes to the active node. This functionality is called performance standby mode, and is enabled by default for all standby nodes when using integrated storage on Vault Enterprise.

Note that carefully — performance standby is not an opt-in tier feature. It is the default behavior of standby nodes on Enterprise with integrated storage. This matters later in Unit 8.

A Vault cluster must maintain quorum in order to continue servicing requests. Nodes should be spread across availability zones to increase fault tolerance.

By default, standby nodes are also voters. If the active node becomes unavailable, a new active node is chosen by and among the remaining standby nodes. However, standby nodes can also be specified as non-voters. Non-voting nodes also act as data replication targets, but do not contribute to the quorum count.

A non-voting node can be promoted to a voting node through Vault Enterprise’s Autopilot functionality. Autopilot also enables server stabilization, automated upgrades, and redundancy zones.

Vault will seal itself under certain conditions, such as during a loss of quorum. Sealing prevents control of Vault from falling into the hands of a single actor. By default a sealed Vault is unsealed by manually submitting enough unseal key shards, created at initialization.

Because this process is manual, it becomes suboptimal with many clusters, as there are many different key holders with many different keys. For Vault Enterprise deployments, configure an auto-unseal mechanism.

Secrets engines — provide an interface for storing, retrieving, and controlling access to sensitive data, with each type handling specific kinds of secrets or workflows, such as key/value storage or database credential issuance.

Auth methods — the method that users, machines, or applications use to authenticate to a cluster.

Policies — the permissions assigned to authenticated users, machines, or applications specifying what secrets they can access.

Tokens — every request carries one. Service tokens are persisted; batch tokens are issued from memory and do not consume storage.

Leases — every dynamic secret carries one, with a TTL. Unit 7 covers the lifecycle.

Audit devices — Unit 3. The critical property: an otherwise-successful request will fail if it cannot be logged to at least one configured audit device.

Vault crossed a major version boundary in April 2026. Material from before then may be wrong. Three changes break existing patterns:

Change	Version	Effect
Wildcards and globs no longer permitted in the rendered output of identity templates — Vault returns “permission denied”	2.0.1	Breaks templated policies where entity metadata contains a glob. See Unit 5.
max_token_header_size added to the TCP listener, default 8 KB (8192 bytes)	2.0.0	Covers all current opaque Vault tokens; operators using enterprise JWT or OIDC tokens with large authorization_details claims should evaluate token sizes and raise the limit proactively
IPC_LOCK capability removed from official OCI images, preserving the non-root vault user runtime model	2.0.2	Affects container runtime configuration

New Enterprise surface in 2.0.0: SCIM identity provisioning; SPIFFE JWT-SVID support; visual policy generator; namespace onboarding workflow; Secret Sync using workload identity federation; envelope encryption via Transit; public CA integration (PKI External CA, acquiring certificates from public CAs through ACME); AWS KMS multi-region keys; local accounts secrets engine for Linux credential rotation; LDAP static role rotation enhancements; rotation policies defining reusable retry behavior for failed automated rotations.

Two known issues to check on customer clusters:

• On performance primary clusters, the rotation manager incorrectly routes rotation entries for local mounts created under a namespace to shared rotation manager storage instead of local storage, so entries can be lost on restart. Before upgrading to a fixed version, set disable_automated_rotation=true on the root or static role config to clean up the entry in shared storage.
• SCIM is beta. When using Okta Group Push with Vault SCIM, removing a user from an Okta group does not remove that user from the corresponding Vault group, because Okta sends a SCIM PATCH request for member removal that Vault 2.0.0 does not support.