HashiCorp Certified: Vault Associate (002)

**Token vs Token Accessor 不分** — Token 本身是 secret，Accessor 是元数据引用，可以用来 lookup 或 revoke 但不能拿来认证。考试至少 1-2 道题考 "管理员怎么 revoke 一个 token 但又不能知道 token 本身的值" — 答案就是 Accessor。

**Response Wrapping 用途搞错** — Response Wrapping 不是加密 secret，是把 secret 包装成一个一次性的 wrapping token，传递给消费方后由消费方 unwrap。典型场景是 CI/CD 把 secret 安全地传给容器，wrapping token 即使被截获也只能用一次。这是考试经典场景题。

**Vault Agent vs 直接调 API 混淆** — Vault Agent 是 client-side daemon，做两件事：auto-auth（自动登录拿 token）和 template（把 secret 渲染到文件给应用读）。它不是 server 组件，不替代 Vault server。题目会问 "应用不想集成 Vault SDK，怎么让它读到 secret" — 答案是 Vault Agent template。

**AppRole 的 two-step pull 只记一半** — AppRole 认证需要 RoleID（公开的，类似 username）+ SecretID（机密的，类似 password）两个值才能换 token。常见错误是只记得 RoleID 或者把 SecretID 当成永久凭证 — SecretID 默认是 single-use 的，用一次就失效，必须 wrap 后传递。

**Seal Type 不分** — Vault 支持多种 seal 模式：Shamir（手动 unseal，5 份 key 要 3 份）、Auto-unseal（用 AWS KMS / Azure Key Vault / GCP KMS 自动解封）、Transit seal（用另一个 Vault 实例解封）。考试会问场景题 — 比如 "在 EKS 上部署 Vault 怎么做到 pod 重启自动恢复" — 答案是 AWS KMS auto-unseal，不是 Shamir。

**KV v1 和 v2 路径搞混** — KV v2 在 API path 上多一层 `data/`，CLI 命令会自动加但 API 调用必须手写：`vault kv get secret/foo`（CLI）实际访问的是 `secret/data/foo`（API）。Policy 里写 path 必须用 API path，所以 v2 的 policy 必须写 `path "secret/data/foo"` 而不是 `path "secret/foo"`。

**以为 Batch Token 等同 Service Token** — Batch Token 不写存储后端，性能极高但不能 renew、不能创建子 token、Vault 重启就失效。适合短生命周期的高频请求场景（比如 CI job），不适合长生命周期的 worker。