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>
# ポリシーで許可されたパスのみ成功
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

# ポリシー（HCL）
path "secret/data/app/*" {
  capabilities = ["read", "list"]
}

# ポリシー適用
vault policy write app-read app-read.hcl

# service トークン（1h、更新可）
vault token create -policy=app-read -ttl=1h

# batch トークン（非永続・非更新）
vault token create -type=batch -policy=app-read -ttl=15m

# orphan トークン
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

# 認証方式の有効化（例: AppRole）
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

# Secrets Engine の有効化（例: KV v2）
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

# トークン更新（可能な場合）
vault token renew -increment=30m

# リース ID を指定して更新/失効
vault lease renew database/creds/app/abc123
vault lease revoke database/creds/app/abc123

# プレフィックス配下を一括失効
yes | vault lease revoke -prefix database/creds/app

# レスポンスラップで安全に受け渡し
VAULT_ADDR=https://vault:8200 \
curl -H "X-Vault-Token: $TOKEN" -H "X-Vault-Wrap-TTL: 5m" \
  $VAULT_ADDR/v1/secret/data/app/config
# 受領側: 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

# 初期化（例: 5分割・3閾値）
vault operator init -key-shares=5 -key-threshold=3
# Unseal（閾値分のキーを入力）
vault operator unseal

# Raft クラスタ参加
vault operator raft join http://vault-1:8200

# Auto Unseal の例（設定ファイル抜粋）
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)

# 監査デバイスの有効化（ファイル出力）
vault audit enable file file_path=/var/log/vault_audit.log

# 統合ストレージのスナップショット
vault operator raft snapshot save backup.snap
# 復元（メンテ状態で実施）
vault operator raft snapshot restore backup.snap

# Enterprise（用語の把握が主題）
# DR/Performance 複製の有効化はライセンス前提。CLI は概念理解に留める。

Check Your Understanding

Frequently Asked Questions