Create Vault policies →mediumMultiple Select

VA-003 Create Vault policies Practice Question

A Vault administrator is building a policy for an application team that needs to manage PKI certificates issued by the 'pki_int' intermediate mount. The team must be able to generate new certificates from the 'web-server' role and revoke certificates, but must not be able to modify the role, generate a root CA, or configure the mount. (Choose two.)

⚠ Common exam trap

Many exam-takers confuse the path that issues certificates from a role with the path that defines the role, and granting write access to the definition.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

path "pki_int/issue/web-server" { capabilities = ["create", "update"] }

Vault PKI separates consuming a role from managing it. Writing to the issue endpoint generates certificates, and writing to the revoke endpoint revokes them, so those two statements cover the operational needs. Role definitions, root generation, and mount configuration are administrative surfaces that must remain outside the team's policy to satisfy the stated restrictions.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
path "pki_int/issue/web-server" { capabilities = ["create", "update"] }
Why this is correct
Issuing a certificate against a PKI role is performed by writing to the issue endpoint, so create and update on pki_int/issue/web-server permits generating certificates for that role only. It does not allow altering the role definition, touching other roles, or generating root material, which keeps the team within the intended boundary while satisfying the certificate-generation requirement.
✗
path "pki_int/root/generate/internal" { capabilities = ["create", "update"] }
Why it's wrong here
Generating an internal root CA is a highly privileged operation that establishes trust anchors for the entire mount. The scenario explicitly states the team must not generate a root CA, so including this statement directly violates the requirement. It would also let the team replace or extend the trust hierarchy, undermining the intermediate's isolation from the root.
✓
path "pki_int/revoke" { capabilities = ["create", "update"] }
Why this is correct
Revocation is triggered by writing to the pki_int/revoke endpoint, so create and update on that path lets the team revoke certificates and update the CRL as needed. It grants no ability to modify roles or generate root CAs, which aligns with the stated requirement that the team revoke certificates without broader PKI configuration rights.
✗
path "pki_int/config/*" { capabilities = ["create", "update"] }
Why it's wrong here
Paths under pki_int/config control mount-wide behavior such as URLs in issued certificates and CRL configuration. Granting write access here lets the team redirect certificate endpoints or alter distribution points, which is a configuration privilege not requested and explicitly excluded by the requirement that the mount not be configured. It should not appear in this policy.
✗
path "pki_int/roles/web-server" { capabilities = ["create", "update"] }
Why it's wrong here
This path controls the role definition itself, allowing changes to allowed domains, key usage, and TTLs. Granting it would let the team broaden what certificates can be issued, a privilege the scenario explicitly withholds. Managing the role is an administrative action distinct from consuming it, so this statement should be excluded even though it concerns the same role.

Go deeper

VA-003 Create Vault policies Practice Question

Why each option matters

Option-by-option breakdown

Related to this question