HashiCorp Certified: Vault Associate Intermediate — Quiz 2 Study Guide

HashiCorp Vault is the industry-standard tool for secrets management, and understanding how it controls *who* can access *what* — and for *how long* — is the foundation of every real-world deployment. This guide covers the core concepts you'll need to ace Quiz 2, from policies and authentication methods to dynamic secrets and audit logging.

---

Vault Architecture Overview

Vault is built around a few key components:

Storage Backend — where encrypted secrets are persisted (e.g., Consul, S3, DynamoDB)

Secrets Engines — plugins that store, generate, or encrypt data

Auth Methods — plugins that authenticate users/applications and issue tokens

Policies — rules that define what a token is allowed to do

Audit Devices — log every request and response for compliance

Think of Vault as a bank vault: auth methods are the ID check at the door, policies are the permissions slip that says which safety deposit boxes you can open, and audit logging is the security camera recording everything.

Namespaces

Namespaces allow multi-tenancy within a single Vault cluster. Each namespace is an isolated environment with its own policies, auth methods, and secrets engines — ideal for large enterprises separating teams or business units.

---

Identity and Access Management (IAM)

Vault's IAM features answer the question: "Who are you, and what are you allowed to do?"

The primary purpose of Vault IAM is to centralize and control access to secrets across multiple platforms, teams, and cloud providers — replacing scattered, hard-coded credentials with a unified access control layer.

Vault IAM components include:

Entities — a logical user or application identity

Aliases — links between an entity and a specific auth method login

Groups — collections of entities that share policies

---

Authentication Methods

Authentication is how Vault verifies identity. Once verified, Vault issues a token that is used for all subsequent requests.

Common Auth Methods

AWS Auth Method

The AWS auth method allows users and applications to authenticate using their existing AWS IAM credentials (IAM roles, EC2 instance profiles, or IAM users). This is the answer when a question asks about authenticating with "existing cloud provider credentials."

AppRole Auth Method

AppRole is designed for applications and automated pipelines. It uses two credentials:

RoleID — like a username (not secret, can be baked into an image)

SecretID — like a password (secret, injected at runtime)

# Fetch a token using AppRole
vault write auth/approle/login \
  role_id="your-role-id" \
  secret_id="your-secret-id"

LDAP Auth Method

LDAP lets users log in with their corporate directory credentials (Active Directory, OpenLDAP). Vault maps LDAP groups to Vault policies automatically.

---

Policies

A Vault Policy is an HCL (or JSON) document that defines what actions a token is permitted to perform on specific paths.

Path and Capabilities

Every policy rule has two parts:

path — the Vault API path being controlled (e.g., secret/data/myapp/*)

capabilities — the allowed operations on that path

# Example Vault Policy
path "secret/data/myapp/*" {
  capabilities = ["read", "list"]
}
path "auth/token/renew-self" {
  capabilities = ["update"]
}

Capabilities Reference

token_ttl in Policies

The token_ttl setting within a policy (or role) controls how long a token issued under that policy remains valid before it must be renewed or expires. This is a security control to limit the blast radius of a compromised token.

# Role with token TTL settings
vault write auth/approle/role/my-role \
  token_ttl=1h \
  token_max_ttl=4h \
  policies="my-policy"

---

Tokens and Leases

Tokens

Every authenticated session in Vault is represented by a token. Tokens:

Are the *only* way to interact with Vault after authentication

Have a TTL (time-to-live) and can be renewed

Can be periodic (renewable indefinitely) or non-periodic

Can create child tokens (forming a token hierarchy)

Leases

When Vault generates a dynamic secret, it creates a lease — a binding contract that includes:

A lease ID to reference the secret

A TTL after which the secret expires

The ability to renew or revoke the secret early

# Renew a lease
vault lease renew <lease-id>
Revoke a lease immediately
vault lease revoke <lease-id>

---

Secret Engines

Secret engines are the workhorses of Vault. Key types include:

KV (Key/Value) — store static secrets; v2 supports versioning

Dynamic Secrets (AWS, Database, etc.) — generate short-lived credentials on demand

PKI — issue TLS certificates

Transit — encryption-as-a-service (think KMS)

KMS — integrates with cloud KMS providers (AWS KMS, GCP CKMS) for key management and auto-unseal

Dynamic Secrets

Dynamic secrets are generated on-demand and automatically expire. For example, the AWS secrets engine can create a temporary IAM access key that expires after 1 hour — no long-lived credentials stored anywhere.

---

Audit Logging

Audit devices record every request and response to Vault, including:

Who made the request (token/entity)

What path was accessed

What the result was (success/error)

Sensitive values are hashed in audit logs by default. Vault requires at least one audit device to be active for security compliance. Common backends: file, syslog, socket.

---

Security Best Practices

Use short TTLs and dynamic secrets to minimize exposure

Enable audit logging on all production clusters

Apply least-privilege policies — only grant what's needed

Use namespaces to isolate teams and environments

Rotate the root token immediately after initial setup

---

Troubleshooting Tips

403 Permission Denied → Check the token's attached policies and the path/capabilities

Token expired → Check token_ttl and token_max_ttl settings

Sealed Vault → Vault needs to be unsealed with the required number of unseal keys (or auto-unseal via KMS)

Use vault token lookup to inspect a token's policies and TTL

Use vault audit list to verify audit devices are enabled

---

Key Takeaways

Policies define *what* a token can do using path + capabilities; token_ttl controls how long that token lives.

Auth methods (AWS, AppRole, LDAP) verify identity and issue tokens; the AWS method specifically uses existing cloud IAM credentials.

Dynamic secrets generate short-lived credentials on demand with leases, drastically reducing the risk of credential exposure.

Namespaces enable multi-tenancy, while audit logging ensures every action is recorded for compliance.

The core Vault flow is always: Authenticate → Get Token → Use Token (governed by Policy) → Secret Expires via Lease.