HashiCorp Vault Associate 002: Secrets Management Cert 2026

Dev mode vs production mode

The most common beginner mistake with Vault is running a production workload against a dev-mode server. The exam tests this distinction explicitly. Dev mode (vault server -dev) starts an in-memory, single-node, auto-unsealed Vault with a root token printed to stdout — suitable for local development and learning but completely insecure for any persistent use. Production mode requires a configuration file specifying a storage backend, listener (TLS address), and optionally an auto-unseal provider. Key differences the exam tests:

• Persistence: Dev mode stores data in-memory and loses all data on restart. Production mode uses a persistent storage backend.
• Sealing: Dev mode auto-unseals on start. Production mode begins in a sealed state and requires unsealing before serving requests.
• Root token: Dev mode prints the root token to stdout. Production mode generates unseal keys and an initial root token during vault operator init — which must be distributed using Shamir’s Secret Sharing.
• TLS: Dev mode uses HTTP by default. Production mode should always use HTTPS with a valid TLS certificate.

The seal/unseal process and Shamir’s Secret Sharing

When a Vault server starts (or restarts), it is in a sealed state: it cannot serve any requests because the encryption key used to protect the storage backend has not been loaded into memory. The exam tests the mechanics of how Vault becomes operational:

• Initialization (vault operator init): Generates the master key and splits it into n unseal key shares using Shamir’s Secret Sharing. The default is 5 shares with a threshold of 3 — any 3 of the 5 shares can reconstruct the master key and unseal Vault. The shares should be distributed to different administrators so that no single person can unseal Vault unilaterally.
• Unsealing (vault operator unseal): Each operator provides their share; once the threshold is reached, Vault derives the master key, decrypts the encryption key stored in the storage backend, and transitions to an unsealed state.
• Auto-unseal: For production deployments where manual unseal would create operational friction (e.g., after automatic VM restarts), Vault supports auto-unseal using a cloud KMS: AWS KMS, Azure Key Vault, or GCP Cloud KMS holds the master key, and Vault automatically retrieves it on startup. The exam tests the trade-off: auto-unseal eliminates the manual step but makes Vault’s availability dependent on the cloud KMS service and the network path to it.
• Sealing: Vault can be manually sealed by an operator with the sys/seal permission. It also seals automatically if it detects a partial failure that could indicate a security compromise. A sealed Vault serves no requests and protects data even if the storage backend is compromised.

Storage backends and high availability

Vault is a stateless application: all persistent state lives in the storage backend. The exam tests the available backends and their high-availability implications:

• Integrated storage (Raft): The recommended backend since Vault 1.4. Uses the Raft consensus algorithm to replicate data across a cluster of Vault nodes — no external dependency required. A 3-node cluster tolerates one node failure; a 5-node cluster tolerates two. The exam tests that Raft HA requires all nodes to be Vault nodes (not a separate datastore), and that the storage “raft” stanza must include a node_id and path for the data directory.
• Consul backend: The original HA backend. Vault delegates all storage and locking to Consul. Still supported but the 002 exam reflects the industry shift toward Integrated Storage for new deployments.
• Non-HA backends (file, in-memory): Suitable for single-node deployments. The file backend persists data to disk but provides no replication. The exam tests that non-HA backends cannot support multiple Vault nodes serving the same data.
• Active/standby model: In an HA Vault cluster, one node is active (serves reads and writes) and the others are standby (redirect clients to the active node or serve reads via performance standbys in Vault Enterprise). The exam tests that standby nodes are not idle — they participate in Raft consensus and can be promoted to active if the current active node fails.

AppRole

AppRole is the standard auth method for machine-to-machine authentication in non-cloud environments. It uses two pieces of credential: a RoleID (public, analogous to a username) and a SecretID (private, analogous to a password). The key design insight the exam tests is secret introduction: how does a machine that needs to authenticate with Vault receive its SecretID without that SecretID being exposed in a way that allows interception? The recommended pattern is the push model: an orchestration layer (CI/CD pipeline, configuration management system, or a trusted human) delivers the SecretID to the machine at startup via a secure channel, then the machine authenticates with Vault, exchanges the credentials for a short-lived token, and discards the SecretID. SecretIDs have a use-limit and TTL that the exam expects candidates to be able to set and reason about. The pull model — where the machine polls an API that delivers SecretIDs — is also testable. AppRole is appropriate when the workload runs in an environment that does not have a platform-native identity (unlike Kubernetes pods, EC2 instances, or GCE instances which have their own identity documents).

Kubernetes auth

The Kubernetes auth method lets pods authenticate with Vault by presenting their Kubernetes Service Account Token (a JWT signed by the cluster’s API server). Vault verifies the token against the Kubernetes API server using a configured kubernetes_host and optional CA certificate. The exam tests the configuration flow:

• Enable the auth method: vault auth enable kubernetes
• Configure the Kubernetes API server address and the token reviewer JWT (a Vault service account token that Vault uses to call the Kubernetes TokenReview API)
• Create roles that map Kubernetes service accounts and namespaces to Vault policies
• Vault Agent running as a sidecar or init container handles the token exchange transparently — the application pod never calls Vault directly

The critical exam question pattern: a pod in namespace production using service account app-sa should be allowed to read secrets from secret/data/prod/*. The candidate must know that the Vault role must specify bound_service_account_names = [“app-sa”], bound_service_account_namespaces = [“production”], and the role must reference the policy that grants read on secret/data/prod/*. Failing to restrict the namespace allows any pod in any namespace using a service account named app-sa to authenticate with the role — a common misconfiguration the exam tests.

JWT/OIDC auth (for CI/CD pipelines)

GitHub Actions, GitLab CI, and many other CI/CD platforms now issue signed JWTs to pipeline jobs. These JWTs contain claims about the job (repository, branch, environment, ref) that Vault can use to apply fine-grained access policies. The JWT/OIDC auth method eliminates the need for static secrets in CI/CD pipelines entirely — no more platform-level secrets storing cloud credentials. The exam tests:

• Configuring the OIDC discovery URL (e.g. https://token.actions.githubusercontent.com for GitHub Actions)
• Creating bound claims that restrict which pipeline jobs can authenticate to a role (e.g. repository and ref claims to limit access to a specific repo’s main branch deploy job)
• The difference between JWT (static JWKS verification) and OIDC (discovery-based verification) flows

The exam also covers AWS auth (EC2 instance identity documents or IAM roles), GCP auth (service account identity tokens), and Azure auth (VM managed identity tokens) — each follows the same pattern of using a platform-native identity document that Vault verifies against the platform’s API.

KV secrets engine (v1 and v2)

The Key-Value (KV) engine is the simplest secrets engine: it stores arbitrary key-value pairs. The exam tests the critical differences between v1 and v2:

• KV v1: No versioning. Writing a new value to a path overwrites the existing value with no way to recover the previous value. No metadata. Simpler to use but provides no audit trail of secret value changes.
• KV v2: Versioned. Each write creates a new version; up to max_versions (default 10) are retained. Versions can be soft-deleted (vault kv delete marks them deleted but retains the data) or hard-destroyed (vault kv destroy removes the data permanently). Metadata is stored separately from the secret data — a policy can grant access to metadata without granting access to the secret value. The path structure changes: secret/data/my-secret for the actual value, secret/metadata/my-secret for metadata, secret/delete/my-secret for soft-delete, secret/destroy/my-secret for permanent destruction, secret/undelete/my-secret to restore a soft-deleted version.
• Check-and-Set (CAS): KV v2 supports an optional CAS parameter that prevents a write from succeeding unless the current version matches the expected version. Used to prevent race conditions when multiple writers could update the same secret concurrently.

The most common exam question pattern: a team needs to be able to read the current value of a secret but must not be able to see deleted or previous versions. The candidate must identify that the policy needs read on secret/data/path but must NOT include list or read on secret/metadata/path.

Dynamic secrets: database engine

Dynamic secrets are Vault’s most impactful capability and the concept the exam tests most rigorously. Instead of storing a static credential that never changes, Vault generates a new unique credential on demand every time a consumer requests one, and automatically revokes it when the lease expires. The database secrets engine implements this for relational databases (PostgreSQL, MySQL, Oracle, MSSQL, MongoDB) and cloud-managed equivalents (RDS, Cloud SQL, Azure Database).

• Configuration: Vault connects to the database using a highly privileged account (the “root” credential). Vault stores this root credential and uses it to create and revoke dynamic users. The exam tests that the root credential itself should be rotated using vault write database/rotate-root/<config-name> after initial configuration, so that Vault is the only system that knows the root password.
• Roles: Database roles define the SQL statements Vault executes to create a dynamic user (creation_statements), the default TTL and max TTL for the generated credentials, and optionally the statements to revoke them (revocation_statements). The {{name}} and {{password}} placeholders in the creation SQL are substituted with Vault-generated values.
• Credential lease: A consumer reads the dynamic credential at a path like database/creds/my-role. Vault creates the database user, returns the username and password with a lease TTL, and starts a countdown. When the lease expires (or is revoked), Vault executes the revocation statements to drop the database user. If the consumer needs to keep the credential longer, it can renew the lease before expiry up to the max TTL.
• Static roles: For databases where dynamic user creation is impractical (legacy systems, external services), Vault also supports static roles that manage credential rotation for an existing account. Vault rotates the password on a schedule and keeps the stored credential current.

PKI secrets engine

Vault can function as a full certificate authority (CA), issuing X.509 certificates on demand with configurable TTLs, subject fields, SANs, and key types. The exam tests the two-tier CA architecture that security standards require:

• Root CA: A root CA certificate is self-signed and has a very long TTL (10+ years). The root CA’s private key should be kept offline and protected with the highest available physical and cryptographic controls. In Vault, a root CA is configured in a PKI secrets engine path (e.g. pki/) and the root private key is generated inside Vault and never exported.
• Intermediate CA: An intermediate CA is signed by the root CA and has a shorter TTL (1–5 years). All operational certificate issuance happens from the intermediate CA. This limits the blast radius of an intermediate CA compromise — the root CA can revoke the intermediate’s certificate and issue a new one without changing the trust anchor. Vault implements this by generating a Certificate Signing Request (CSR) in the intermediate PKI mount, signing it with the root PKI mount, then importing the signed certificate back into the intermediate mount.
• Certificate issuance: Roles on the PKI engine define which Common Names (CNs) and SANs are permitted, the key algorithm and size, the maximum TTL for issued certificates, and whether the consumer can specify SANs or whether they are enforced by the role. Applications obtain certificates by writing to pki_int/issue/my-role; Vault generates the key pair inside Vault (secure) or signs a CSR from the consumer (key is generated externally).
• CRL and OCSP: Vault maintains a Certificate Revocation List (CRL) and an OCSP responder. The exam tests that the CRL distribution point must be reachable by certificate verifiers — typically an internal load balancer in front of Vault, since Vault itself responds to CRL requests at a well-known path.

Transit secrets engine (encryption as a service)

Transit is Vault’s encryption-as-a-service engine. Rather than shipping data to Vault for storage, applications call Transit to encrypt data before storing it in their own databases. The encryption key never leaves Vault; the application receives only ciphertext. This pattern separates key management from data storage — even a full database dump is useless to an attacker without access to the Transit engine. The exam tests:

• Named keys: Each application creates a named key in Transit (transit/keys/my-app). The key type can be AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, RSA, or ECDSA depending on the use case. AES-256-GCM is the most common for symmetric encryption.
• Encrypt and decrypt: vault write transit/encrypt/my-app plaintext=$(base64 <<< “secret-data”) returns a ciphertext prefixed with the vault version (vault:v1:...). Decryption sends the ciphertext back to transit/decrypt/my-app.
• Key rotation: vault write -f transit/keys/my-app/rotate creates a new key version. New encryptions use the latest version; decryption continues to work for all ciphertext versions because Vault retains all past key versions. The version prefix in the ciphertext (vault:v1:, vault:v2:) identifies which key version was used.
• Rewrap: After rotation, old ciphertext can be re-encrypted with the new key version using transit/rewrap/my-app — without Vault ever decrypting the plaintext. This allows applications to migrate all stored ciphertext to the new key version so that old key versions can be retired (min_decryption_version controls which versions Vault will still decrypt).
• Convergent encryption: An optional mode where the same plaintext always produces the same ciphertext. This enables searching for an encrypted value in a database without decrypting the entire table. The exam tests that convergent encryption has a security trade-off: an attacker who can observe ciphertext values can confirm whether two values have the same plaintext.
• Signing: Transit also supports RSA and ECDSA signing with named keys, enabling Vault to serve as the signing authority for JWTs or data integrity signatures without exposing the private key.

Token types and their lifecycle

Every interaction with Vault requires a token. Tokens carry the policies that define what the bearer can do. The exam tests three token types and the operational scenarios each is appropriate for:

• Service tokens: The standard token type. Stored in Vault’s storage backend with their full metadata: policies, TTL, accessor, create time. Can be renewed, revoked, and looked up. Create a parent-child hierarchy — revoking a parent token recursively revokes all child tokens. Most authentication methods issue service tokens.
• Batch tokens: Lightweight, encrypted binary payloads that are not stored in Vault. Vault does not track them — it simply verifies the cryptographic integrity when presented. Cannot be renewed and do not participate in the parent-child hierarchy. Suitable for high-volume workloads (e.g. a Vault cluster handling millions of authentication events per day) where the overhead of storing service tokens in the backend would create a performance bottleneck. The exam tests that batch tokens cannot be revoked individually and expire only at their fixed TTL.
• Root tokens: Carry every capability on every path. Must be guarded with extreme care. The exam tests that root tokens should be created only when required (e.g. for initial configuration or emergency access), used for the minimum necessary task, then revoked immediately. Root tokens should never be issued with a TTL of zero (which means they never expire); periodic root tokens that expire are safer.
• Orphan tokens: Service tokens that have no parent — revoking the token that created them does not revoke the orphan. Used when a process needs a token that outlives the operator session that created it. The sudo capability on auth/token/create-orphan (or the no_parent parameter with appropriate permissions) is required to create orphan tokens.
• Periodic tokens: Service tokens with a configurable period TTL that can be renewed indefinitely as long as the renewal happens before each period expires. Used by long-running services that need persistent Vault access without a max TTL. The exam tests that periodic tokens do not inherit a max TTL from their parent — they renew forever until explicitly revoked.

Vault policies

Vault policies are written in HCL (HashiCorp Configuration Language) and define path-based access control. Every policy statement specifies a path and a set of capabilities. The exam tests both the HCL syntax and the operational patterns:

• Capabilities: create (write new), read, update (overwrite), delete, list (enumerate), sudo (access root-protected paths), deny (explicit deny overrides all other policy grants). The exam tests that deny is applied before all other capabilities — if any policy attached to a token includes a deny on a path, access is denied regardless of what other policies grant.
• Wildcards and globs: A trailing * matches anything at that level and below (secret/data/prod/* matches all paths under secret/data/prod/). A + wildcard matches a single path segment (secret/data/+/config matches secret/data/app-a/config and secret/data/app-b/config but not secret/data/app-a/nested/config). The exam frequently tests the difference between these two wildcard types in access control scenarios.
• Policy templating: Policies can reference identity entity and group metadata to create self-service access patterns. The template {{identity.entity.id}} resolves to the authenticated entity’s ID, enabling per-user secret namespaces (secret/data/users/{{identity.entity.id}}/*) where each user can read and write their own secrets but not others’. The exam tests this pattern as the solution to scenarios requiring tenant isolation without separate policies per user.
• Default policy: Every token automatically has the default policy attached (unless no_default_policy is set). The default policy grants the minimum capabilities needed for a token to manage itself: renew and revoke its own token, lookup its own capabilities. Operators should understand what the default policy contains before relying on it or modifying it.

Auto-auth, caching, and templating

• Auto-auth: Vault Agent is configured with an auth method stanza (e.g., method “kubernetes” or method “aws”). On startup, it authenticates with Vault and obtains a token. It then monitors the token’s TTL and renews it proactively before expiry. If renewal fails (e.g., the token max TTL has been reached), it re-authenticates from scratch. The application always has a valid token delivered to a sink (a file, environment variable, or in-memory socket) without needing to manage the auth lifecycle itself.
• Templating: Agent can render Consul-Template-style templates that reference Vault secrets. When a secret changes or a lease is renewed, Agent re-renders the template and writes the updated output to a file. Applications that read configuration from files get automatic secret rotation without code changes or restarts (if they support hot-reloading). The exam tests the template syntax: {{ with secret “database/creds/my-role” }}{{ .Data.username }}{{ end }} renders the dynamic database username into a configuration file.
• Caching: Agent can act as a local caching proxy for Vault. Instead of making a network call to Vault for every secret read, the application calls http://127.0.0.1:8200 (the Agent listener) and Agent returns cached results. This reduces latency and protects against brief Vault unavailability. The exam tests that the cache does not persist across Agent restarts (it is in-memory) and that Cache TTLs respect Vault’s lease TTLs.
• Kubernetes injector: The Vault Agent Injector is a Kubernetes MutatingAdmissionWebhook that intercepts Pod creation and injects a Vault Agent init container and sidecar when the Pod carries the annotation vault.hashicorp.com/agent-inject: “true”. The init container fetches secrets before the main container starts (ensuring secrets are available at startup); the sidecar handles renewal throughout the pod’s lifetime. Secrets are delivered as files at /vault/secrets/<filename>. The exam tests the annotations required: vault.hashicorp.com/role specifies the Vault role, and vault.hashicorp.com/agent-inject-secret-<filename> specifies the secret path and optional template for each secret file.