Skip to content
Cheat sheets

003 · Domain 2: Vault policies · 13% of the exam

Task 2.4: Choose a Vault policy based on requirements

Writing the smallest policy that meets a requirement: which paths, which capabilities, how several policies combine, and where deny or a parameter rule is needed.

Study it

Sample questions

Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.

Question 1 · choose 1

Team web uses the KV v2 mount secret/. Its members must be able to read, write, list and soft-delete secrets under web/, but must never be able to remove version data permanently. Which policy fits?

  1. Asecret/data/web/*: create, read, update, delete; and secret/metadata/web/*: list
  2. Bsecret/web/*: create, read, update, delete, list
  3. Csecret/data/web/*: create, read, update, delete; and secret/metadata/web/*: list, delete
  4. Dsecret/data/web/*: create, read, update, patch; and secret/metadata/web/*: list, read
Show the answer and why

  • Asecret/data/web/*: create, read, update, delete; and secret/metadata/web/*: list

    Correct

    On KV v2, delete on data/ is a soft delete of the latest version, and list on metadata/ lists keys; nothing here can purge data.

  • Bsecret/web/*: create, read, update, delete, list

    Incorrect

    KV v2 serves data under data/ and metadata/, so a policy on secret/web/* matches none of the API paths.

  • Csecret/data/web/*: create, read, update, delete; and secret/metadata/web/*: list, delete

    Incorrect

    delete on metadata/ permanently removes the key's metadata and every version.

  • Dsecret/data/web/*: create, read, update, patch; and secret/metadata/web/*: list, read

    Incorrect

    Without delete on data/, members cannot soft-delete the latest version, which the requirement needs.

KV v2 splits a secret across data/, metadata/, delete/, undelete/ and destroy/ paths, so a policy chooses capabilities per prefix. Soft deletes stay recoverable; metadata deletes and destroy calls do not.

HashiCorp documentation

Task 2.4Report a problem with this question

Question 2 · choose 1

Users on the userpass method must be able to change passwords, but must not be able to change any other setting of a user, such as token_ttl. Which rule on the userpass users path fits?

  1. Acapabilities = ["update"] with allowed_parameters = { "password" = [] }
  2. Bcapabilities = ["update"] with denied_parameters = { "password" = [] }
  3. Ccapabilities = ["update"] with required_parameters = ["password"]
  4. Dcapabilities = ["update", "sudo"] with no parameter rules
Show the answer and why

  • Acapabilities = ["update"] with allowed_parameters = { "password" = [] }

    Correct

    With allowed_parameters set, only the listed parameters may be sent, and an empty list allows any value.

  • Bcapabilities = ["update"] with denied_parameters = { "password" = [] }

    Incorrect

    This blocks changes to the password and allows everything else, the opposite of the goal.

  • Ccapabilities = ["update"] with required_parameters = ["password"]

    Incorrect

    Requiring password still lets the request change other parameters too.

  • Dcapabilities = ["update", "sudo"] with no parameter rules

    Incorrect

    Without parameter rules every setting can be changed, and sudo adds nothing here.

Parameter constraints narrow what an allowed request may contain. Remember they are not supported for the KV v2 engine.

HashiCorp documentation

Task 2.4Report a problem with this question

Question 3 · choose 1

A team may use every path under secret/ except secret/super-secret, which it must never touch. What is the simplest policy?

  1. AA rule on "secret/*" only, since an exact path not listed is excluded from the glob
  2. B"secret/*" with the needed capabilities, plus "secret/super-secret" with ["deny"]
  3. CA rule on "secret/+" only, since + skips the super-secret path
  4. DA rule on "secret/*", plus "secret/super-secret" with ["list"] only
Show the answer and why

  • AA rule on "secret/*" only, since an exact path not listed is excluded from the glob

    Incorrect

    The glob covers secret/super-secret too, so access would be granted.

  • B"secret/*" with the needed capabilities, plus "secret/super-secret" with ["deny"]

    Correct

    deny on the exact path takes precedence over the broad grant.

  • CA rule on "secret/+" only, since + skips the super-secret path

    Incorrect

    + matches any single segment, super-secret included.

  • DA rule on "secret/*", plus "secret/super-secret" with ["list"] only

    Incorrect

    The exact path then allows list, so the team could still touch it; only deny forbids all access.

Broad grants plus narrow denies keep policies short while protecting the exceptions.

HashiCorp documentation

Task 2.4Report a problem with this question

Question 4 · choose 1

SecretIDs for the AppRole my-role must always be returned wrapped, with a wrapping TTL of at most 90 seconds. Which rule on auth/approle/role/my-role/secret-id enforces this?

  1. Amax_wrapping_ttl = "90s" alone with create and update
  2. Bttl = "90s" with create and update, the policy setting for wrapped responses
  3. Callowed_parameters = { "wrap_ttl" = ["90s"] } with create and update
  4. Dmin_wrapping_ttl = "1s" and max_wrapping_ttl = "90s" with create and update
Show the answer and why

  • Amax_wrapping_ttl = "90s" alone with create and update

    Incorrect

    A maximum alone does not force clients to request wrapping.

  • Bttl = "90s" with create and update, the policy setting for wrapped responses

    Incorrect

    Policies have no ttl setting; wrapping limits use the wrapping TTL parameters.

  • Callowed_parameters = { "wrap_ttl" = ["90s"] } with create and update

    Incorrect

    Wrapping is requested with a header or CLI flag, not a body parameter that this rule could check.

  • Dmin_wrapping_ttl = "1s" and max_wrapping_ttl = "90s" with create and update

    Correct

    A minimum wrapping TTL of one second makes wrapping mandatory, and the maximum caps the TTL clients request.

Policies can require and bound response wrapping per path, which keeps sensitive values such as SecretIDs out of plain responses.

HashiCorp documentation

Task 2.4Report a problem with this question

Question 5 · choose 1

A delegated team may create and update token roles, but no role may list admin in allowed_policies; any other policy name is fine. Which rule on auth/token/roles/* fits?

  1. Acreate and update with denied_parameters = { "allowed_policies" = [] }
  2. Bcreate and update with allowed_parameters = { "allowed_policies" = ["admin"] }
  3. Ccreate and update with denied_parameters = { "allowed_policies" = ["admin"] }
  4. Dcreate, update and deny on auth/token/roles/admin
Show the answer and why

  • Acreate and update with denied_parameters = { "allowed_policies" = [] }

    Incorrect

    An empty list denies any change to that parameter, not just admin.

  • Bcreate and update with allowed_parameters = { "allowed_policies" = ["admin"] }

    Incorrect

    This would allow only admin and block every other parameter.

  • Ccreate and update with denied_parameters = { "allowed_policies" = ["admin"] }

    Correct

    A populated denied list blocks requests containing those values and leaves all others allowed.

  • Dcreate, update and deny on auth/token/roles/admin

    Incorrect

    That denies a role named admin; it does not stop other roles from allowing the admin policy.

Empty lists allow or deny any value; populated lists allow or deny only the listed values.

HashiCorp documentation

Task 2.4Report a problem with this question

Practice domain 2 →Practice all domains →