Exam domain 1 — Access Control — requires you to understand how Vault decides who gets access to which secrets. The concept of authorisation with policies and paths is the mechanism Vault uses to make those access decisions. Without this, every user and application in your organisation would have the same level of access, which would be a security disaster.
Jump to a section
A simple way to picture Authorization with Policies and Paths
An airport security officer named Priya controls access to different parts of a busy international airport. She does not check every traveller personally. Instead, she uses a rulebook that says what each type of badge holder is allowed to do. A pilot’s badge lets them walk to any departure gate but not into the baggage hall. A baggage handler’s badge lets them enter the tarmac and the cargo area but not the passenger lounge. A cleaner’s badge permits access to toilets and waiting areas from 11pm to 5am only. Priya never has to guess or ask permission. She simply checks the badge, looks at her rulebook, and says yes or no. Every rule is written down in advance. If the airport adds a new VIP lounge, Priya gets one new page in the rulebook that says which badge types can enter. She does not need to redesign the whole security system. The rulebook is the policy. The badge is the token. The part of the airport the badge can reach is the path. This is exactly how policies and paths work in Vault. Policies are written rules that determine what actions a user or application can perform on which secrets. Paths are the locations in Vault where those secrets live. When Vault receives a request, it checks the requester’s token against the attached policies, then compares that against the path in the request. If the policy does not grant access to that path, the request is denied — just like a cleaner trying to enter a cockpit.
The rulebook is the policy. The badge is the token. The gate is the path. The specific rule that says 'baggage handlers can enter the cargo bay' is a policy statement. When the airport adds a new jetway, Priya updates the rulebook for the relevant badge types only. She does not rewrite every single rule. This is exactly how Vault policies work: they are written in HCL (HashiCorp Configuration Language) and are attached to tokens. When a token attempts to access a path, Vault checks the policies attached to that token. If any policy grants access, the request proceeds. If none grant access, it is denied.
Vault is a tool that stores and controls access to secrets. Secrets are sensitive pieces of information such as passwords, API keys, database credentials, or encryption keys. For Vault to protect these secrets, it needs a way to decide who is allowed to do what. That decision process is called authorisation. Authorisation answers the question: 'Is this user or application allowed to perform this action on this secret?'
Policies are the rules that define what is allowed. They are written in a language called HCL (HashiCorp Configuration Language). A policy looks like a set of statements. Each statement contains a path and one or more capabilities. A path in Vault is like a file path in a folder system. For example, 'secret/data/my-app' is a path that points to a specific secret or a group of secrets. Capabilities are actions that can be performed on that path. The main capabilities are:
create — allows creating a new secret at the path
read — allows retrieving the secret at the path
update — allows modifying the secret at the path
delete — allows removing the secret at the path
list — allows listing all keys at the path (like seeing the names of files in a folder)
deny — explicitly forbids any action on the path
A policy ties a set of capabilities to one or more paths. For example, a policy might say 'allow read on secret/data/team-a/*'. The asterisk (*) is a wildcard that means 'anything after this'. So that policy allows reading any secret that sits under the folder 'team-a'. A token is a piece of data that Vault issues to a user or application after they authenticate. The token carries the identity of the requester and any policies attached to that identity. When a request arrives at Vault, the following steps happen:
Vault receives the request, which includes the token and the path being accessed.
Vault checks the token to see which policies are attached to it.
Vault examines each attached policy to see if any statement grants the requested capability on the requested path.
If at least one policy grants the capability, Vault allows the action.
If no policy grants the capability, or if a policy explicitly denies it, Vault denies the request.
This is a fundamental change from how access control used to work. In older systems, access was often managed by hardcoding permissions into the application code. If you changed a user's role, you had to update and redeploy the application. With Vault, policies are separate from the applications. You write a policy once, attach it to a token, and the token inherits those rules. If you need to change access, you update the policy, and all tokens that use that policy immediately reflect the change. No code changes, no redeployments.
Paths in Vault are organised hierarchically. The root of the path is the mount point. For example, the KV (key-value) secrets engine is mounted at 'secret/'. Under that, you can have subpaths like 'secret/data/production/db-pass'. Policies can use glob patterns (like *) to match many paths with one rule. This makes it easy to grant broad access or very narrow access. The most secure practice is the principle of least privilege: give each token only the minimum capabilities on the minimum set of paths it needs to do its job.
Define the access requirements
Before writing any policy, decide which user or application needs which capabilities on which secrets. For example, a backup service needs read access to all secrets, but a web application needs only its own database password. This step determines what goes into the policy.
Write the policy in HCL
Create a text file with the .hcl extension. Write one or more path blocks. Each path block starts with 'path "<path>"' and contains a 'capabilities' array listing the allowed actions. For example: path "secret/data/app/*" { capabilities = ["read", "list"] }.
Write the policy into Vault
Use the Vault CLI command 'vault policy write <policy-name> <filename>.hcl'. This stores the policy in Vault's internal storage. You can also use the Vault UI or API. The policy becomes available for attachment to tokens immediately.
Create a token with the policy attached
Use the command 'vault token create -policy=<policy-name>' to generate a new token that carries that policy. You can attach multiple policies by repeating the -policy flag. The token is then given to the user or application that needs access.
Test the policy with the capabilities endpoint
Use 'vault token capabilities <token> <path>' to see which capabilities the token actually has on a specific path. This lets you verify the policy is working correctly before putting it into production. It also helps debug why a token is being denied access.
Monitor and update policies as needed
Over time, access needs change. Use 'vault policy list' to see all policies, and 'vault policy read <name>' to view the contents. To update, write the new HCL file over the old one with the same command. Old tokens immediately reflect the new rules.
An IT professional named Jordan works for a company called FinSafe that handles financial transactions. FinSafe uses Vault to manage database credentials for multiple microservices. A microservice is a small, independent application that does one thing, like processing payments or sending emails. Jordan needs to ensure that the payment-processing microservice can only read the payment database password, not the customer email database password.
Jordan first creates a policy. She opens a text editor and writes an HCL policy file called payment-reader.hcl. The policy contains a single statement: allowed the read capability on the path 'secret/data/payments/*'. She also explicitly denies any other path by not including them in the policy. She then uses the Vault CLI, a command-line tool, to write this policy into Vault with the command 'vault policy write payment-reader payment-reader.hcl'. This stores the policy in Vault.
Next, Jordan creates a token for the payment microservice. She uses the command 'vault token create -policy=payment-reader'. Vault returns a token string. She configures the microservice to use this token when making Vault requests. Now, when the microservice starts up, it sends a request to Vault with the token, asking to read the secret at 'secret/data/payments/prod-db-password'. Vault checks the policy attached to the token, sees that read is allowed on that path, and returns the secret. If the same microservice later tries to read from 'secret/data/customers/email-list', Vault checks the policy, finds no matching statement, and denies the request. The microservice gets an error instead of the secret.
Jordan also needs to manage human users. Developers in the team need to write new secrets into a development path. Jordan creates a policy called dev-writer that grants create and update on 'secret/data/dev/*'. She creates a token for each developer and attaches the dev-writer policy. When a developer leaves the company, Jordan revokes their token, and that developer immediately loses all access — no need to change the policy or redeploy anything.
Real-world tasks that Jordan performs regularly include:
Writing new policies in HCL using a code editor
Testing policies with 'vault token capabilities' to check what a token can do
Reviewing existing policies for compliance using 'vault policy list' and 'vault policy read'
Attaching policies to tokens when creating them
Using the Vault UI web interface to visually inspect paths and policies
Auditing access by enabling audit devices that log every request and its authorisation decision
The VA-003 exam tests your understanding of how policies control access to secrets through paths. You will not be asked to write a perfect HCL policy from memory using arcane syntax, but you must understand the structure and logic. The exam loves to test the concept of path globbing and how wildcards work. A common question presents a policy with a path like 'secret/data/team-a/*' and asks which paths are accessible. The trap is that 'secret/data/team-a/*' does NOT include 'secret/data/team-a' itself. The asterisk matches only content after the slash, not the exact parent path. Also, 'secret/data/team-a/**' matches everything recursively, including subdirectories.
Another frequent exam area is capability names. You must memorise the six capabilities: create, read, update, delete, list, and deny. The exam may give you a scenario and ask which capability is needed. For example, 'An application needs to see a list of all keys under secret/data/app/config. Which capability does it require?' The answer is list. Similarly, 'An app needs to store a new secret for the first time' requires create.
The exam also checks your understanding of how policies are associated with tokens. A token is issued with one or more policies. If a token has multiple policies, Vault takes the union of all permissions. That means if policy A allows read on path X, and policy B denies read on path X, then deny wins. Deny always overrides allow. This is a critical exam point.
Specific exam topics and trap patterns include:
Path matching: knowing that 'secret/data/*' does not match 'secret/data/foo/bar' (only one level deep)
Capability confusion: differentiating between update (modify existing secret) and create (make a new one)
Token vs policy relationship: questions that ask what happens when you revoke a token vs delete a policy
Default deny: Vault operates on a 'deny by default' basis. If no policy grants access, the request is denied. There is no implicit 'allow all' except for the root token.
The 'capabilities' endpoint: you can test what a token can do with 'vault token capabilities' — the exam may ask about this
Policy syntax: recognising that a policy block starts with 'path "..."' and has a 'capabilities = ["read"]' block inside
Name of the policy language: HCL (HashiCorp Configuration Language) — not JSON, not YAML
Policy paths for different engines: KV v2 secrets are under 'secret/data/' not just 'secret/' — the exam expects you to know this distinction
The root token: it bypasses all policies. It is for initial setup only, never for everyday use.
You must memorise the following definitions exactly:
Policy: a set of rules in HCL that define allowed capabilities on paths
Path: the location of a secret or system endpoint in Vault
Capability: an action like read, write, create, update, delete, list
Token: a piece of data that carries identity and attached policies
Default deny: the principle that access is denied unless explicitly granted by a policy
Vault uses a default-deny model: if no policy grants a capability on a path, access is automatically denied.
A policy in Vault is a set of HCL rules that define which capabilities are allowed on which paths.
Paths in Vault are hierarchical and use wildcards like * and ** to match multiple resources.
The six core capabilities are create, read, update, delete, list, and deny — memorise them precisely.
A token inherits the combined permissions of all policies attached to it, with deny always overruling allow.
Policies are decoupled from application code — you can change access rules without redeploying anything.
The root token bypasses all policies and should never be used for routine operations.
KV v2 secrets engine places secrets under 'secret/data/' path, not directly under 'secret/'.
These come up on the exam all the time. Here's how to tell them apart.
KV v1 secrets engine path
Path format: secret/my-secret
No separate data subpath
Capabilities directly apply to the secret path
KV v2 secrets engine path
Path format: secret/data/my-secret
Requires /data/ segment after mount
Metadata and destroy paths exist separately
Token with multiple policies (union)
Permissions are combined from all policies
If one policy allows read on path X, and another allows write on path X, both actions are allowed
Deny in any policy overrides all allows on that path
Token with a single policy (no union)
Only the permissions from that single policy apply
No union — you have only what one policy grants
Simpler to audit but less flexible
Capability 'create'
Used for writing a new secret that does not exist yet
Fails if the secret already exists at the path
Typically used during initial setup or provisioning
Capability 'update'
Used for modifying an existing secret
Fails if the secret does not exist at the path
Typically used for regular credential rotation
Path with single wildcard *
Matches only one level of subdirectories
Example: secret/data/team/* matches secret/data/team/a but not secret/data/team/a/b
Used for flat folder structures
Path with double wildcard **
Matches any number of nested subdirectories
Example: secret/data/team/** matches secret/data/team/a/b/c and any depth
Used for deep hierarchical structures
Mistake
A policy that allows 'read' on 'secret/data/app/*' also allows reading 'secret/data/app' directly.
Correct
The asterisk matches only items under the path, not the path itself. To match the parent, you need two statements: one for the exact path and one with the wildcard.
People think of file systems where opening a folder implicitly gives access to its contents. In Vault, the path itself is a separate resource from its children.
Mistake
If a policy is deleted, all tokens that had that policy attached lose all access immediately.
Correct
Tokens are not automatically revoked when a policy is deleted. The token remains valid, but it no longer has the permissions from the deleted policy. If it had no other policies, it becomes unusable for any action.
It seems logical that deleting the rule would delete the permission, but Vault separates token lifecycle from policy lifecycle for audit and recovery purposes.
Mistake
Using 'deny' in a policy is the same as not including the path at all.
Correct
Deny is an explicit instruction that overrides any allow statement from other policies attached to the same token. Not including a path simply means 'no decision' — Vault defaults to deny anyway, but deny becomes necessary when you want to block a specific path that another policy would otherwise allow.
Beginners think 'no rule means no access' is sufficient, but when a token has multiple policies, one policy might grant access to a broad path, and you need deny to carve out exceptions.
Mistake
A single policy can have only one path statement.
Correct
A single policy file can contain multiple path blocks, each defining capabilities for different paths. For example, a policy could grant read on 'secret/data/team-a/*' and write on 'secret/data/team-a/temp/*' in the same file.
The name 'policy' sounds singular, but in HCL, a policy file is a collection of rules. Beginners expect one-to-one mapping between policy and path.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You should not do that in production, but you can create a policy that grants all capabilities on all paths using path "*" { capabilities = ["create", "read", "update", "delete", "list"] }. Attach this policy to your token. However, the root token already has unlimited access — use it only for initial setup.
KV v2 requires the path to include '/data/' after the mount point. For example, 'secret/data/mysecret' for KV v2, but 'secret/mysecret' for KV v1. KV v2 also has additional paths like 'secret/metadata/' and 'secret/destroy/' that need separate policy statements.
Yes. A policy is a reusable set of rules. You can attach it to any number of tokens. When you update the policy, all tokens with that policy see the change instantly. This is much easier than updating each token individually.
If one policy grants read and another denies read on the same path, the deny takes precedence. Vault evaluates all policies and deny overrides any allow. This is a safety mechanism to ensure explicit restrictions cannot be bypassed.
Use the command 'vault policy delete <policy-name>'. This removes the policy from Vault. Existing tokens that had that policy attached will no longer have those permissions. However, the tokens themselves remain valid and can still be used if they have other policies.
No. Different secrets engines have different path structures. For example, the database secrets engine uses paths like 'database/creds/my-role', while the KV engine uses 'secret/data/...'. The policy syntax is the same, but you must know the correct path for the engine you are using.
You've finished Authorization with Policies and Paths. Continue through the VA-003 study guide to build a complete picture of the exam.
Done with this chapter?