Housing-authority automation jobs use a cloud SDK to update case queues. How should those jobs obtain credentials?
Select an answer to reveal the explanation.
Short Explanation
SDK credential chains that assume short-lived roles keep housing jobs from smuggling permanent keys into git. Hard-coded keys and public portals are the opposite hygiene.
Full Explanation
Cloud SDKs resolve credentials through a default chain that can assume instance or workload roles and short-lived tokens without embedding permanent keys in source. Housing-authority automation jobs that update case queues should rely on that SDK default credential chain with short-lived roles so secrets are not committed to Git, emailed to contractors, or published in open datasets.
Hard-coding permanent access keys inside the job source repository places long-lived credentials in Git history—an enduring municipal exposure that clones forever. Emailing plaintext keys to every contractor before each nightly run multiplies copies across inboxes and devices outside central control. Storing provider secrets in a public open-data portal dataset publishes credentials to the internet by design and fails every civic data-handling expectation.
Exam caveat: ensure the runtime identity—CI role, task role, or managed identity—is least-privilege for case-queue updates only, with no unused admin actions attached. Operational check: remove embedded keys from the housing job repository, attach a short-lived role the SDK can assume, run a job successfully, and confirm cloud audit logs show role sessions rather than static key IDs.