HashiCorp Vault Associate (003) Question 40
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 development team needs an application token that can read only the current values of secrets under secret/data/dev/payments/*, but must not be able to list other environments, update secrets, or delete any versions. The security team wants this access enforced consistently even if the same authentication method is used by other teams. Which Vault approach provides the BEST solution?
- A
Create a Vault policy that grants read on secret/data/dev/payments/* and attach that policy to the application's token or role
- B
Create a Vault token with a long TTL and manually distribute it to the application so the token itself limits access
- C
Enable audit devices so unauthorized requests are denied and only approved secret paths are accessible
- D
Use a root token for the application and rely on the application's code to read only the dev/payments path
Show answer and explanation
Correct answer: A
Explanation
The value of Vault policies is that they provide centralized, consistent, least-privilege authorization for secrets and system paths. Policies are attached to tokens directly or through authentication roles, identity entities, and groups, allowing administrators to separate authentication from authorization. In this scenario, the correct design is to define a narrowly scoped policy for the KV v2 data path the application needs. For KV v2, access to secret values is typically controlled on paths such as secret/data/..., and metadata operations such as listing use different paths, such as secret/metadata/.... By granting only the required capability on the correct path, Vault enforces access regardless of the client implementation or auth method used. This aligns with HashiCorp best practices around least privilege and policy-based access control.
- A. Correct.
Correct. Vault policies are the primary authorization mechanism in Vault and define which paths and capabilities a token has. In this scenario, a policy can grant only the needed capability, such as read, on the KV v2 data path secret/data/dev/payments/*, while withholding list, create, update, delete, and destroy capabilities. Attaching the policy to a token, entity, group, or auth role enforces least-privilege access consistently regardless of which user or workload authenticates through the same auth method.
- B. Incorrect.
Incorrect. A token TTL controls how long a token remains valid, not what the token is allowed to do. Manually distributing a token may also create operational and security risks. Access restrictions in Vault are enforced by policies attached to the token, not by the token lifetime alone.
- C. Incorrect.
Incorrect. Audit devices record requests and responses for accountability and investigation, but they do not make authorization decisions. Vault policies determine whether access is allowed or denied. Someone might choose this option because auditing is an important security feature, but it does not replace policy-based access control.
- D. Incorrect.
Incorrect. A root token bypasses normal policy restrictions and has effectively unrestricted access. This violates least privilege and creates significant risk if the application or token is compromised. Relying on application code for access control is weaker than enforcing access centrally in Vault with policies.