HashiCorp Vault Associate 試験ガイド: 出題範囲・配点の考え方・申込手順

Vault Associate は、Vault の基本アーキテクチャ、認証・認可、シークレットエンジン、リース管理、データ保護（Transit など）、運用監査を横断的に問うエントリーレベル資格です。

本稿は、出題範囲と配点の考え方、受験申込の実務、学習の着眼点をまとめています。最新情報は公式ドキュメントと認定ページを優先してください（https://developer.hashicorp.com/vault / https://developer.hashicorp.com/certifications/security-automation）。

試験の全体像と配点ポリシーの捉え方

Vault Associate は多肢選択式（単一/複数選択を含む）が中心で、ブループリントに沿ってドメイン毎に出題されます。問題数・制限時間・合格基準は改定されることがあるため、受験直前に公式認定ページで確認してください。

配点はドメイン比率で大枠が決まり、個々の問題は均等とは限りません。部分点は基本的にありません。見直し時間を確保し、取り切れる問題から解く順番設計が有効です。

• 出題は英語が基本（UI 言語や辞書の可否は受験プラットフォームの規約に従う）
• ドメイン横断のシナリオ問題が増えがち（例: 認証とリースを絡めた設問）
• 個別機能の暗記より、Vault の原理（Auth と Secrets の分離、ポリシー評価、リースと失効）を優先して理解

Vault Associate 出題マップ（概念のつながり）

試験前に最低限手を動かす: バージョンとステータス確認

vault --version
VAULT_ADDR=http://127.0.0.1:8200 vault status
# dev サーバ起動中なら Seal Type/Key Shares/HA Mode などが確認できる

Vault の基本アーキテクチャと運用要点

Vault は単一バイナリで、ストレージ、API サーバ、暗号コアを内包します。ストレージには Integrated Storage（Raft）が広く使われ、HA 構成ではリーダー選出が行われます。初期化（init）でマスターキーが生成され、シール/アンシールにより鍵素材の取り扱いが制御されます。

試験では、init/unseal の流れ、Raft と外部ストレージの違い、オートアンシールの概念、vault status 出力の読み方が頻出です。

• init は一度だけ実施。以降は unseal で始動
• シール状態では API は健康チェック以外に応答しない
• Raft はサーバ内に一貫性を持つログを保持。スナップショット/ピア管理が要点

Raft を用いた HA クラスタ概略

初期化とアンシールの最短手順（検証用）

# 初期化（学習用に 1/1 構成）
vault operator init -key-shares=1 -key-threshold=1 > init.out
UNSEAL_KEY=$(grep 'Unseal Key 1:' init.out | awk '{print $4}')
ROOT_TOKEN=$(grep 'Initial Root Token:' init.out | awk '{print $4}')

# アンシールとログイン
vault operator unseal "$UNSEAL_KEY"
vault login "$ROOT_TOKEN"

# 状態確認
vault status

認証（Auth）とポリシー（Authorization）の核心

Vault では、Auth Method が誰かを証明し、ポリシーが何ができるかを決めます。トークンは一時的な権限の容器であり、親子継承や TTL により権限の寿命が管理されます。

試験では、各 Auth の適用シナリオ、トークン種別（service/ batch など）の違い、ポリシーのパス構文（capabilities）を文脈に合わせて選べるかが問われます。

• Auth の選択はワークロード固有（人間/マシン、Kubernetes 内外、クラウド IAM 連携）
• ポリシーは allow のみを積み上げる設計が基本。deny はエンタープライズ機能に関連
• root トークンの常用は不可。初期設定後は撤廃または厳格保管

AppRole と Kubernetes の認証フロー比較

ポリシー定義と Auth 有効化の最小例

# ポリシー（読み取りのみ）
cat > readonly.hcl <<'EOF'
path "kv/data/app/*" {
  capabilities = ["read", "list"]
}
EOF
vault policy write app-read readonly.hcl

# KV v2 とポリシー対象パスの作成
vault secrets enable -path=kv kv-v2
vault kv put kv/app/config api_key=redacted

# AppRole の有効化とロール作成
vault auth enable approle
vault write auth/approle/role/app-role token_policies="app-read" token_ttl=1h token_max_ttl=4h
vault read -field=role_id auth/approle/role/app-role/role-id
vault write -f -field=wrapping_token -wrap-ttl=5m auth/approle/role/app-role/secret-id

シークレットエンジンとリース管理（更新・失効）

KV は静的シークレット（バージョニング可）、Database や Cloud は動的シークレット（都度発行、期限到来で無効化）を提供します。Vault は発行した資格情報にリースを付与し、TTL/Max TTL/Explicit Max TTL を組み合わせて寿命を制御します。

試験では、renew（更新）とrevoke（失効）の違い、親トークン失効による子リースの巻き戻し、KV v2 のデータパスとメタデータパスの違いが頻出です。

• lease の更新は Max TTL を超えない
• 親トークンが revoke されると、子リースも一括で revoke
• KV v2 はデータが kv/data、メタが kv/metadata、サブパスを誤らない

リースライフサイクルの概念

KV v2 とリース操作の手慣らし

# KV v2 の基本
vault secrets enable -path=kv kv-v2
vault kv put kv/app/config token=abc version=1
vault kv get kv/app/config

# リースの概念は動的シークレットで確認する
# 例: database エンジン（接続先はダミー、実務では有効な DSN を指定）
# vault secrets enable database
# vault write database/config/mydb plugin_name=postgresql-database-plugin \
#   allowed_roles="app-role" connection_url="postgres://..."
# vault write database/roles/app-role db_name=mydb [email protected] \
#   default_ttl=1h max_ttl=4h
# creds 発行と lease 確認
# vault read database/creds/app-role
# vault lease renew <lease_id>
# vault lease revoke <lease_id>

データ保護（Transit/Wrap）と監査の押さえ所

Transit はデータを保存せず、暗号操作（暗号化/復号、署名/検証、トークン化）を提供します。アプリ側は暗号鍵を持たず、Vault の鍵管理ポリシーに従います。レスポンスラッピングは、センシティブなレスポンスを一度限りのラップトークンで包み、別経路で配布するための仕組みです。

監査デバイスを有効化すると、リクエスト/レスポンスのメタ情報が記録され、トレース可能性が向上します。シークレット値はハッシュ化されて記録される点を理解します。

• Transit は鍵のローテーションとバージョン管理が可能
• wrap-ttl は短く、受領側は unwrap を一度だけ実行
• 監査ログのハッシュ化は可逆ではない（値の漏洩防止）

Transit による暗号化の呼び出し経路

Transit と Response Wrapping の小さな実験

# Transit を有効化し鍵を作成
vault secrets enable transit
vault write -f transit/keys/app-key

# 暗号化と復号
cipher=$(vault write -field=ciphertext transit/encrypt/app-key plaintext=$(base64 <<< 'hello'))
echo "$cipher"
vault write -field=plaintext transit/decrypt/app-key ciphertext="$cipher" | base64 -d

# ラッピングして配布（5分で失効）
vault kv get -wrap-ttl=5m kv/app/config > wrapped.json
WRAP_TOKEN=$(jq -r '.wrap_info.token' wrapped.json)
VAULT_TOKEN=$WRAP_TOKEN vault unwrap

受験準備と申込・当日の流れ

申込は HashiCorp Certification のポータルから行います。アカウント作成後、Vault Associate を選択し、希望の受験方式（オンライン監督や地域により提供されるテストセンター）と日時を予約します。受験方式・料金・再受験規約は更新される場合があるため、直前に公式ページを確認してください（https://developer.hashicorp.com/certifications/security-automation）。

学習は公式ドキュメントとチュートリアルを主軸に、手元の dev サーバで CLI を反復するのが最短です。出題は操作の流れを理解しているかを見るため、コマンドと API パスの両方を意識すると得点効率が上がります。

• 本人確認書類を事前に準備（オンライン監督の要件を満たす環境確認）
• トライアルのシステムチェックを受け、本番と同条件でネットワーク/カメラを検証
• 直前は blueprint を読み直し、弱点ドメインの要点を1枚に要約

申込から合否までのタイムライン

学習用に dev サーバを最速で立ち上げる

# 開発用サーバ（揮発、学習専用）
export VAULT_DEV_ROOT_TOKEN_ID=root
vault server -dev -dev-root-token-id=$VAULT_DEV_ROOT_TOKEN_ID &
export VAULT_ADDR=http://127.0.0.1:8200
vault status
# 以降、本文のコマンドをそのまま試せる

問題で確認

よくある質問