HashiCorp Vault Associate & Operations Professional

Every platform eventually runs into the same wall: you can put everything in Git except the passwords. HashiCorp Vault is the most widely deployed answer to that problem, and HashiCorp sells two certifications for it — a one-hour multiple-choice Vault Associate (003) and a four-hour, lab-based Vault Operations Professional. This page is a verified, unsentimental guide to both: what they actually test, what they cost, how their objectives map onto the platform work covered elsewhere on this site — and, just as importantly, the cases where you should spend the same weekend on something else.

What these credentials are, and where they sit

☺ Like you’re 10: Two badges from the company that makes Vault — a beginner one you answer questions for, and a hard one where you actually do the work.

Both credentials are issued by HashiCorp, the vendor that builds Vault. That is the first thing to internalise: unlike the CNCF exams covered on the certifications hub, these are vendor certifications about a specific product. They are not neutral surveys of the secrets-management landscape. They test how Vault does things, in Vault’s vocabulary, at the Vault version the exam is pinned to.

Two rungs, one ladder

HashiCorp groups its exams into two tracks — Infrastructure Automation (Terraform, covered on the Terraform certification page) and Security Automation, where the Vault pair lives. The Associate is the entry rung: one hour, online-proctored, multiple choice, for engineers who understand Vault’s concepts and can drive it from the CLI, API and UI. The Operations Professional is a different animal — a long, hands-on exam that drops you into a pre-provisioned Linux box to build, harden and operate Vault, including a meaningful chunk of Vault Enterprise functionality.

Per the official pages, as of writing, both exams test against Vault 1.16 and both certifications are valid for two years. The Associate is “strongly recommended” but not formally required before the Professional.

Who they are aimed at

HashiCorp frames the Associate at cloud engineers who know Vault’s basic concepts and use cases, assuming terminal skills, some infrastructure understanding and introductory security knowledge. The Professional expects considerably more: Linux administration, IP networking, PKI experience, information-security fundamentals and container infrastructure. That last prerequisite is what makes this page relevant to you — the Professional explicitly includes an objective on the security implications of running Vault in Kubernetes.

Why a platform engineer might take it — and when to skip

☺ Like you’re 10: Learn the safe if your school actually has that safe. If your school uses a different safe, learn that one instead.

Here is the honest case for. Secrets are the hardest unsolved corner of GitOps: everything else about a platform can be a file in a repo, and the plaintext credential cannot. The Vault Associate curriculum is, almost by accident, a very good tour of the concepts that fix this — dynamic short-lived credentials, leases and renewal, path-based authorisation, and workload identity via the Kubernetes auth method. Those ideas transfer to AWS Secrets Manager, Google Secret Manager, Azure Key Vault and the External Secrets Operator even when the commands do not. If your organisation already runs Vault, the Associate is cheap, fast, and turns folklore into a mental model.

When to skip it — properly

And here is the honest case against, which most study sites will not give you:

• You don’t run Vault, and you won’t. If your platform is single-cloud and your secrets live in the cloud provider’s own manager, this is vendor-locked knowledge. You will learn genuinely useful patterns, but you will be examined on Vault path syntax you never type again. Read Secrets Management and External Secrets instead and spend the money on the exam your platform actually needs.
• You are mid-CNPE or mid-CNPA. Neither Vault exam substitutes for the CNCF ladder. If your next twelve weeks are budgeted, finish the CNPE or CNPA first — they cover secrets at exactly the depth those exams test, and they are the credential a platform-engineering hiring manager is looking for.
• Half the Professional is Enterprise-only. Look closely at the Ops Pro objectives below: disaster-recovery replication, performance replication, performance standby nodes, paths filters, Sentinel policies, control groups, namespaces and HSM seal wrap are all explicitly marked (Vault Enterprise). If your employer will never buy an Enterprise licence, you are paying to learn features you cannot use. That is a legitimate reason to stop at the Associate.
• Both exams are pinned to an ageing Vault. HashiCorp states that the Associate (003) and the Operations Professional are both examined against Vault 1.16 — a release that shipped in April 2024, several minor versions behind the current release line. That is not a reason to avoid the exam, but it does mean you are certifying against a snapshot: newer features are not examinable, and a study guide written against today’s Vault will teach you behaviour the exam will not ask about. Check the pinned version on the official page before you buy anything.
• Licensing has moved under everyone’s feet. HashiCorp relicensed its products under the non-OSI Business Source License in 2023, which prompted a community fork — OpenBao, now developed in the open under Linux Foundation stewardship. If your organisation’s open-source policy is strict, confirm which binary you are actually allowed to run before you invest in product-specific certification. The concepts carry across; the support contract does not.

What the exams actually test

☺ Like you’re 10: The vendor publishes an exact list of what they’ll ask. Read the list, not somebody’s blog.

HashiCorp publishes a formal exam content list for each exam. The domains below are transcribed from those official pages. One important caveat before you build a study plan around percentages: HashiCorp does not publish domain weights for either exam. Anyone quoting you “Domain 5 is 22%” invented it.

Vault Associate (003) — nine objective areas

Notice objective 9. The Associate blueprint reaches directly into Kubernetes, and the two named artefacts — Vault Agent and the Vault Secrets Operator — are exactly the pieces a platform engineer wires into a cluster.

Vault Operations Professional — eight objective areas

Per the official orientation page, the Professional runs a Vault Enterprise binary, mixes lab scenarios with multiple-choice and “hybrid” questions that require inspecting the live environment, allows the Vault UI, Visual Studio Code and Vault’s own documentation during the exam, and currently requires a US English QWERTY keyboard layout. Labs may be completed in any order and each is scored independently.

The substance you actually need to know

☺ Like you’re 10: The safe locks itself when it restarts, you prove who you are to open it, and then it hands you keys that expire.

Seal, unseal, and how Vault protects itself

Vault encrypts everything it stores with a data-encryption key, itself encrypted by a master key. When Vault starts it is sealed — it holds the ciphertext but not the key, so it serves almost nothing. Unsealing reconstructs that key. Classic Vault uses Shamir secret sharing: initialisation splits the unseal key into n shares and requires a threshold of k to reassemble it, so no single operator can bring Vault up alone. In production you replace that ceremony with auto-unseal, delegating the wrapping key to a cloud KMS or HSM — which is why “auto unseal Vault” is its own Professional objective.

Auth methods, policies, tokens and leases

The flow is always the same shape. A human or a workload authenticates through an auth method (OIDC, LDAP, AppRole, or — for us — Kubernetes). Vault checks the identity, looks up its policies, and returns a token carrying them. The token has a TTL. Anything that token reads from a dynamic engine comes back with a lease, which also has a TTL and can be renewed or revoked. Revoke the lease and the underlying credential is destroyed at the source — that is the property that makes short-lived secrets safe.

# --- initialise and unseal (Shamir: 5 shares, any 3 unseal) -----------------
vault operator init -key-shares=5 -key-threshold=3
vault operator unseal      # run three times with three different shares
vault status               # Sealed: false

# --- Kubernetes auth: let a ServiceAccount become a Vault identity ----------
vault auth enable kubernetes
vault write auth/kubernetes/config \
    kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \
    kubernetes_ca_cert=@ca.crt \
    token_reviewer_jwt="$REVIEWER_JWT"

vault write auth/kubernetes/role/checkout \
    bound_service_account_names=checkout \
    bound_service_account_namespaces=payments \
    token_policies=checkout-read \
    token_ttl=1h
# note: the older `policies=` / `ttl=` spellings still work but the API docs
# mark `policies` DEPRECATED — write new roles with the token_* parameters

# --- KV v2: versioned static secrets (note the implicit data/ path) ---------
vault secrets enable -path=secret -version=2 kv
vault kv put -mount=secret checkout/config api_key=abc123
vault kv get -mount=secret -version=1 checkout/config
vault kv patch -mount=secret checkout/config log_level=debug
vault kv delete -mount=secret checkout/config        # soft delete, recoverable
vault kv undelete -mount=secret -versions=2 checkout/config
vault kv destroy  -mount=secret -versions=2 checkout/config   # unrecoverable

# --- database engine: credentials that did not exist a second ago -----------
vault secrets enable database
vault write database/config/orders \
    plugin_name="postgresql-database-plugin" \
    allowed_roles="orders-ro" \
    connection_url="postgresql://{{username}}:{{password}}@pg:5432/orders" \
    username="vaultadmin" password="s3cr3t"

vault write database/roles/orders-ro \
    db_name=orders \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" max_ttl="24h"

vault read database/creds/orders-ro     # → a brand-new user, leased for 1h
vault lease renew  database/creds/orders-ro/xxxx
vault lease revoke database/creds/orders-ro/xxxx

# --- transit: encryption as a service (Vault never stores your data) --------
vault secrets enable transit
vault write -f transit/keys/orders-pii
vault write transit/encrypt/orders-pii \
    plaintext=$(printf '%s' "4111-1111-1111-1111" | base64)   # printf, not echo:
                                                             # a trailing newline
                                                             # ends up in ciphertext
vault write -f transit/keys/orders-pii/rotate

KV v1 vs KV v2 — the trap everyone falls into

KV v1 is a flat key-value store: put, get, delete, gone. KV v2 adds versioning, soft delete that can be undeleted, hard destroy, per-secret metadata, and check-and-set writes. The exam-relevant gotcha is the path shape: on a v2 mount the API path is secret/data/<path> for values and secret/metadata/<path> for version history, even though the vault kv CLI hides that from you. Write a policy against secret/checkout/* on a v2 mount and it will silently grant nothing.

Policy syntax — path plus capabilities

Vault policies are HCL, deny-by-default, and made of paths carrying capabilities: create, read, update, patch, delete, list, sudo (for root-protected paths), deny, plus subscribe and recover. Per the official policy documentation, deny “always takes precedence regardless of any other defined capabilities, including sudo.” Paths match exactly, with * as a trailing glob and + as a single-segment wildcard; the most specific match wins.

# checkout-read.hcl — a least-privilege policy for one workload
# KV v2 values live under data/, history under metadata/
path "secret/data/checkout/*" {
  capabilities = ["read"]
}

path "secret/metadata/checkout/*" {
  capabilities = ["list", "read"]
}

# short-lived database credentials, on demand
path "database/creds/orders-ro" {
  capabilities = ["read"]
}

# a single-segment wildcard: any team, but only its own config
path "secret/data/teams/+/config" {
  capabilities = ["read"]
}

# belt and braces — deny beats everything else, including sudo
path "secret/data/checkout/root-key" {
  capabilities = ["deny"]
}

Getting secrets into a Pod: three doors

This is the part that matters most on a Kubernetes platform, and HashiCorp documents three integrations with a real comparison. The Vault Agent Injector is a mutating webhook that adds a Vault Agent sidecar to annotated Pods; the agent authenticates, renders templated secrets to a shared in-memory volume, and keeps them fresh. The Vault Secrets Store CSI provider plugs into the vendor-neutral Secrets Store CSI Driver and mounts secrets as ephemeral volumes — the right choice if you already run that driver for several backends. The Vault Secrets Operator (VSO) is the newest: a controller that reconciles custom resources and syncs Vault material into native Kubernetes Secret objects, so applications consume them with standard Kubernetes patterns. HashiCorp’s own comparison table ranks the load each one puts on Vault: VSO is “Lowest load due to CRD-specific connections and cluster-local secret caching,” the CSI provider is “Higher load due to per-Pod connections,” and the Agent Injector is “Highest load due to per-Pod connections and sidecar pattern.” The same table marks both VSO and the CSI provider as Kubernetes-native, and VSO is the only one of the three that writes a real Secret object — the other two surface secrets as mounted volumes.

# Door 1 — Vault Agent Injector: annotations on the Pod template
apiVersion: apps/v1
kind: Deployment
metadata: { name: checkout, namespace: payments }
spec:
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "checkout"                 # the k8s auth role
        vault.hashicorp.com/agent-inject-secret-db: "database/creds/orders-ro"
        vault.hashicorp.com/agent-inject-template-db: |
          {{- with secret "database/creds/orders-ro" -}}
          DB_USER={{ .Data.username }}
          DB_PASS={{ .Data.password }}
          {{- end }}
    spec:
      serviceAccountName: checkout      # bound_service_account_names
      containers:
        - name: app
          image: ghcr.io/acme/checkout:1.4.3
          # secret is rendered to /vault/secrets/db — memory-backed, never on disk
---
# Door 3 — Vault Secrets Operator: a CRD that produces a real Secret
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata: { name: checkout-config, namespace: payments }
spec:
  vaultAuthRef: checkout-auth
  mount: secret
  type: kv-v2
  path: checkout/config
  refreshAfter: 60s
  destination:
    name: checkout-config      # a normal Kubernetes Secret appears here
    create: true

How this maps onto the platform work on this site

☺ Like you’re 10: Almost everything on the Vault list already has a page here — this table shows you where.

Read the Associate blueprint next to this site’s table of contents and the overlap is striking. Vault is not a side quest; it is a concrete implementation of ideas that recur across four separate domains of platform work.

Exam logistics — attributed, and go check it yourself

☺ Like you’re 10: Here are the numbers the vendor printed. Numbers move — look them up again before you pay.

All of the above is taken from HashiCorp’s official Security Automation certifications page and the official exam content lists for the Vault Associate (003) and the Vault Operations Professional, as of writing. HashiCorp also publishes free sample questions and an exam orientation for the Professional — do both before you book.

Verdict: where it fits in a realistic order

☺ Like you’re 10: Do the cheap one if your job touches Vault. Only do the expensive one if you’re the person who keeps Vault alive.

Sequence it like this. If you are working toward platform-engineering roles generally, the CNCF ladder comes first — CNPA or CNPE, then the Kubernetes exams, as laid out on the certifications hub. Vault Associate is a strong second credential once your platform actually runs Vault, or once you own the secrets story on your team. It is cheap, it is one hour, and the concepts pay rent immediately in secrets design conversations. Budget a couple of focused weeks if you use Vault weekly, four to six if you are starting cold.

The Operations Professional is a specialist commitment: genuinely hard, hands-on, and a certificate that you can run Vault as production infrastructure rather than consume it. Take it if you are on a team that operates a Vault cluster — especially a Vault Enterprise cluster with replication and namespaces. If you merely consume Vault as a client, or your organisation is standardised on a cloud secrets manager, skip it without guilt and put the hours into External Secrets, workload identity, the policy side of your own platform, and the security practice tasks. A credential you cannot exercise at work decays faster than the two-year clock.

One last framing that keeps Timmy honest: certifications are a proof, not a curriculum. Read the Vault objectives even if you never book the exam — they are an unusually well-organised list of the things that go wrong with secrets. Auth, policy, token, lease, engine, seal. Learn the six nouns and you can evaluate any secrets system, including the one you already have. The glossary has all six.