County cloud deploys should avoid long-lived static access keys in CI. Which secrets practice best matches that goal?
Select an answer to reveal the explanation.
Short Explanation
You can think of dynamic, short-lived credentials as day passes: they expire, so a lost credential stops working. A decade-long key in Git or a permanent administrator key does the opposite, while disabling authentication leaves deployments unprotected; rotation or leases are the safer pattern.
Full Explanation
County cloud deployments that avoid long-lived static access keys in CI should issue dynamic short-lived credentials with rotation or leases for each deploy. These credentials reduce the window in which a stolen CI secret can be used, expire automatically, and fit cloud STS/assume-role or vault lease patterns. A pipeline can request credentials at job start, use temporary permissions for the deployment, and let the lease expire rather than leaving a powerful key active indefinitely. Embedding a decade-long cloud key in pipeline YAML checked into Git combines a long-lived credential with exposure through source control. Keeping one permanent administrator key in all county CI pipelines fails least privilege and blast-radius control: one leak can compromise every pipeline. Disabling authentication so deploy jobs never need credentials removes an essential security control; unauthenticated cloud deployment is not a safe secrets practice. Exam caveat: short-lived credentials still require correctly scoped IAM permissions, because temporary over-privileged access remains dangerous. Periodic rotation alone is not the same as per-deploy dynamic issuance, even though both can help. Practical check: configure CI to assume a deploy role or request a vault lease for each job, set a minutes-or-hours TTL, deny long-lived access keys in policy, audit pipelines for static keys, and verify that an expired or revoked lease can no longer deploy county cloud workloads.