HC-002

Vault Associate (002) Exam Details

Exam Objective Domains

What Is HashiCorp Vault?

HashiCorp Vault is a secrets management tool that provides a unified interface to any secret, while providing tight access control and recording a detailed audit log. Vault handles leasing, key revocation, key rolling, and auditing. It can manage static secrets, dynamically generate credentials for databases and cloud providers, and provide encryption as a service without exposing encryption keys.

Exam Tip: Vault's four key use cases are: secrets management, data encryption, identity-based access, and key management. Understand how each maps to Vault features.

Vault Architecture Components

Seal/Unseal Process

When Vault starts, it is in a sealed state. It knows where the encrypted data is stored, but cannot decrypt it. Unsealing requires providing enough unseal keys to reconstruct the master key.

Exam Tip: Sealing Vault (vault operator seal) throws away the master key from memory and requires unseal keys again. This is an emergency measure. Auto unseal reduces operational burden but shifts trust to the KMS provider.

Initialization & Key Ceremony

The root token generated during init has unlimited permissions. It should be revoked after initial setup and regenerated only when needed via vault operator generate-root.

Storage Backends

Exam Tip: Integrated Storage (Raft) is the recommended production backend. It provides HA without external dependencies. Dev mode uses in-memory storage (data lost on restart).

Dev Server Mode

Running vault server -dev starts Vault in development mode with several convenience features:

• Automatically initialized and unsealed
• In-memory storage (no data persisted)
• Listens on localhost:8200 without TLS
• Root token is printed to stdout
• KV v2 secret engine mounted at secret/
• Never use dev mode in production

Authentication Methods

Auth methods verify client identity and assign Vault policies. Multiple auth methods can be enabled simultaneously. Each is mounted at a unique path.

Exam Tip: Token auth is ALWAYS enabled and cannot be disabled. AppRole is the recommended method for machine-to-machine authentication. Every successful auth produces a Vault token.

Auth Method CLI Commands

Token Types & Properties

Token Hierarchy & Orphan Tokens

Service tokens form a parent-child tree. When a parent token is revoked, all its children and their leases are also revoked. Orphan tokens have no parent and are not revoked when the creating token expires.

Token TTL & Max TTL

TTL (Time To Live): How long a token is valid. Can be renewed before expiry. Max TTL: Hard ceiling -- token cannot be renewed past this time. Once max TTL is reached, the token expires permanently and a new one must be obtained.

Default TTL is 32 days (768h). The system max TTL is also 32 days. Both can be tuned per auth method mount or per role.

Exam Tip: A token with period set (periodic token) can be renewed indefinitely as long as it is renewed within its period. Periodic tokens never hit a max TTL. They are useful for long-running services.

Vault Policies Overview

Policies define what a client can access. They are written in HCL (or JSON) and provide path-based access control. Vault follows a deny by default model -- if no policy grants access, it is denied.

Policy Capabilities

Exam Tip: deny always wins. If ANY policy attached to a token denies access to a path, it is denied regardless of what other policies allow. Policies are additive for all other capabilities.

Policy Syntax Examples

Policy CLI Commands

Path Templating

Policies support templated paths using identity information. This enables policies that dynamically scope access based on the authenticated entity.

Exam Tip: Path globs: * matches any characters within a single path segment. + is a single-segment wildcard in path patterns. Paths are matched most-specific-first.

Audit Devices

Audit devices record every Vault operation. Vault requires at least one enabled audit device before it will process requests (if any are configured). If all audit devices fail, Vault becomes unresponsive to prevent unaudited access.

Sensitive data in audit logs is HMAC-hashed by default (not plain text). This allows log correlation without exposing secrets.

Secret Engine Types

Secret engines are mounted at a path and responsible for storing, generating, or encrypting data. Each engine is isolated; secrets at secret/ are completely separate from those at database/.

KV v1 vs KV v2

Exam Tip: KV v2 adds data/ and metadata/ path prefixes to the API. The CLI abstracts this, but policies must reference the full API path (e.g., secret/data/myapp).

Secret Engine CLI Commands

Dynamic Secrets & Leases

Dynamic secrets are generated on-demand and automatically revoked after their lease expires. Every dynamic secret has a lease with a lease ID, TTL, and renewability.

Exam Tip: Dynamic secrets reduce risk because credentials are short-lived and unique per client. If compromised, they expire automatically. Revoking a lease immediately invalidates the credentials.

Cubbyhole Secret Engine

Cubbyhole is a special engine that provides token-scoped secret storage. Each token has its own cubbyhole that no other token can access. When the token is revoked or expires, its cubbyhole is destroyed. This is used for secure secret introduction patterns (response wrapping).

Response Wrapping: Any Vault response can be wrapped in a single-use wrapping token using -wrap-ttl. The wrapped response is stored in the wrapping token's cubbyhole and can only be unwrapped once. This provides secure zero-knowledge secret delivery.

Transit Secret Engine (Encryption as a Service)

The Transit engine provides cryptographic operations on data in-transit. It handles encryption, decryption, signing, verification, and key management without exposing encryption keys. Applications send data to Vault for encryption and receive ciphertext back -- keys never leave Vault.

Key Rotation & Versioning

Transit supports key rotation. When a key is rotated, a new version is created. New encryptions use the latest version, but old ciphertext can still be decrypted with previous versions. The ciphertext prefix (vault:v1:, vault:v2:) indicates which key version was used.

• min_decryption_version -- oldest key version allowed for decryption
• min_encryption_version -- oldest key version allowed for encryption
• Rewrap re-encrypts ciphertext with the latest key version without exposing plaintext to the client

Exam Tip: Key rotation does NOT re-encrypt existing data. You must use the rewrap endpoint to update existing ciphertext to the latest key version. Old key versions are retained for decryption until min_decryption_version is advanced.

Transit Key Types

Vault API

All Vault operations are available via a RESTful HTTP API. The CLI is a thin wrapper around the API. Authentication is via the X-Vault-Token header.

Vault Agent & Environment Variables

Vault Agent: A client-side daemon that handles token renewal, secret caching, and template rendering. It can auto-auth with Vault and populate config files with secrets using templating.

Exam Tip: VAULT_ADDR and VAULT_TOKEN are the two most commonly needed env vars. In production, always use TLS. The vault status command checks if Vault is sealed/unsealed and does not require authentication.