Task 5.2: Compare and contrast dynamic secrets vs. static secrets, and know their use cases

• AA database secrets engine dynamic role with default_ttl set to 24h

  Incorrect

  Dynamic roles do not keep a fixed username such as vendor_app.

• BThe connection configured with vendor_app as its own user, with the root credential rotated daily

  Incorrect

  After a root rotation the connection user's password is accessible to Vault alone, so the application could not read it.

• CA KV v2 secret holding the vendor_app password with delete_version_after set to 24h

  Incorrect

  That only removes old versions from Vault; it does not change the password in the database.

• DA database secrets engine static role mapped to vendor_app with rotation_period set to 24h

  Correct

  A static role maps to one existing database user, and Vault rotates its password on the schedule.

Static roles fit existing accounts whose name cannot change.

• AAn SMTP password written to KV by an admin

  Correct

  A password an admin writes to KV is stored as given and read back unchanged.

• BA PostgreSQL user created for each request

  Incorrect

  Credentials created on request are dynamic secrets.

• CAWS keys generated for each deployment job

  Incorrect

  Generated cloud keys are dynamic secrets.

• DA certificate issued at each request by PKI

  Incorrect

  Certificates issued per request are generated, not stored values.

Ask whether Vault keeps a value it was given or creates the credential itself.

• AA creation statement that sets the password inside the database

  Incorrect

  Creation statements receive the password Vault generated through {{password}}; they do not decide its format.

• BA KV v2 secret holding a list of approved passwords for Vault to hand out

  Incorrect

  Dynamic credentials are generated by Vault, not drawn from stored values.

• CA password policy, named in the database connection's password_policy

  Correct

  A password policy defines the length and character rules, and the connection uses it when generating passwords.

• DAn ACL policy with allowed_parameters on the database/creds path

  Incorrect

  ACL parameter rules constrain request parameters; they do not shape generated passwords.

Without password_policy, the database engine generates 20-character passwords with at least one uppercase letter, one lowercase letter, one number and one dash. Password policies are unrelated to ACL policies despite the name.

• ARead on report's creds endpoint in the operator's own policy

  Incorrect

  A missing policy grant returns permission denied, not an error from the connection about the role.

• Breport added to the connection's allowed_roles list

  Correct

  allowed_roles lists the roles that may use a connection; it defaults to none, and * allows any role.

• CA root credential rotation, which re-authorizes the connection

  Incorrect

  rotate-root changes Vault's own password on the connection and does not change which roles may use it.

• DA second connection, since each connection serves only one role

  Incorrect

  One connection can serve many roles once they are allowed on it.

Each connection names the roles that may use it in allowed_roles; the default empty list allows none, and * allows every role.

• AA KV secret listing the usernames Vault may hand out

  Incorrect

  Dynamic users are created by Vault, not drawn from a stored list.

• BA static role for every application that will request access

  Incorrect

  Dynamic roles do not depend on static roles.

• CAn agent on the database server that receives Vault's requests

  Incorrect

  Vault talks to the database through its plugin and connection; no agent runs there.

• DA connection whose user can create and drop other users

  Correct

  Vault uses a user configured on the connection to manipulate dynamic and static users.

Dynamic secrets integrate with the target platform, so Vault needs enough privilege there to create and clean up credentials.