A code review finds that several cloud workloads authenticate to the provider's APIs using long-lived access keys hard-coded in configuration files stored with the application code. Which change best addresses service access for these workloads?
Select an answer to reveal the explanation.
Short Explanation
A permanent key taped under the doormat stays a problem whether you move it to the flowerpot or change it every season. Workload identities give each service a badge that expires by itself. The trap is any fix that still leaves a long-lived secret somewhere to steal.
Full Explanation
Service access concerns how non-human identities, such as applications, functions and containers, authenticate to cloud APIs. Long-lived static keys are a common breach path because they leak through repositories, images, logs and backups and remain valid until someone notices. A workload identity lets the platform authenticate the workload itself and issue short-lived, automatically rotated credentials scoped to a least-privilege role, so no secret is stored with the code and a leaked token expires quickly. Moving keys into environment variables removes them from files but leaves the same long-lived secret on the host, visible to process inspection, crash dumps and anyone with access to the deployment configuration. Quarterly rotation shortens exposure somewhat, yet a key leaked the day after rotation remains valid for months, and a private repository is still widely readable inside the organization. Encrypting the files while storing the passphrase beside them provides no real protection, because anyone who can read the repository can decrypt them. Exam caveat: where a workload cannot use a platform identity, a secrets manager with automatic rotation is the fallback, not hard-coding. Operational check: scan repositories and images for credential patterns and confirm the provider shows no active long-lived keys for the affected service accounts.