You Can Pass This Exam For Free
Choose Your Study Path
Limited experience with HashiCorp tools or secrets management. You need to learn both Vault fundamentals and infrastructure security concepts from scratch.
Week 1Install Vault locally, start a dev server (vault server -dev), and follow the Getting Started tutorials. Learn the CLI basics: vault status, vault login, vault kv put/get. Understand the concept of secrets management and why plaintext secrets are dangerous.
Week 2Study authentication methods: userpass, AppRole, LDAP, JWT/OIDC. Understand the difference between human auth methods (userpass, LDAP) and machine auth methods (AppRole, AWS, Kubernetes). Practice enabling and configuring auth methods via CLI and API.
Week 3Deep dive into Vault policies: learn HCL policy syntax, path matching (exact, glob, plus sign wildcards), and capabilities (create, read, update, delete, list, sudo, deny). Practice writing policies for different access patterns.
Week 4Study tokens: service vs batch tokens, root tokens, orphan tokens, periodic tokens, token accessors, TTL and max TTL. Understand the token hierarchy and what happens when a parent token is revoked. Study leases: lease IDs, renewal, and revocation.
Week 5Master secrets engines: KV v1 vs KV v2, dynamic secrets with the Database engine, Transit engine for encryption as a service, PKI for certificate generation. Learn response wrapping and cubbyhole. Practice enabling engines at custom paths.
Week 6Study Vault architecture: seal/unseal process, Shamir's Secret Sharing, auto-unseal with cloud KMS, storage backends (Integrated Storage/Raft vs Consul). Learn deployment models: self-managed clusters vs HCP Vault Dedicated. Study Vault Agent and Vault Secrets Operator.
Week 7Take full practice exams. Review all incorrect answers, especially on secrets engines (20% weight) and authentication methods (15% weight). Re-study any domain where you score below 70%.
Week 8Final review: focus on confusing pairs (service vs batch tokens, KV v1 vs v2, Shamir vs auto-unseal), CLI commands, and API paths. Take another practice exam aiming for 80%+. Schedule your real exam.
Exam Overview
Format
57 questions, 60 minutes. Multiple choice, multiple answer, and true/false questions.
Scoring
Passing score is approximately 70%. No penalty for wrong answers -- always answer every question.
Domains & Weights
- Authentication Methods15%
- Vault Policies13%
- Vault Tokens15%
- Vault Leases7%
- Secrets Engines20%
- Encryption as a Service5%
- Vault Architecture Fundamentals8%
- Vault Deployment Architecture12%
- Access Management Architecture5%
Registration
$70.5 USD. Online proctored exam administered through Certiverse (HashiCorp's own exam portal, replacing PSI in May 2024). Exam fee is $70.50 USD. Available in English only.
Topic Priority Table
Not all topics are tested equally. Focus your study time on Tier 1 first, then Tier 2. Tier 3 topics rarely appear — just recognize what they do.
Domain 115% of exam
Authentication Methods
This domain covers how users and machines prove their identity to Vault. You must understand the different authentication methods, when to use each one, and the distinction between human and machine auth methods. Identity entities and groups allow mapping multiple auth methods to a single identity.
Key Topics
UserpassLDAPAppRoleOIDC/JWTAWS AuthKubernetes AuthIdentity EntitiesGroups
Must-Know Concepts
- Authentication methods are pluggable components that verify identity and return a Vault token upon successful authentication
- Human auth methods (userpass, LDAP, OIDC) require interactive login; machine auth methods (AppRole, AWS, Kubernetes) enable automated authentication
- AppRole uses role_id (like a username, relatively static) and secret_id (like a password, can be dynamic and single-use) for machine authentication
- Identity entities represent a single person or machine across multiple auth methods; groups aggregate entities for unified policy assignment
- You can authenticate via CLI (vault login), API (POST to /v1/auth/<method>/login), or UI (web interface login form)
- Auth methods must be explicitly enabled before use (vault auth enable <method>) and can be mounted at custom paths
- Each auth method maps to policies that determine what the resulting token can access
Common Exam Traps
AppRole is a MACHINE auth method, not a human one. Do not confuse it with userpass just because it has an ID and secret
Multiple auth methods can map to the same identity entity, allowing a user who logs in via LDAP and userpass to have a unified identity
The token auth method is always enabled and cannot be disabled. It is the only built-in auth method
Auth methods at custom paths must be referenced by their custom path, not the default method name
Domain 213% of exam
Vault Policies
Policies are the primary authorization mechanism in Vault. Written in HCL, they define what paths a token can access and what capabilities (create, read, update, delete, list, sudo, deny) are allowed. Understanding policy syntax, path matching, and the default-deny behavior is critical.
Key Topics
HCL Policy SyntaxPath MatchingCapabilitiesDefault PolicyRoot PolicyPolicy CLI Commands
Must-Know Concepts
- Vault uses a default-deny model: if no policy explicitly grants access to a path, access is denied
- Policy capabilities: create, read, update, delete, list, sudo (access protected paths), deny (explicit denial that overrides all other capabilities)
- Path matching: exact paths, glob patterns (* matches any suffix), and single-segment wildcards (+ matches exactly one path segment)
- The root policy grants unlimited access and cannot be modified or deleted. It should only be attached to root tokens
- The default policy is attached to all tokens by default and grants basic self-management capabilities (token lookup, renewal, etc.)
- Policies are configured via CLI (vault policy write <name> <file>) or UI and take effect immediately -- no restart required
- Multiple policies on a token are additive (union of permissions), but deny always wins
Common Exam Traps
The + wildcard matches exactly ONE path segment, not multiple. path "kv/+/data" matches kv/team1/data but NOT kv/team1/team2/data
The * glob only works at the END of a path. It matches any suffix. path "secret/*" matches secret/foo and secret/foo/bar
deny capability overrides ALL other capabilities, even if another policy grants access to the same path
The default policy is automatically attached to all tokens. Removing it from a token is possible but rarely appropriate
Domain 315% of exam
Vault Tokens
Tokens are the core authentication mechanism in Vault. Every request requires a token. This domain tests your understanding of token types (service, batch, root, orphan, periodic), token hierarchy, TTLs, accessors, and when to use each type. This is the second-heaviest domain alongside authentication methods.
Key Topics
Service TokensBatch TokensRoot TokensOrphan TokensPeriodic TokensToken AccessorsTTLMax TTL
Must-Know Concepts
- Service tokens are persisted to storage, renewable, have parent-child relationships, and support all Vault features (accessors, cubbyhole, etc.)
- Batch tokens are NOT persisted, NOT renewable, have no parent-child relationships, and are designed for high-volume ephemeral workloads
- Root tokens have no TTL, no max TTL, and access everything. They should be revoked after initial setup and regenerated only when needed
- Orphan tokens have no parent. When a parent token is revoked, all child tokens are also revoked -- but orphan tokens survive parent revocation
- Periodic tokens have a period instead of a max TTL. They can be renewed indefinitely as long as renewal happens within each period
- Token accessors allow lookup, renewal, and revocation of tokens without knowing the actual token value -- useful for audit and management
- TTL (time-to-live) determines how long a token is valid. Max TTL is the absolute maximum lifetime a token can reach through renewals
Common Exam Traps
Batch tokens CANNOT be renewed, CANNOT have child tokens, and CANNOT use cubbyhole. If any question mentions these features, the answer is service tokens
Revoking a parent token revokes ALL child tokens recursively. Only orphan tokens are exempt from this cascading revocation
Root tokens can be regenerated using unseal keys (or recovery keys with auto-unseal) via vault operator generate-root, even after the original root token is revoked
A token with num_uses: 1 can only be used exactly once, regardless of its remaining TTL
Domain 47% of exam
Vault Leases
Leases are Vault's mechanism for tracking the lifecycle of dynamic secrets. Every dynamic secret has a lease with an ID, a TTL, and the ability to be renewed or revoked. Understanding lease management is essential for operating dynamic secrets engines like Database and PKI.
Key Topics
Lease IDsLease RenewalLease RevocationTTLDynamic Secret Lifecycle
Must-Know Concepts
- Every dynamic secret comes with a lease that includes a unique lease ID and a TTL
- Lease IDs are used to manage the lifecycle of dynamic secrets: renew to extend, revoke to immediately invalidate
- Renewing a lease extends the TTL, but not beyond the max TTL configured on the secrets engine or mount
- Revoking a lease immediately invalidates the dynamic secret (e.g., the database credentials are deleted)
- When a lease expires without renewal, Vault automatically revokes the associated secret
- Lease management commands: vault lease renew <lease_id>, vault lease revoke <lease_id>, vault lease revoke -prefix <path>
Common Exam Traps
Static secrets in the KV engine do NOT have leases. Only dynamic secrets (Database, PKI, etc.) have leases
Revoking a lease does not just invalidate the Vault record -- it also cleans up the actual resource (e.g., drops the database user)
The -prefix flag on lease revoke allows revoking ALL leases under a path, which is useful during incident response
Domain 520% of exam
Secrets Engines
Secrets engines are the core of Vault's functionality. This is the heaviest domain at 20%, covering KV (v1 and v2), Database, Transit, PKI, and other engines. You must understand when to use each engine, the difference between static and dynamic secrets, response wrapping, and how to enable and manage engines via CLI, API, and UI.
Key Topics
KV v1/v2Database EngineTransit EnginePKI EngineCubbyholeResponse WrappingDynamic Secrets
Must-Know Concepts
- Secrets engines are enabled at specific paths and each path is isolated. You can enable multiple instances of the same engine at different paths
- KV v1 stores key-value pairs with no versioning. KV v2 adds versioning, soft delete, metadata, and check-and-set (CAS)
- The Database secrets engine generates dynamic, short-lived database credentials that are automatically revoked when leases expire
- The Transit secrets engine provides encryption as a service: encrypt, decrypt, and manage keys WITHOUT storing the data itself in Vault
- Response wrapping provides a single-use wrapping token that references the actual secret, so only a token ID traverses the network
- Cubbyhole is a token-scoped secrets engine: each token has a private cubbyhole that dies with the token. Used internally by response wrapping
- Dynamic secrets provide unique credentials per consumer with automatic revocation, eliminating shared credential risks
- Enable secrets engines: vault secrets enable [-path=custom] <engine>. List enabled engines: vault secrets list
Common Exam Traps
The Transit engine does NOT store data in Vault. It only performs cryptographic operations. The application must persist the ciphertext elsewhere
KV v2 is NOT the default version when enabling the KV engine on non-dev servers -- running 'vault secrets enable kv' without flags enables KV v1. To enable KV v2 explicitly, use 'vault secrets enable kv-v2' or specify -version=2
Destroying a KV v2 version permanently removes the data. Deleting only soft-deletes (data can be undeleted). Know the difference
Response wrapping tokens are single-use: unwrapping a second time returns an error, which indicates potential interception
Each secrets engine mount is completely isolated. Secrets at kv/ and kv-prod/ are separate even if both are KV engines
Domain 65% of exam
Encryption as a Service
This domain focuses specifically on the Transit secrets engine for cryptographic operations. You must know how to encrypt, decrypt, and rotate encryption keys. While only 5% of the exam, questions here are straightforward if you understand the Transit engine well.
Key Topics
Transit EngineEncrypt/DecryptKey RotationRewrappingConvergent Encryption
Must-Know Concepts
- Encrypt: vault write transit/encrypt/<key-name> plaintext=$(base64 <<< 'data') returns ciphertext prefixed with vault:v1:
- Decrypt: vault write transit/decrypt/<key-name> ciphertext=vault:v1:... returns base64-encoded plaintext
- Key rotation creates a new version of the encryption key. New encryptions use the latest key version. Old ciphertext can still be decrypted
- Rewrapping updates ciphertext to use the latest key version without exposing the plaintext to the client
- The ciphertext prefix vault:v1: indicates the key version used for encryption. After rotation, new ciphertext shows vault:v2:
Common Exam Traps
Transit decrypt returns base64-encoded plaintext, NOT raw plaintext. You must base64 decode the response to get the original data
Key rotation does NOT invalidate old ciphertext. Old versions of the key are retained for decryption. You must use min_decryption_version to force re-encryption
Transit does NOT store any data. It is purely a cryptographic service. The application must store the ciphertext
Domain 78% of exam
Vault Architecture Fundamentals
This domain covers how Vault works internally: how data is encrypted, the seal/unseal process, and environment variable configuration. Understanding these fundamentals is critical for the deployment and operations questions throughout the exam.
Key Topics
Encryption BarrierSeal/UnsealShamir's Secret SharingMaster KeyEnvironment Variables
Must-Know Concepts
- Vault encrypts all data before writing it to storage. The storage backend never sees plaintext data
- The encryption barrier is the cryptographic layer between Vault and its storage backend. All data passes through this barrier
- When sealed, Vault has access to encrypted data in storage but cannot decrypt it. Only the unseal process restores the encryption key
- Shamir's Secret Sharing splits the master key into N shares with threshold K. Any K shares can reconstruct the master key
- During initialization, Vault generates a master key and encryption key. The master key encrypts the encryption key, and Shamir splits the master key
- Key environment variables: VAULT_ADDR (server URL), VAULT_TOKEN (auth token), VAULT_NAMESPACE (enterprise namespace), VAULT_SKIP_VERIFY (skip TLS verification)
Common Exam Traps
When Vault is sealed, it CAN access physical storage but CANNOT read (decrypt) the data. This is a commonly tested true/false question
Sealing Vault requires sudo capability on sys/seal. It is a protected operation
VAULT_ADDR must be set before any CLI operation. Without it, the CLI does not know which Vault server to contact
Vault never stores the master key. It only exists in memory when Vault is unsealed and is reconstructed from Shamir shares each time
Domain 812% of exam
Vault Deployment Architecture
This domain covers how Vault is deployed in production: self-managed clusters vs HCP Vault, storage backends, Shamir vs auto-unseal, and replication strategies. Understanding deployment tradeoffs is essential for scenario-based questions.
Key Topics
Self-Managed VaultHCP Vault DedicatedIntegrated Storage (Raft)Consul BackendAuto-UnsealDR ReplicationPerformance Replication
Must-Know Concepts
- Self-managed Vault: organization installs, configures, and maintains Vault clusters. Full control but full operational burden
- HCP Vault Dedicated: HashiCorp manages the infrastructure, upgrades, and operations. Organizations consume Vault as a service
- Integrated Storage (Raft) is the recommended storage backend. It uses Raft consensus and requires no external dependencies
- Consul storage backend requires a separate Consul cluster. Still supported but adds operational complexity
- Auto-unseal uses a trusted KMS (AWS KMS, Azure Key Vault, GCP KMS) to automatically unseal Vault on restart. Recovery keys replace unseal keys
- DR replication creates passive standby clusters for failover. Performance replication creates active read replicas for scaling
- Shamir's Secret Sharing is the default unseal mechanism. Auto-unseal is preferred for production to eliminate manual intervention
Common Exam Traps
With auto-unseal, the unseal keys are replaced by recovery keys. Recovery keys CANNOT unseal Vault -- they are used for operations like root token generation
HCP Vault Dedicated is NOT the same as a dev server. It is a production-grade managed service with HA, backup, and monitoring
DR replication secondaries do NOT serve read requests during normal operation. Only performance replication secondaries serve reads
Raft requires a minimum of 3 or 5 nodes for production HA. A single Raft node provides no HA benefit
Domain 95% of exam
Access Management Architecture
This smaller domain covers Vault Agent and Vault Secrets Operator (VSO), which simplify how applications consume Vault secrets. Vault Agent handles auto-auth and caching for general workloads, while VSO provides Kubernetes-native secret synchronization.
Key Topics
Vault AgentAuto-AuthCachingTemplate RenderingVault Secrets OperatorKubernetes Secrets Sync
Must-Know Concepts
- Vault Agent is a client-side daemon that handles auto-authentication, token lifecycle management, caching, and template rendering
- Auto-auth allows Vault Agent to automatically authenticate to Vault and manage token renewal without application involvement
- Agent caching reduces API calls to the Vault server by caching responses locally
- Agent templates render Vault secrets into configuration files using Go template syntax
- Vault Secrets Operator (VSO) is a Kubernetes operator that syncs Vault secrets into native Kubernetes Secret objects
- VSO features include instant updates (watching for secret changes), encrypted client cache, and secret transformation
Common Exam Traps
Vault Agent works on ANY platform (VMs, containers, bare metal). VSO is ONLY for Kubernetes
Agent caching does not make the agent a mini-Vault. Cached responses are forwarded from the actual Vault server
VSO creates native Kubernetes Secrets, so applications do not need Vault client libraries -- they consume secrets through standard Kubernetes mechanisms
Vault Concepts You Must Not Confuse
These pairs appear on nearly every exam. Learn the difference and you'll avoid the most common traps.
Top Mistakes to Avoid
Confusing service tokens (persisted, renewable, full-featured) with batch tokens (lightweight, not persisted, not renewable) -- know which features each supports
Thinking key rotation in Transit invalidates old ciphertext -- old key versions are retained for decryption until explicitly removed
Mixing up KV v1 (no versioning, destructive writes) with KV v2 (versioned, soft delete, metadata, CAS)
Forgetting that Transit does NOT store data in Vault -- it only performs cryptographic operations and the app must persist ciphertext
Confusing disaster recovery replication (passive standby for failover) with performance replication (active read replicas for scaling)
Thinking auto-unseal eliminates the master key -- it delegates key management to a KMS but still uses an encryption key hierarchy
Not understanding that orphan tokens survive parent token revocation while normal child tokens do not
Confusing the + wildcard (matches exactly one path segment) with the * glob (matches any suffix at end of path) in policy paths
Assuming Vault Agent is Kubernetes-only -- it works on any platform; VSO is the Kubernetes-specific component
Forgetting that Transit decrypt returns base64-encoded plaintext, not raw text -- you must decode it
Thinking the default policy can be removed from Vault -- it can be detached from tokens but cannot be deleted from the system
Not knowing that AppRole is a machine auth method, not a human auth method, despite having user-like concepts (role_id/secret_id)
Exam-Ready Checklist
Can explain all 9 exam domains and their relative weights (15%, 13%, 15%, 7%, 20%, 5%, 8%, 12%, 5%)
Understand the difference between service tokens, batch tokens, root tokens, orphan tokens, and periodic tokens
Can write Vault policies with correct path matching (exact, +, *) and capabilities (create, read, update, delete, list, sudo, deny)
Know the complete seal/unseal process: Shamir's Secret Sharing, threshold vs shares, auto-unseal with KMS, recovery keys
Can choose the correct auth method for any scenario: human (userpass, LDAP, OIDC) vs machine (AppRole, AWS, Kubernetes)
Understand all major secrets engines: KV v1/v2, Transit, Database, PKI, Cubbyhole -- and when to use each
Can explain Transit encryption, decryption, key rotation, and rewrapping -- including that data is NOT stored in Vault
Know the deployment architecture differences: self-managed vs HCP Vault, Raft vs Consul, DR vs performance replication
Understand Vault Agent (auto-auth, caching, templates) and VSO (Kubernetes secret sync) and when to use each
Can explain response wrapping: how it works, why it is secure (single-use, short TTL, only reference on network)
Know lease lifecycle: lease IDs, renewal, revocation, automatic cleanup of dynamic secrets
Scored 70%+ on at least two full practice exams covering all 9 domains
Recommended Resources
Free & Official Resources
Paid Courses & Practice Exams
These are recommended if you prefer a structured learning path. They can save time but are not required to pass.