HashiCorp Vault Associate (003) Question 44
Single answer2a Explain the value of Vault policiesA platform team uses HashiCorp Vault to store application secrets under the KV v2 engine at path secret/. A developer reports that their application can read secrets from secret/data/payments/api but is also able to list other teams' secret paths under secret/metadata/. The security team wants to limit the application's access to only the payments secrets while still allowing the app to retrieve the specific secret it needs. Which Vault policy change best addresses this requirement?
- A
Grant the application create, read, update, delete, and list on secret/* so it can fully manage only what it needs
- B
Grant read on secret/data/payments/* and deny list on secret/metadata/* except for secret/metadata/payments/* if listing within the payments path is required
- C
Grant sudo on secret/data/payments/* so the application can bypass metadata visibility
- D
Remove all policies from the token and rely on the KV engine configuration to prevent listing of unrelated paths
Show answer and explanation
Correct answer: B
Explanation
This question tests the practical value of Vault policies: they let operators enforce least privilege by granting only the capabilities needed on specific paths. In a real deployment, policies reduce blast radius, limit accidental exposure, and separate access between teams. For KV v2 specifically, candidates should know that secret data access and key listing use different API paths: reads target /data/, while list operations target /metadata/. That distinction matters when writing policies. A strong policy design gives the application read access only to secret/data/payments/* and avoids broad list access to secret/metadata/*, unless listing is intentionally needed in the payments subtree. This aligns with HashiCorp guidance on policy-based access control and KV v2 path structure.
- A. Incorrect.
Incorrect. This is overly permissive and works against the value of Vault policies, which is to enforce least-privilege access. Granting broad capabilities on secret/* would allow the application to access or modify far more than the payments secrets. It also does not solve the core problem of restricting visibility into other teams' paths.
- B. Correct.
Correct. Vault policies are used to precisely control capabilities on paths, which is a key part of their value. With KV v2, reading secret values occurs on the data path, such as secret/data/payments/, while listing keys uses the metadata path, such as secret/metadata/payments/. Allowing read only where needed and limiting or removing list on unrelated metadata paths reduces information disclosure and enforces least privilege.
- C. Incorrect.
Incorrect. The sudo capability is not a general-purpose way to bypass normal access restrictions for application access, and it is reserved for privileged administrative operations on certain system paths. It does not represent an appropriate solution for routine secret consumption and would violate least-privilege design.
- D. Incorrect.
Incorrect. Access in Vault is governed by authentication plus authorization through policies. The secrets engine configuration alone does not replace policies for path-level authorization. Removing policies would not be a valid way to control what the application can read or list; in practice, the token needs policies that explicitly allow the required actions.