HashiCorp Vault Associate (003) Question 61
Single answer2e Configure Vault policies using the UI and CLIA platform engineer needs to give an application team read-only access to secrets stored under the KV v2 secrets engine mounted at secret/. The team should be able to read the current value of secrets under apps/payments/, but they must not be able to list secrets outside that path or modify any data. The engineer wants to create the policy in the Vault UI and then validate it from the CLI. Which policy definition should the engineer use?
- A
path "secret/apps/payments/*" { capabilities = ["read"] }
- B
path "secret/data/apps/payments/*" { capabilities = ["read"] }
- C
path "secret/metadata/apps/payments/*" { capabilities = ["read", "list"] }
- D
path "secret/data/apps/payments/*" { capabilities = ["create", "update", "read"] }
Show answer and explanation
Correct answer: B
Explanation
The key applied concept is that KV v2 policy paths differ from the user-facing secret path shown in many UI workflows. For a mount at secret/ and an application path of apps/payments/, reading secret values requires policy access to secret/data/apps/payments/* with the read capability. If the team also needed to browse keys in the UI or by CLI using list operations, they would additionally need list on the corresponding metadata path, such as secret/metadata/apps/payments/*. However, this scenario explicitly limits access to reading current values and avoiding broader listing or modification. In practice, an engineer could create this ACL policy in the UI under Policies and then validate it from the CLI by logging in with a token that has the policy and testing a command such as vault kv get secret/apps/payments/
- A. Incorrect.
Incorrect. For a KV v2 secrets engine, policy paths must account for the API structure. Reading secret data uses the /data/ path segment, not the mount path alone. A common mistake is to write policies as if the engine were KV v1, where the path would map more directly to the mount and secret path.
- B. Correct.
Correct. In KV v2, reading the current value of a secret requires access to the data endpoint, which is represented in policies as path "secret/data/apps/payments/*" with the read capability. This grants read access only to secret data under apps/payments/ and does not permit writes or listing elsewhere.
- C. Incorrect.
Incorrect. The metadata path in KV v2 is used for operations such as listing keys and managing metadata, not for reading the secret value itself. Adding list on metadata would also allow listing within that path, which is broader than the requirement and does not by itself grant access to the secret data values.
- D. Incorrect.
Incorrect. This policy includes create and update, which would allow modifying secrets. That violates the requirement for read-only access. While the data path is correct for KV v2 reads, the capabilities are too permissive.