Build a Learning Environment with the HCP Vault Free Tier: A Practical Guide for Associate / Ops

The Vault Associate / Operations exam scope broadly covers fundamentals such as policies, auth methods, secret engines, tokens/leases, and auditing. Beyond local dev mode, getting hands-on in a cloud environment with HCP Vault (managed) deepens your understanding all the way through network exposure and least-privilege design.

This guide assumes the HCP Vault free trial / free tier and walks through starting as safely as possible, the initial CLI setup, and a minimal hands-on lab (KV and AppRole), tying each step to topics commonly tested on the exam. Features, pricing, and plan names can change over time, so always verify with the HCP console and official documentation.

Free Tier Assumptions and Safe Usage

HCP Vault is a managed Vault cluster on the HashiCorp Cloud Platform. Free trial and development (non-production) plans may include limits such as a single node, feature restrictions, and duration/credit caps. Always check the latest terms in the HCP console and the official documentation (developer.hashicorp.com/vault).

Even for learning, be careful with exposure settings and token operations. Create least-privilege policies, and when using a public endpoint, restrict the IP allow list to only your device's global IP for safety. The initial high-privilege token should be promptly revoked after bootstrap and verification, with strict storage rules as a basic principle.

• Minimize exposure: when using a public endpoint, restrict the IP allow list to your own global IP only
• Least privilege: do not keep reusing the root/admin token after bootstrap
• Cost management: delete the cluster when done. Be careful not to exceed the free tier hours/credits
• Exam mindset: set up a configuration that lets you touch policies (path rules), auth methods (userpass/AppRole/OIDC), KV v2, token TTL/leases, and audit

Steps to Create an HCP Vault Cluster (Free Tier)

Create a project in the HCP console and create a new Vault cluster. For learning, pick a nearby region; if you need to expose it quickly, enable the public endpoint and restrict the IP allow list to your own global IP only. HVN (HashiCorp Virtual Network) can be auto-created or set up manually.

If you want reproducibility with Terraform, use the HCP provider. Provider and resource attributes may change between versions, so consult the latest reference at developer.hashicorp.com before running it.

• Sign in to HCP → Create Project → Vault → Create cluster
• Choose a plan/tier intended for learning/non-production (free tier/development plan)
• Enable Public endpoint → register your device's global IP/32 in Allowed CIDR
• After cluster creation, securely note down the initial token (may be shown only once)

Reference: minimal example of creating a development cluster with Terraform (HCP provider)

terraform {
  required_providers {
    hcp = {
      source  = "hashicorp/hcp"
      version = ">= 0.88.0"
    }
  }
}

provider "hcp" {}

# 学習用の HVN（必要に応じて）
resource "hcp_hvn" "lab" {
  hvn_id         = "hvn-lab"
  cloud_provider = "aws"
  region         = "us-west-2"
  cidr_block     = "172.25.16.0/20"
}

# 開発/無料枠相当のクラスタ（属性名はプロバイダ版数で変わる可能性あり）
resource "hcp_vault_cluster" "lab" {
  cluster_id       = "vault-lab-01"
  hvn_id           = hcp_hvn.lab.hvn_id
  tier             = "dev"        # 学習用ティア例。実際はコンソールの名称に合わせる
  public_endpoint  = true          # 学習の簡便さ重視
  # IP 許可リストはコンソールまたは専用リソースで設定（プロバイダの最新docs参照）
}

output "vault_public_address" {
  value = hcp_vault_cluster.lab.public_endpoint_url
}

Connecting via CLI and Initial Setup

Install the Vault CLI on your local machine and set the environment variables VAULT_ADDR and VAULT_TOKEN. The HCP initial token has elevated privileges. Use it only for bootstrapping policies/roles and switch to a limited learning token as soon as possible.

The connection setup looks like the following. For learning, start simply with public endpoint + IP allow list, then move to HVN/Private Link as you become familiar — this builds operations-oriented perspective.

• Use the https://...:8200 shown in the HCP console for VAULT_ADDR
• Register only your own global IP/32 in the IP allow list (update each time if you change locations)
• Do not store the initial token; switch to a token with a limited policy

Minimal connection diagram for learning

First CLI connection and minimal bootstrap

# macOS 例: CLI インストール
brew tap hashicorp/tap && brew install hashicorp/tap/vault

# HCP 表示のアドレスと初期トークンを設定（初期トークンは一時利用）
export VAULT_ADDR="https://<your-cluster>.<region>.aws.hashicorp.cloud:8200"
export VAULT_TOKEN="hvs.<initial-root-or-admin-token>"

# 接続確認
vault status

# 学習用の読み取り専用ポリシー例（kv v2 の read に限定）
cat > app-read.hcl <<'EOF'
path "secret/data/app/*" {
  capabilities = ["read"]
}
EOF

vault policy write app-read app-read.hcl

# 最小権限のトークンを発行（例: 1h 生存、再新可）
vault token create -policy=app-read -ttl=1h -renewable=true

Essential Vault Feature Set for Learning (Directly Tied to Associate / Ops)

What appears frequently in both the exam and real work: KV v2, auth methods (userpass/AppRole/OIDC), policies, tokens/leases, and auditing. First enable KV v2, restrict access with a policy, then create app-oriented authentication with AppRole — get this flow down.

Audit devices are important in production, and experiencing the basics of file auditing even in a learning environment makes you stronger on design questions (HCP may have constraints on audit destinations, so trying it once in local dev helps your understanding).

• KV v2: versioned key/value. The API paths are data/ and metadata/
• Policies: capabilities per path (read, create, update, delete, list, sudo)
• Auth: userpass suits humans, AppRole suits apps (RoleID/SecretID)
• Tokens/leases: distinguish TTL, Renew, Revoke, and Orphan
• Audit: records request/response metadata. Understand the PII handling policy

Enable KV v2 and AppRole to confirm the basics

# KV v2（secret/）を有効化
vault secrets enable -path=secret -version=2 kv

# シークレット投入と参照（v2 は data/ を使う）
vault kv put secret/app/config db_user=demo db_pass=s3cr3t
vault kv get secret/app/config

# AppRole を有効化し、ポリシーを付与
vault auth enable approle

cat > app.hcl <<'EOF'
path "secret/data/app/*" {
  capabilities = ["read", "list"]
}
EOF

vault policy write app app.hcl

vault write auth/approle/role/myapp \
  token_policies="app" \
  token_ttl="30m" \
  token_max_ttl="4h" \
  secret_id_ttl="30m" \
  secret_id_num_uses=1

Exercise: An App Retrieves a Secret via AppRole

In this exercise, you obtain a client token using AppRole's RoleID/SecretID and read a secret from KV v2 end-to-end. For the exam, being able to diagram where each token/lease is issued and what can be renewed/revoked is a strong advantage.

Single-use SecretIDs (num_uses=1) and short TTLs are basic tactics in both learning and real work. Keep the leak surface small and design with rotation in mind.

• RoleID is an identifier, SecretID is the credential to present (distribute over secure channels)
• The client token obtained from AppRole login is granted the policy's permissions
• Run vault token renew before TTL expires, and revoke when no longer needed

A sequence of commands to log in via AppRole and read KV

# RoleID と SecretID を取得
ROLE_ID=$(vault read -field=role_id auth/approle/role/myapp/role-id)
SECRET_ID=$(vault write -field=secret_id auth/approle/role/myapp/secret-id)

echo "ROLE_ID=$ROLE_ID"
echo "SECRET_ID=$SECRET_ID"

# AppRole ログインでクライアントトークン取得
APP_TOKEN=$(vault write -field=token auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID")

echo "APP_TOKEN=$APP_TOKEN"

# アプリ視点で KV 読み取り（ポリシーの許可範囲のみ）
VAULT_TOKEN="$APP_TOKEN" vault kv get secret/app/config

# TTL 確認と更新
VAULT_TOKEN="$APP_TOKEN" vault token lookup
VAULT_TOKEN="$APP_TOKEN" vault token renew

# 使い終わったら明示的に取り消し
VAULT_TOKEN="$APP_TOKEN" vault token revoke -self

Common Pitfalls in the Free Tier and How to Handle Them

Most connectivity failures come from an outdated IP allow list, or your global IP changing at work/home. First, re-check the Allowed CIDR in the HCP console. Certificate errors are typically caused by typos in VAULT_ADDR or proxy interference.

For tokens, operations fail due to TTL exceeded or insufficient policies. Use vault token lookup to check the current TTL and policies, renew if needed, and revoke tokens that are unnecessary by design. After finishing, stop/delete the cluster to prevent cost incidents.

• HTTP 403/timeout: check the IP allow list, security groups, and possible region mismatches
• permission denied: review the path and capabilities in the policy (watch for data/ vs metadata/ mix-ups)
• clock skew: check your device's time sync (NTP). It affects TTL verification
• Reissuing the initial token: the HCP-side workflow (regeneration / whether support is needed) varies by time period, so refer to the console and official documentation

Frequently used verification commands

# ステータス/診断
vault status

# トークンとポリシーの確認
vault token lookup

# ポリシーの中身を確認
vault policy read app

# KV v2 のメタデータを確認
vault list secret/metadata/app/

# 監査（ローカル dev で練習）
# vault audit enable file file_path=/tmp/vault_audit.log

Check Your Understanding

Frequently Asked Questions