HashiCorp Vault Associate (003) Question 42
Single answer2a Explain the value of Vault policiesA platform team is onboarding a new application to HashiCorp Vault. The application only needs to read database credentials generated from the path database/creds/payroll-readonly. During testing, an engineer attaches the default policy to the application's token and discovers the app cannot read the credentials. A teammate suggests using the root token so the rollout is not blocked. What is the best response based on the value of Vault policies?
- A
Create a policy that grants only
readondatabase/creds/payroll-readonlyand attach it to the application's token instead of using a root token. - B
Use the root token temporarily because dynamic secrets are short-lived, so broad access is acceptable for application startup.
- C
Attach the default policy and add the application to a Vault identity group; group membership automatically allows access to all generated credentials.
- D
Enable a new auth method for the application; once authenticated, Vault allows access to requested secrets even without a matching policy.
Show answer and explanation
Correct answer: A
Explanation
This scenario tests why Vault policies are valuable: they let administrators define fine-grained authorization rules so applications receive only the capabilities they need on specific paths. In Vault, authentication answers who or what is connecting, while policies determine what that entity can do. Best practice is to avoid root tokens for applications and instead use least-privilege policies attached through an appropriate auth method. The default policy is intentionally limited and does not replace application-specific authorization. HashiCorp documentation on policies and access control emphasizes path-based capabilities such as read, create, update, delete, list, and sudo, and recommends minimizing privileges to reduce operational and security risk.
- A. Correct.
Correct. Vault policies are the primary authorization mechanism and are used to enforce least-privilege access to paths and capabilities. If the application only needs to read credentials from
database/creds/payroll-readonly, the correct approach is to create a narrowly scoped policy grantingreadon that path and associate it with the application's token through an auth method or token creation process. This demonstrates the value of policies: they reduce risk by limiting what a token can do. - B. Incorrect.
Incorrect. A root token bypasses normal policy restrictions and should not be used for routine application access. The fact that the secret is dynamic or short-lived does not justify excessive privileges. This option reflects a common misconception that temporary access is low risk; in practice, overprivileged tokens increase the blast radius if leaked or misused.
- C. Incorrect.
Incorrect. The default policy does not automatically grant access to arbitrary secret paths such as
database/creds/payroll-readonly. Identity groups can be useful for assigning policies to sets of users or machines, but membership alone does not provide access unless an appropriate policy is attached. The misconception here is confusing identity organization with authorization rules. - D. Incorrect.
Incorrect. Authentication and authorization are separate in Vault. Enabling an auth method helps the application prove its identity and obtain a token, but the token still needs policies that explicitly allow access to the requested path. This distractor targets the common error of assuming successful login implies permission to read secrets.