A TypeScript citizen-portal backend must list objects in a departmental S3 bucket using credentials from the runtime role—not hard-coded keys in source. How should it call AWS?
Select an answer to reveal the explanation.
Short Explanation
Never carve AWS keys into the source tree like a spare house key under the mat. Use the SDK and let the runtime role hand out temporary credentials. That is how a citizen-portal backend should talk to S3.
Full Explanation
A TypeScript citizen-portal backend that must list objects in a departmental S3 bucket should use the AWS SDK for JavaScript with the default credential provider chain so the execution role supplies temporary credentials. Runtime roles (task role, Lambda execution role, instance profile) mint short-lived credentials automatically; source code never contains long-term keys. That is the baseline secure pattern for municipal apps on AWS and aligns with least privilege and key rotation hygiene.
Embedding long-term access key ID and secret in a committed .env file creates credential leakage risk through Git history and shared laptops. Emailing operators a CSV of access keys to paste into the IDE before each deploy is neither automatable nor auditable. Disabling IAM for the task role and opening the bucket with anonymous public reads exposes departmental objects to the world—often a compliance incident for citizen data.
Exam caveat: the default provider chain order matters (env vars, SSO, instance/task role, etc.). Local developers may use SSO profiles; production must use the task/execution role. SDK signing is required—unsigned HTTP to S3 is not an acceptable shortcut.
Operational check: remove static keys from repos and secrets scanners; attach an execution role with s3:ListBucket/GetObject on the needed prefix; confirm the app lists objects without local key files in the deployment environment; and rotate any previously committed keys immediately.