HashiCorp Vault Associate (003) exam dumps

HashiCorp Vault Associate (003) practice question 62 of 243

Vault Associate (003). Associate level, HashiCorp. Free question with the correct answer and a full explanation.

HashiCorp Vault Associate (003) Question 62

Single answer2e Configure Vault policies using the UI and CLI

A platform engineer needs to give an application team read-only access to database credentials generated by the database secrets engine at path db/creds/readonly. The team should not be able to list other database roles, update configuration, or manage leases. The engineer wants to create the policy in the Vault UI and then verify from the CLI that the policy grants only the intended capability. Which policy stanza should the engineer create?

  1. A

    path "db/creds/readonly" { capabilities = ["read"] }

  2. B

    path "db/*" { capabilities = ["read", "list"] }

  3. C

    path "db/creds/readonly" { capabilities = ["create", "update"] }

  4. D

    path "sys/leases/*" { capabilities = ["read"] }

Show answer and explanation

Correct answer: A

Explanation

Vault policies are path-based and should follow least-privilege principles. For database dynamic credentials, clients typically read from a path like db/creds/ to obtain credentials generated for that role. The safest policy is therefore an exact-path rule with only the read capability. In practice, an engineer might create this policy through the Vault UI policy editor and then validate behavior from the CLI using token capability checks, for example vault token capabilities db/creds/readonly, or by testing with a token associated with the policy. Broad wildcards such as db/* and unnecessary capabilities such as list, create, update, or access to sys/leases endpoints commonly lead to over-permissioning. This aligns with Vault policy best practices and the documented capability model for ACL policies.

  • A. Correct.

    Correct. For a generated credential endpoint such as db/creds/readonly, the minimum capability needed to fetch credentials is read on that exact path. This grants access only to that role's credential endpoint and does not allow listing other roles, changing engine configuration, or interacting with lease management endpoints. After creating the policy in the UI, the engineer can verify effective permissions from the CLI with a command such as vault token capabilities db/creds/readonly.

  • B. Incorrect.

    Incorrect. This is too broad. Granting access on db/* with read and list would allow visibility into additional paths under the db mount, including metadata or role-related paths that the team was not supposed to enumerate. The inclusion of list also directly conflicts with the requirement that the team must not be able to list other database roles.

  • C. Incorrect.

    Incorrect. Create and update are used for writing data to endpoints, not for reading generated credentials from the db/creds/readonly endpoint. A common misconception is that dynamic secrets are 'generated,' so create might be needed, but for this endpoint clients retrieve credentials with read semantics.

  • D. Incorrect.

    Incorrect. Access to sys/leases/* is unrelated to simply reading database credentials from db/creds/readonly. Granting this would expose lease-related system endpoints, which violates the requirement that the team must not manage leases. It also does not itself grant access to the database credential endpoint.

Timed practice exam

Take a HashiCorp Vault Associate (003) practice test under exam conditions

70 questions in 60 minutes, drawn from this bank, with a score report and a per-question review when you finish.

Start timed exam