HashiCorp Vault Associate (003) Question 52
Single answer2c Describe Vault policy syntax: capabilitiesA platform team wants an application to read its database credentials from Vault at the path secret/data/apps/payments while preventing the application from listing other secrets or modifying any data. The team is writing an ACL policy for the application's token. Which policy stanza best meets this requirement?
- A
path "secret/data/apps/payments" { capabilities = ["read"] }
- B
path "secret/data/apps/payments" { capabilities = ["list"] }
- C
path "secret/metadata/apps/payments" { capabilities = ["read"] }
- D
path "secret/data/apps/payments" { capabilities = ["create", "update"] }
Show answer and explanation
Correct answer: A
Explanation
Vault ACL policies use capabilities such as create, read, update, delete, list, sudo, patch, and deny to authorize actions on paths. In a real deployment, selecting the narrowest capability set is important for least-privilege access. Here, the application only needs to retrieve a secret, so read is sufficient. Because the example uses a KV v2-style path, the secret value is accessed under the data endpoint, not metadata. The list capability is specifically for enumeration and does not imply read access to secret contents. HashiCorp documentation on Vault policies and KV v2 API behavior makes this distinction clear: use the correct path and only the required capability.
- A. Correct.
Correct. For Vault ACL policies, capabilities define which operations are allowed on a path. To let an application retrieve a secret value without allowing it to modify or enumerate secrets, the appropriate capability is read on the secret's data path. In KV v2, reading secret contents uses the /data/ path, so granting read on secret/data/apps/payments allows the application to fetch that secret and nothing more.
- B. Incorrect.
Incorrect. The list capability allows listing keys at a path where supported, not reading the secret value itself. This is a common misconception because users often assume list is a broader read-like permission. In practice, list is used for enumeration and would not let the application retrieve the secret contents from the KV v2 data path.
- C. Incorrect.
Incorrect. In KV v2, the metadata path is used for metadata-related operations, not for reading the secret's actual stored value. A read on secret/metadata/apps/payments would apply to metadata endpoints rather than the secret data endpoint the application needs. This option reflects confusion between KV v2 data and metadata API paths.
- D. Incorrect.
Incorrect. The create and update capabilities are write-oriented permissions. They would allow writing secret data to the path rather than safely consuming it. Since the requirement is read-only access for an application, granting write capabilities would violate least-privilege best practices.