Vault Exam Sample Questions: Core Domains (Associate / Ops)

This article is a curated set of sample questions for the HashiCorp Vault certifications (Associate / Operations), organized around the domains that come up most often, viewed through a practical operations lens.

We avoid version-specific edge cases and stick to the stable behavior described in the official documentation. Enterprise-only features (namespaces, replication, and so on) are called out explicitly.

Exam Domains and How They Fit Together

Associate covers the core concepts broadly: init/unseal, tokens and policies, auth methods, the main Secrets Engines, TTL/lease/wrapping, and audit. Operations adds HA and storage, backup and recovery, day-2 operations, and the basics of (Enterprise) replication.

Most questions come down to whether you can correctly pair each component with its responsibility. You should be able to picture the flow end to end: client authentication, policy enforcement, secret issuance and revocation by the Secrets Engine, and audit logging.

• Auth methods prove who you are, policies control what you can do, and Secrets Engines decide what gets handed out (static or dynamic).
• TTL/lease govern lifetime, wrapping enables safe handoff, and audit provides the trail of operations.
• From an Ops perspective, the exam probes HA/storage design, init and unseal, and the consistency of backup and recovery procedures.

Flow from client request to secret issuance (high level)

Client --> [Auth Method] --(login)--> [Token]
   |                                   |
   |---- request w/ token ------------> |  (policy check)
                                       v
                                   [Secrets Engine]
                                       |
                                       v
                                   [Lease/TTL]
                                       |
                                       v
                                    [Audit]

Minimal command example for grasping the concept (KV v2 read)

vault login <TOKEN>
# Only the paths the policy allows will succeed
vault kv get -mount=secret app/config

Token and Policy Design Essentials (Associate / Ops)

Authorization in Vault is policy-centric. You grant capabilities (read, create, update, delete, list, deny, sudo, and so on) on path blocks at the least-privilege level you can. deny always wins — an explicit deny cancels any allow. The default policy only grants minimal self-introspection, and root tokens must not be used for everyday work.

Tokens come in two broad flavors: service and batch. Service tokens are persisted, renewable, and can create child tokens. Batch tokens are non-persistent, non-renewable, and cannot create child tokens — they shine in high-throughput scenarios. Orphan tokens are not chain-revoked when their parent is revoked. Periodic tokens must be renewed within the period and are deliberately not bound by max_ttl.

• The exam tends to ask why you picked a given token type rather than just what each token can do.
• TTL hierarchy: requested TTL ≤ role max_ttl ≤ system maximum. If renewable=false, the token cannot be renewed at all.
• Policies are evaluated additively, but deny still wins. Over-broad wildcard allows are a classic wrong-answer trap.

Example: writing a policy and creating tokens

# Policy (HCL)
path "secret/data/app/*" {
  capabilities = ["read", "list"]
}

# Apply the policy
vault policy write app-read app-read.hcl

# A service token (1 hour, renewable)
vault token create -policy=app-read -ttl=1h

# A batch token (not persisted, not renewable)
vault token create -type=batch -policy=app-read -ttl=15m

# An orphan token
yes | vault token create -policy=app-read -orphan

Choosing Auth Methods and Secrets Engines

Choose an auth method based on where the workload lives and where its identity comes from. For example: Kubernetes Auth for pods, AppRole for server apps, OIDC/JWT for SaaS or human users, and the cloud-native auth methods for cloud runtimes. For ad-hoc human operations, GitHub/LDAP/userpass are fine — just keep the policies minimal.

Pick a Secrets Engine by purpose. KV v2 holds versioned static secrets, Database issues and revokes dynamic credentials, Transit performs encryption and signing without storing data, and PKI issues short-lived certificates. The exam loves "I want encryption without storing data → Transit" style mapping questions.

• Kubernetes: verify the ServiceAccount JWT, then attach policies via Role/RoleBinding.
• AppRole: a Role ID plus a Secret ID. A natural fit for pull-style deployments.
• KV v2: a two-layer API (data/ and metadata/); the difference between delete and destroy is a recurring exam theme.

Representative enable commands

# Enable an auth method (AppRole, for example)
vault auth enable approle
vault write auth/approle/role/app ttl=1h policies=app-read
vault read -field=role_id auth/approle/role/app/role-id
vault write -f -field=secret_id auth/approle/role/app/secret-id

# Enable a secrets engine (KV v2, for example)
vault secrets enable -path=secret -version=2 kv
vault kv put secret/app/config username=svc password=s3cr3t

TTL, Leases, Revocation, and Response Wrapping

Dynamic secrets (for example, those from the Database Engine) come with a lease. A lease either expires automatically or gets extended when the client renews it. Revoking by prefix (revoke -prefix) reclaims every dynamic credential under that mount. Static secrets (KV) are usually not lease-managed.

Response wrapping sets X-Vault-Wrap-TTL so the response is wrapped in a single-use wrapping token that can be handed off safely. Only the receiver can unwrap it, and the payload sits temporarily in Cubbyhole. On the exam, it is the canonical answer whenever a question asks how to safeguard credentials in transit through intermediaries.

• Periodic tokens can keep renewing past max_ttl, but they expire the moment you stop renewing them.
• Tokens and leases are different things: a token authorizes, a lease governs the lifetime of what was issued (such as a DB user).
• revoke reclaims immediately, revoke-prefix reclaims a range, and revoke-force is the last resort.

Typical renew and revoke operations

# Renew the token (where possible)
vault token renew -increment=30m

# Renew or revoke by lease ID
vault lease renew database/creds/app/abc123
vault lease revoke database/creds/app/abc123

# Revoke everything under a prefix
yes | vault lease revoke -prefix database/creds/app

# Hand it over safely with response wrapping
VAULT_ADDR=https://vault:8200 \
curl -H "X-Vault-Token: $TOKEN" -H "X-Vault-Wrap-TTL: 5m" \
  $VAULT_ADDR/v1/secret/data/app/config
# On the receiving side: vault unwrap

Operations: Init, Unseal, HA, and Storage

Initialization generates Shamir-split keys (recoverable above a threshold) along with the initial root token. Configuring Auto Unseal with cloud KMS or an HSM removes the manual unseal step at startup. In that mode, recovery keys are typically issued separately for break-glass operations.

An HA deployment runs Active/Standby with writes accepted only by the Active node. Integrated storage (Raft) lets Vault itself reach consensus across nodes for availability. Snapshots provide a consistent backup that is used for planned maintenance or disaster recovery.

• Integrated storage requires a quorum in the cluster. Be careful with shutdown and restart ordering.
• Upgrades follow the same playbook: take a snapshot first, verify compatibility, then roll out in stages.
• Standby nodes forward requests but do not write. Plan for brief lease-renewal failures during Active failover.

Representative init/unseal and Raft procedures

# Initialize (5 shares, threshold 3)
vault operator init -key-shares=5 -key-threshold=3
# Unseal (supply as many keys as the threshold)
vault operator unseal

# Join the Raft cluster
vault operator raft join http://vault-1:8200

# Auto-unseal example (config excerpt)
seal "awskms" {
  region     = "ap-northeast-1"
  kms_key_id = "arn:aws:kms:..."
}

Operations: Audit, Backup, and Enterprise Replication

Audit devices record metadata for every API request and response. Sensitive fields are HMAC-hashed to reduce exposure risk. In production, rotation, retention, and clock synchronization of the audit destination matter just as much as turning it on.

Backups are taken as integrated-storage snapshots: a consistent point-in-time state that can be restored within the same major-version compatibility window. Enterprise adds DR and Performance replication — DR fails over to a standby cluster, while Performance scales reads. The exam expects you to keep the terminology and use cases straight.

• Audit is one of the first operational controls you should enable. Disabling HMAC is for verification environments only.
• Snapshots must be reconciled with the target cluster's state. Validate access policies after every restore.
• DR is about availability; Performance is about throughput. Assuming one replication mode covers both requirements is a common mistake.

Audit, snapshots, and replication (including Enterprise features)

# Enable the audit device (to a file)
vault audit enable file file_path=/var/log/vault_audit.log

# Snapshot of the integrated storage
vault operator raft snapshot save backup.snap
# Restore (during a maintenance window)
vault operator raft snapshot restore backup.snap

# Enterprise (the point here is the terminology)
# Enabling DR/performance replication needs a licence. Treat the CLI as conceptual.

Check Your Understanding

Frequently Asked Questions