A municipal open-data portal application must write objects to an S3 bucket without embedding long-lived access keys in the app. Which approach should the architect design?
Select an answer to reveal the explanation.
Short Explanation
Hardcoded keys are like leaving the parks shed key taped to the door. Give the app a role that hands out short-lived STS credentials when it runs—on an instance, a task, or via assume-role. When the session ends, the key vanishes; nothing sticky lives in the app.
Full Explanation
When a municipal open-data portal must write objects to Amazon S3 without embedding long-lived access keys, the correct pattern is to assign an IAM role to the compute path and let AWS Security Token Service (STS) issue temporary credentials. On Amazon EC2 that is an instance profile; on Amazon ECS/EKS or Lambda it is a task or execution role; across accounts it may be an assume-role chain. Temporary credentials rotate automatically, are scoped by the role policy, and disappear when the session ends—exactly what a parks or open-data application needs so secrets are not baked into configuration files or container images.
Baking an IAM user access key and secret into the application configuration fails because static keys are long-lived, hard to rotate, frequently committed to source control, and remain valid after developers leave. Emailing temporary passwords for the AWS account root to developers is worse: root is never an application identity, email is an insecure channel, and root credentials grant unrestricted account power. Storing static access keys in an S3 bucket for download at startup merely relocates the secret; the app still needs credentials to read that bucket, creating a circular bootstrap problem, and anyone who can read the bucket obtains standing keys.
Exam caveat: the role's trust policy must allow the correct service principal (ec2.amazonaws.com, lambda.amazonaws.com, etc.), and the permissions policy should allow only the required s3:PutObject (and related) actions on the intended bucket/prefix—not s3:*. Prefer bucket policies and least-privilege identity policies together for defense in depth. Operational check: launch the portal compute with the role attached, confirm the instance/task metadata or Lambda environment yields temporary keys (not AKIA long-term keys), successfully put an object to the open-data prefix, and verify that removing the role or tightening the policy produces AccessDenied without any hardcoded keys present in config.