HashiCorp Vault Associate (003) Question 41
Single answer2a Explain the value of Vault policiesA security team is onboarding a new application to HashiCorp Vault. The application should be able to read database credentials generated from the path database/creds/payroll-readonly, but it must not be able to view other secrets or manage Vault itself. The team wants a solution that is easy to audit and follows least-privilege practices across different auth methods. Which approach provides the most value from Vault policies in this scenario?
- A
Create a policy that grants only the
readcapability ondatabase/creds/payroll-readonly, then attach that policy to the application's authenticated identity or token - B
Create a policy with broad access to
database/*so the application can read credentials now and support future database roles without additional policy updates - C
Rely on the application's auth method configuration alone, because authentication determines which paths the application can access after login
- D
Issue a long-lived root token to the application and use operational procedures to prevent misuse
Show answer and explanation
Correct answer: A
Explanation
The main value of Vault policies is that they provide fine-grained, path-based authorization independent of how a client authenticates. This lets teams enforce least privilege, standardize access control, and clearly audit what each application is allowed to do. In this scenario, the best practice is to create a narrowly scoped policy for the exact credential path the application needs and attach that policy to the token or identity produced by the chosen auth method. HashiCorp Vault documentation emphasizes that policies define capabilities such as read, create, update, delete, list, patch, sudo, and deny on paths, while auth methods are responsible for authentication, not authorization. This separation is a core reason policies are valuable in real-world Vault deployments.
- A. Correct.
Correct. Vault policies are the primary authorization mechanism in Vault and define what authenticated clients can do on specific paths. Granting only the
readcapability ondatabase/creds/payroll-readonlyenforces least privilege, limits blast radius, and works consistently regardless of whether the app authenticates with AppRole, Kubernetes, JWT/OIDC, or another auth method. This also improves auditability because the allowed actions are explicitly documented in policy. - B. Incorrect.
Incorrect. Although this might seem convenient, granting access to
database/*violates least-privilege principles and exposes more secrets than required. One of the key values of Vault policies is the ability to scope access precisely to specific paths and capabilities. Broad wildcard access is a common mistake because it makes future expansion easier at the cost of security. - C. Incorrect.
Incorrect. Authentication and authorization are separate in Vault. Auth methods verify identity and return a token, but policies attached to that token determine what the client can access. A common misconception is that enabling or configuring an auth method alone controls secret access. In practice, policies provide the authorization layer that makes access reusable and consistent across auth methods.
- D. Incorrect.
Incorrect. Root tokens bypass normal policy restrictions and are intended only for initial setup or emergency administrative tasks. Using a root token for an application defeats the value of Vault policies, removes least-privilege protections, and creates major security and audit risks. Operational process is not a substitute for technical access controls.