A township container task must retrieve database credentials at runtime. The credentials must be encrypted at rest with KMS and readable only by the task role. Which design best meets that requirement?
Select an answer to reveal the explanation.
Short Explanation
Secrets Manager plus a task role is like a lockbox the container can open only with its badge—KMS keeps the secret encrypted at rest. Baking passwords into images or READMEs is how townships end up rotating credentials in a panic.
Full Explanation
A township container task that must retrieve database credentials at runtime—with encryption at rest via KMS and readability limited to the task role—should store those credentials in AWS Secrets Manager encrypted with a KMS key and grant only the task execution/task role secretsmanager:GetSecretValue (and matching kms:Decrypt) on that secret ARN. At startup or refresh, the task calls Secrets Manager over a private path when required, never baking passwords into image layers. That design yields rotation-friendly, auditable secret access aligned with least privilege.
Baking plaintext passwords into container image layers and pushing to a public gallery fails confidentiality permanently—image history retains secrets even after "deletion" from the running task. Committing the password to a public README and injecting via world-readable environment files on shared NFS without encryption fails secrecy and access control. Disabling database authentication so no secrets are required fails basic data protection and is not an acceptable substitute.
Exam caveat: task role versus execution role permissions are easy to confuse—ensure the role the application code assumes can read the secret, and prefer VPC endpoints for Secrets Manager/KMS so credentials retrieval stays private. Operational check: deploy a task without the secret in the image, confirm it retrieves credentials successfully, remove the secret permission and confirm failure, and verify CloudTrail shows GetSecretValue only from the expected role.