HashiCorp Vault Associate (003) Question 64
Single answer2e Configure Vault policies using the UI and CLIA security team wants application developers to be able to read database credentials generated by the database secrets engine at path database/creds/dev-readonly, but they must not be able to list other roles or change any database configuration. An administrator plans to create the policy in the Vault UI and then validate it from the CLI before attaching it to a token. Which policy configuration best meets this requirement?
- A
Create a policy with
path "database/creds/dev-readonly" { capabilities = ["read"] } - B
Create a policy with
path "database/creds/*" { capabilities = ["read", "list"] } - C
Create a policy with
path "database/*" { capabilities = ["read"] } - D
Create a policy with
path "database/creds/dev-readonly" { capabilities = ["create", "update"] }
Show answer and explanation
Correct answer: A
Explanation
Vault policies are path-based and should follow least-privilege design. For dynamic database credentials, applications typically read from database/creds/<role-name>, so a policy granting read on the exact role path is the appropriate configuration. In the UI, an administrator can create or edit the ACL policy with this stanza; from the CLI, they can validate behavior by attaching the policy to a token and testing with commands such as vault read database/creds/dev-readonly or by reviewing effective capabilities with vault token capabilities database/creds/dev-readonly. HashiCorp Vault documentation for ACL policies and capabilities notes that read is used for read operations, while create and update are for write operations, and broad wildcards should be avoided unless intentionally required.
- A. Correct.
Correct. For the database secrets engine, reading dynamic credentials from a specific role endpoint such as
database/creds/dev-readonlyrequires thereadcapability on that exact path. This grants access only to credentials for that role and does not allow listing other roles or modifying database configuration. This is the least-privilege policy that fits the scenario and can be created in the UI or with the CLI usingvault policy write. - B. Incorrect.
Incorrect. While this would allow reading credentials under any role beneath
database/creds/, it is broader than required and also grantslist, which could expose additional role names depending on the endpoint behavior. The scenario specifically requires access only todev-readonlyand not to other roles. This option violates least-privilege principles. - C. Incorrect.
Incorrect. This path is far too broad. Granting
readondatabase/*could include other readable paths in the database secrets engine beyond just the credentials endpoint, depending on the mount's available API paths. Even if some paths are not readable in practice, the intent here is over-permissive and does not align with limiting access to one role. - D. Incorrect.
Incorrect.
createandupdateare used for write-style operations, not for reading secrets from a credentials endpoint. Thedatabase/creds/dev-readonlyendpoint is accessed with a read operation to generate and return credentials. A common misconception is that dynamic secret generation requirescreateorupdate, but for this endpoint the correct capability isread.