Task 5.6: Explain the value of short-lived, dynamically generated secrets

• ARotate the shared application username and password in the database and redeploy every service with them

  Incorrect

  Redeploying every service would interrupt the others, which the requirement forbids.

• BLeave the credential alone, since its lease will expire on its own at its TTL

  Incorrect

  The credential would stay valid until the TTL ends, but it must stop working now.

• CTrace the username to its lease and requesting client in the audit log, and revoke only that lease

  Correct

  Each service has unique credentials, so the username identifies one lease and one client, and revoking that lease drops only that user.

• DRevoke every lease under the database mount's prefix and let services request new ones

  Incorrect

  Prefix revocation cuts off every service at once, which the requirement forbids.

Dynamic secrets are unique per client and short-lived, so a leak points to one consumer and can be contained by revoking one lease.

• AShort TTLs make the generated passwords longer and harder to guess

  Incorrect

  TTL controls lifetime, not password strength.

• BShort TTLs prevent the credential from being logged

  Incorrect

  Audit logging does not depend on TTL.

• CA leaked credential stops working soon after it is issued

  Correct

  Vault revokes the credential when its lease ends, so exposure is limited to that window.

• DShort TTLs let several services share one credential

  Incorrect

  Dynamic credentials are issued per client.

Short-lived secrets turn a leak from a standing risk into a brief one.

• ANothing needs rotating: each credential is revoked at lease end

  Correct

  Vault revokes dynamic secrets automatically when their TTL expires, so no shared password ages.

• BThe quarterly rotation becomes a monthly Vault job

  Incorrect

  There is no shared password left to rotate.

• CVault rotates the shared password on a schedule, and each app reads it

  Incorrect

  That describes a static role, not dynamic credentials.

• DThe rotation moves to the application teams

  Incorrect

  Vault handles the credential lifecycle.

Automation of the full lifecycle is the operational payoff of dynamic secrets.

• AAn IAM user created by hand and deleted tomorrow

  Incorrect

  Manual deletion relies on someone remembering and leaves access open meanwhile.

• BAWS credentials from the AWS secrets engine with a 2-hour TTL

  Correct

  Vault revokes the credentials when the TTL ends, so access is time-boxed without manual cleanup.

• CA long-lived key stored in KV with a 2-hour delete_version_after

  Incorrect

  Deleting the KV version does not disable the key in AWS.

• DA shared team key rotated after the contractor finishes

  Incorrect

  Rotation afterwards cuts off everyone and depends on manual action.

TTLs on leases and tokens give time-boxed access by design.

• ARevoke the certificate at once, since every lost key must be on the CRL

  Incorrect

  Revocation remains available, but for short-lived certificates it is usually unnecessary, and each revocation makes Vault rebuild the CRL.

• BRequest the private key again from Vault, which keeps a copy of it

  Incorrect

  The PKI engine returns a private key only to the requesting client and does not store generated private keys.

• CRotate the issuing CA, since a lost leaf key exposes the issuer

  Incorrect

  A leaf certificate's key gives no access to the CA's own key.

• DIgnore the certificate and request a new one; it expires shortly anyway

  Correct

  With short lifetimes, a certificate whose key was lost can usually just be ignored until it expires, which keeps CRLs small.

Short-lived certificates follow Vault's philosophy of short-lived secrets: revocation becomes the exception, and CRLs stay small, which matters because rebuilding a CRL is expensive.