Cross-account analytics consumers need access to a municipal shared data lake. Direct long-term access keys are rejected by security. How should consumers authenticate?
Select an answer to reveal the explanation.
Short Explanation
Borrow a visitor badge that expires—don’t mail everyone a master key. Cross-account AssumeRole gives temporary credentials into the lake account. Static keys, root in notebooks, or public buckets are the bad shortcuts security already rejected.
Full Explanation
Cross-account analytics consumers should access a municipal shared data lake by assuming IAM roles that issue temporary credentials into the data lake account, optionally with an external ID and session policies for third parties. Role assumption avoids distributing long-term access keys, supports least-privilege lake permissions (Lake Formation or S3/IAM), and leaves CloudTrail evidence of who assumed which role. That pattern is the standard answer when security rejects direct long-lived keys for lake consumers.
Emailing static IAM access key pairs for a shared lake user recreates the exact standing-secret problem security rejected. Embedding root account credentials in Jupyter notebooks is catastrophic. Making data lake buckets public-read so “no credentials are required” exposes municipal datasets to the world and fails confidentiality controls.
Exam caveat: prefer AssumeRole (and Lake Formation permissions when used) over access keys for cross-account analytics; external ID helps confused-deputy scenarios with third parties. Operational check: create the lake role trust policy for consumer accounts, grant minimal data-plane permissions, successfully assume the role from a consumer, confirm temporary keys expire, and deny Direct S3 access with long-term user keys.