Vault Associate · Domain 2 of 9

Vault Associate Domain 2: Vault policies

Vault policies decide what a token may do. This group tests why policies matter, how path and capabilities syntax work, how to choose a policy that meets a requirement, and how to write and attach policies from the UI and CLI.

Exam weight estimate
Not published
Official objectives
5
Estimated questions estimate
~7
Suggested study time estimate
5–7 hrs

About 12 min read Reviewed October 2026

Overview

Vault policies are HCL or JSON documents that grant or forbid operations on paths. HashiCorp lists five objectives: explain the value of policies, describe the path syntax, describe the capabilities syntax, choose a policy from a set of requirements, and configure policies with the UI and CLI. Vault is deny by default, so a token can do nothing unless one of its policies allows it, and an explicit deny always wins.

You should be able to read a policy and say exactly which requests succeed. That means knowing the capabilities create, read, update, patch, delete, list, sudo and deny, the trailing * glob, the + segment wildcard, the rule that the most specific path wins, and the extra data/ and metadata/ prefixes that KV version 2 paths need. Built-in policies matter too: default is attached to most tokens, and root grants everything.

How it's tested

Policy questions are precise. You may see an HCL snippet and be asked which operation it permits, or a requirement such as read-only access to one team's secrets and be asked which policy satisfies it. Some items test CLI commands such as vault policy write and vault token capabilities.

  • Will this request succeed

    A policy and a request path are shown, and you decide whether the capability and path match allows the operation.

  • Pick the least-privilege policy

    Several candidate policies are offered, and you choose the one that grants only what the requirement describes.

  • Policy workflow

    You identify the command or UI step that writes, lists, reads or checks a policy, or attaches it to a token or auth role.

Reasoning it through

A policy grants read on secret/data/app/* and the user runs vault kv list secret/app. The read grant looks related, but listing keys in KV version 2 is a list operation on the metadata path. Because the policy contains no list capability on secret/metadata/app/*, Vault denies the request, and the fix is adding a list rule on that metadata path.

Objectives 5

Official objectives from the HashiCorp outline, in outline order.

2a Explain the value of Vault policiesWhy policy-based, deny-by-default authorization matters.
What it means
Policies are how Vault applies least privilege. They map identities, through tokens, entities and groups, to the specific paths and operations each client needs, and they deny everything that is not explicitly allowed.
What to understand
Without a matching allow, Vault returns permission denied. Tokens carry a list of policy names, and the effective permissions are the union of all attached policies, except that a deny capability anywhere wins. Policies are evaluated at request time, so editing a policy changes access for existing tokens without reissuing them. The default policy lets a token manage itself, such as looking up and renewing, and the root policy allows everything and cannot be changed.
How it shows up
Expect questions on deny-by-default behavior and on what happens to existing tokens after a policy update.
Common confusion
Believing tokens must be recreated before a policy change takes effect.
2b Describe Vault policy syntax: pathHow path blocks match request paths with exact names and wildcards.
What it means
Each policy rule begins with a path stanza naming the API path it governs, such as path "secret/data/team-a/*". Paths can be exact, end with a * glob, or use + to match exactly one path segment.
What to understand
The * glob is only valid at the end of a path and matches any characters after the prefix, including slashes. The + wildcard matches a single segment anywhere, for example secret/data/+/config. When several rules match, Vault applies the most specific one rather than merging them. KV version 2 adds data/ for secret values and metadata/ for listing and version metadata, so policies must include those prefixes. Templated paths can insert identity values such as {{identity.entity.id}}.
How it shows up
A rule and a request are shown, and you decide whether the path matches and which rule applies.
Common confusion
Placing * in the middle of a path, or forgetting the data/ prefix for KV version 2 secrets.
2c Describe Vault policy syntax: capabilitiesThe operations a policy can allow or deny on a path.
What it means
Capabilities list the operations allowed on a path: create, read, update, patch, delete and list, plus sudo for root-protected endpoints and deny to block access.
What to understand
Capabilities roughly map to HTTP verbs: create and update both relate to writes, with create for new data and update for existing data. Read retrieves, delete removes and list shows keys. Patch allows partial updates. Sudo is needed for some sys/ endpoints in addition to the normal capability. Deny overrides every other capability, even from another policy. A path with no capabilities granted is effectively denied.
How it shows up
You may need to name the capability a command requires, such as list for vault kv list or sudo for a protected endpoint.
Common confusion
Thinking sudo grants every capability; it only unlocks root-protected paths alongside the needed operation.
2d Choose a Vault policy based on requirementsTranslating a stated access need into the right rules.
What it means
This objective asks you to read a requirement, such as letting an application read its own secrets but not delete them, and select or write the policy that grants exactly that and nothing extra.
What to understand
Start from the paths involved, including any KV version 2 prefixes, then add only the needed capabilities. Prefer specific paths to broad globs, use + for repeating structures, and use deny to carve out exceptions inside a wider grant. Remember that the client also needs the default policy, or equivalent rules, to renew or look up its own token. Templated policies scale per-user paths without writing one policy per person.
How it shows up
Expect several near-identical policies, where only the least-privilege option meets the requirement.
Common confusion
Choosing a policy with a broad * glob because it works, when a narrower path satisfies the requirement.
2e Configure Vault policies using the UI and CLIWriting, listing, reading and attaching policies.
What it means
Configuring policies covers creating them with vault policy write, inspecting them with vault policy list and vault policy read, deleting them, and attaching them to tokens, auth method roles, entities or groups. The UI offers the same under Policies.
What to understand
vault policy write app-read app-read.hcl uploads a policy; vault policy fmt tidies HCL. vault token create -policy=app-read issues a token with it, and auth roles take policy lists such as token_policies. vault token capabilities <path> shows what the current token can do on a path, which is useful for troubleshooting. The root and default policies exist on every server; root cannot be edited or deleted, and default cannot be deleted.
How it shows up
A command is shown, and you identify whether it creates, reads, tests or attaches a policy.
Common confusion
Expecting vault policy write to attach the policy to a token automatically.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Deny by default

    No policy match means no access.

    Remember
    Every allowed operation must be granted explicitly.
    Tested as
    Policy evaluation questions.
    Trap
    Assuming read access is implied.

  • Explicit deny

    The deny capability blocks a path.

    Remember
    Deny wins over any allow from any policy.
    Tested as
    Conflicting policy questions.
    Trap
    Expecting the most generous grant to win.

  • * glob

    Prefix match at the end of a path.

    Remember
    Only valid as the final character.
    Tested as
    Path syntax questions.
    Trap
    Using it mid-path.

  • + wildcard

    Matches exactly one path segment.

    Remember
    Can appear anywhere in the path.
    Tested as
    Path syntax questions.
    Trap
    Confusing it with the * glob.

  • Most specific match

    When rules overlap, the more specific path applies.

    Remember
    Rules are not merged across overlapping paths.
    Tested as
    Rule priority questions.
    Trap
    Adding capabilities from a broader rule.

  • KV v2 data/ and metadata/

    Extra path segments for KV version 2.

    Remember
    Reads use data/, list uses metadata/.
    Tested as
    KV policy questions.
    Trap
    Writing policies against the CLI path.

  • sudo capability

    Unlocks root-protected endpoints.

    Remember
    Needed in addition to the normal capability.
    Tested as
    sys/ path questions.
    Trap
    Treating it as full admin.

  • default policy

    Attached to tokens unless excluded.

    Remember
    Lets a token look up and renew itself.
    Tested as
    Token behavior questions.
    Trap
    Thinking it can be deleted.

  • root policy

    Allows every operation.

    Remember
    Cannot be modified or removed.
    Tested as
    Built-in policy questions.
    Trap
    Assigning it for convenience.

  • vault token capabilities

    Reports the capabilities on a path.

    Remember
    Fast way to troubleshoot permission denied.
    Tested as
    CLI questions.
    Trap
    Confusing it with vault policy read.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Path matching: * vs. + vs. exact

ConceptMeaningKey differenceCommon trap
Exact path Matches one specific path Most specific rule Missing sub-paths
Trailing * Matches everything after a prefix End of path only Using it in the middle
+ segment Matches any single segment Works mid-path Expecting it to cross slashes

Key capabilities

ConceptMeaningKey differenceCommon trap
create / update Write new or existing data POST and PUT style writes Granting only one when both are needed
list Show keys under a path Separate from read Assuming read includes list
sudo Access root-protected endpoints Added to another capability Thinking it replaces other grants
deny Block access entirely Overrides all allows Expecting another policy to override it

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Glob in the middle

    What candidates pick
    Pick a policy with secret/*/config.
    Why it looks right
    It reads like a natural wildcard.
    Why it's wrong
    The * glob only works at the end of a path; + matches a single middle segment.

    Clue to watch for A wildcard is needed between two fixed segments.

  2. Read means list

    What candidates pick
    Assume read on secret/data/app/* allows vault kv list.
    Why it looks right
    Read sounds like it should cover browsing.
    Why it's wrong
    Listing is a separate capability, and on KV v2 it applies to the metadata path.

    Clue to watch for The failing command is a list.

  3. Allow beats deny

    What candidates pick
    Expect a second policy granting read to override a deny.
    Why it looks right
    Policies are additive.
    Why it's wrong
    Permissions are a union, but an explicit deny on the path always takes precedence.

    Clue to watch for Two policies conflict on the same path.

  4. Rules merge

    What candidates pick
    Combine capabilities from an exact path and a broader glob.
    Why it looks right
    Both rules match the request.
    Why it's wrong
    Vault applies the most specific matching rule instead of merging overlapping rules.

    Clue to watch for Overlapping path rules with different capabilities.

  5. sudo is admin

    What candidates pick
    Grant sudo to give full access on a path.
    Why it looks right
    The name suggests superuser rights.
    Why it's wrong
    Sudo only unlocks root-protected endpoints and still requires the matching normal capability.

    Clue to watch for The question mentions a sys/ endpoint.

  6. Reissue tokens

    What candidates pick
    Revoke and recreate tokens after editing a policy.
    Why it looks right
    Many systems cache permissions.
    Why it's wrong
    Vault evaluates policies by name at request time, so edits apply to existing tokens immediately.

    Clue to watch for A policy was changed while tokens are in use.

Answer framework

Apply these steps whenever a Domain 2 item asks whether access is allowed or which policy fits.

  1. Write out the full request path, adding data/ or metadata/ when the mount is KV version 2.
  2. Find every rule whose path matches, remembering that * works only at the end and + matches one segment.
  3. Keep the most specific matching rule, and check whether any attached policy places deny on the path.
  4. Map the operation to its capability, such as list for listing keys, update for existing writes and sudo for protected endpoints.
  5. When choosing between policies, select the one granting the fewest paths and capabilities that still satisfy every stated requirement, and reject any option whose wildcard reaches other teams' paths.

Practice question

A developer needs to read and list secrets stored under the KV version 2 mount secret/ at path team-a/, but must not create, change or delete anything. Which policy meets this requirement with least privilege?

Want more like this? The Vault Associate practice test has questions for every domain.

Checklist

0 of 12

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Learn policies by writing them, not just reading them. On a dev server, enable a KV version 2 mount, write a policy that grants read on one team's data path, create a token with that policy, and try reading, listing, writing and deleting. Each failure teaches a rule you will meet on the exam, especially the data/ and metadata/ split and the separation between read and list.

Next, practise path matching on paper. Write ten request paths and three overlapping rules, then decide which rule applies to each request and whether it succeeds. Include a + segment, a trailing glob and an explicit deny so you build fast instincts for the most-specific-path rule.

Use vault token capabilities to confirm your answers, and edit a policy while a token is active to see that the change applies immediately. Close with practice questions on this group, reviewing each miss against the official policy documentation until you can explain why every wrong option fails.

FAQ

How heavily is Vault policies weighted on the exam?

HashiCorp publishes no weight for Vault policies. The group has five objectives, so our planning estimate is about seven questions, although policy reading also appears inside token and secrets engine items.

What happens if no policy matches a path?

Vault denies the request. It is deny by default, so every permitted operation must be explicitly granted by an attached policy.

Can I put * in the middle of a path?

No. The * glob is only valid at the end of a path. Use + to match a single segment in the middle, such as secret/data/+/config.

Why do KV version 2 policies need data/ and metadata/?

The KV version 2 API stores secret values under data/ and key and version information under metadata/. The CLI hides those prefixes, but policies must include them.

Does sudo give full access to a path?

No. Sudo only allows access to root-protected endpoints and must be combined with the normal capability the operation requires.

Do I need to recreate tokens after changing a policy?

No. Tokens reference policies by name and Vault evaluates them at request time, so the change applies to existing tokens straight away.

Other Cybersecurity certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 2 knowledge

You have reviewed policy value, path rules, capabilities and policy workflow. Check whether you can read a policy and judge access accurately under time pressure.

Take the Vault Associate practice test Check your Vault Associate readiness

Keep going