Vault Associate common mistakes
Vault Associate · Understand the traps and how to avoid them.
After enabling an auth method at a non-default path (e.g. `vault auth enable -path=corp-ldap ldap`), the candidate logs in against `auth/ldap/login/...` and concludes the auth method is broken when it returns 404/no handler.
The default path taught in most intro material is the method type name, so the login URL and the CLI -method shortcut are assumed to be fixed regardless of where the mount lives.
What to do instead
Treat the mount path as part of the endpoint: vault login -method=ldap -path=corp-ldap username=..., and confirm the real path with vault auth list before building any request or policy path (auth/corp-ldap/login/*).
Validates a newly written policy by running the CLI commands as the root token (or the token used to write the policy) and concludes the policy works because the commands succeed.
The root token bypasses all policy evaluation, and any token holding sudo/update on sys/policies can read the policy back but that says nothing about enforcement on a normal token.
What to do instead
Create a throwaway token that holds only the policy under test (vault token create -policy=myapp -ttl=5m -no-default-policy), export it as VAULT_TOKEN in a clean shell, and test each command you care about - including the failing ones you expect to be denied.
Grants `read` and `list` on `secret/data/myapp/*` only, then expects `vault kv list secret/myapp` and `vault kv delete secret/myapp` to work with that token.
KV v2 splits data and metadata into separate API paths; listing and destroying versions hit secret/metadata/* and secret/delete/*, so a data-only policy produces permission denied on operations the candidate believes are covered.
What to do instead
Write the policy against all four path families actually used: secret/data/<app>/* (read/create/update), secret/metadata/<app>/* (read/list), and secret/delete/<app>/* or secret/destroy/<app>/* for deletion and version destruction.
Creates a token with `-policy=app-read` and then asserts the token has exactly one policy, but introspection shows `["app-read","default"]`.
Vault automatically attaches the default policy to every token unless it is explicitly suppressed, which changes the effective permission set the candidate is reasoning about.
What to do instead
Remember default is implicit; add -no-default-policy when you truly need an isolated token, and verify with vault token lookup <token> to see the resolved policy list rather than assuming it.
Designs a workflow that calls `vault token renew` on a batch token (or tries to look it up / revoke it) and treats the failure as a configuration bug.
Batch tokens are not persisted in the token store: they cannot be renewed, looked up, or revoked individually, and they carry a fixed TTL - behaviour that does not match the mental model built from service tokens.
What to do instead
Choose the token type deliberately: use service tokens (default) whenever renewal, revocation, or lookup is required, and reserve -type=batch for high-volume, short-lived, non-renewable workloads.
Reads a KV v2 secret with the HTTP API or `-format=json` output and pulls the credential from `.data.password` (or `.password`), getting `null` or empty output.
KV v2 wraps the stored key/value map one level deeper than v1, so the payload is data.data.<key> in JSON responses while the CLI hides that nesting in table output.
What to do instead
For KV v2 JSON responses index .data.data.<key> (vault kv get -format=json secret/myapp | jq -r .data.data.password); for table output use -field=password. Confirm the mount version with vault secrets list -detailed before choosing the access pattern.
Enables a KV mount, writes data, and then tries to flip it to version 2 by running `vault secrets tune -options=version=2 secret/`, expecting existing and future paths to become v2.
The mount's KV version is a creation-time option; secrets tune does not perform the v1→v2 upgrade and the mount silently stays v1, so the secret/data/... paths the candidate then uses do not exist.
What to do instead
Enable v2 up front with vault secrets enable -path=secret -version=2 kv, or upgrade an existing v1 mount explicitly with vault kv enable-versioning secret/; then re-check vault secrets list -detailed for the reported version before writing any policy or client code.
Unseals only the active node after `vault operator init`, or re-runs `operator init` on the second node because its unseal keys "must be different", and then reports the cluster as broken.
operator init happens once per cluster and produces per-cluster unseal keys and root token; every node shares the same barrier material but must be submitted unseal-key shares individually.
What to do instead
Run vault operator init exactly once, distribute the shares, and unseal every node one at a time with the threshold number of shares (vault operator unseal against each node's API address); verify with vault status and vault operator raft list-peers.
Assumes a dynamic credential keeps working after its lease has lapsed and the token is still valid, or renews with an increment far beyond the role's `max_ttl` and treats the clamped result (or error) as a bug.
Dynamic secrets are leased, not permanent: the lease TTL controls validity, revoking the parent token revokes its leases, and no renewal can push a credential past the role's or mount's max_ttl.
What to do instead
Treat the lease as the credential's lifetime: read lease_duration from the response, renew with an increment at or below max_ttl, and request a fresh credential (new lease) when renewal is no longer possible. Inspect and clean up with vault lease lookup, vault lease renew, and vault lease revoke.
Enables exactly one file audit device to a path that later fills or becomes unwritable, and during the incident Vault refuses all client requests.
When every enabled audit device fails, Vault fails closed and blocks requests rather than serving traffic unaudited - a deliberate security property that surprises operators who treat audit as passive logging.
What to do instead
Enable at least two audit devices on independent backends (vault audit enable -path=file1 file ... and a second, e.g. syslog/socket), monitor their health, and during an incident fix or disable the failing device (with a privileged token) using vault audit list / vault audit disable to restore service.