A break-glass human administrator needs console access in an emergency, while an EC2 fleet needs permissions to read objects from a specific S3 bucket. How should those identities typically be modeled?
Select an answer to reveal the explanation.
Short Explanation
People who occasionally need a console login map cleanly to IAM users (especially break-glass). Servers should not get long-lived user keys stuffed on disk — attach an instance role so EC2 picks up temporary credentials automatically.
Full Explanation
Model a break-glass human administrator as an IAM user (with strong MFA) for emergency console access, and model the EC2 fleet with an IAM role for reading objects from a specific S3 bucket. People who occasionally need console login map cleanly to IAM users; servers should not get long-lived user keys stuffed on disk — attach an instance role so EC2 picks up temporary credentials automatically. Using the root user for both the human and every EC2 instance is unsafe. Storing S3 permissions only in security group inbound rules confuses network filters with IAM authorization. Creating root access keys and installing them on each instance is a critical antipattern. Distractors fail by abusing root, by misusing security groups as IAM, or by distributing root keys to fleets. Exam caveat: break-glass users must be few, monitored, and unused in steady state; instance roles should be least-privilege to one bucket or prefix. Operational check: create a monitored break-glass IAM user with MFA, attach an instance profile allowing s3:GetObject on the needed bucket ARN, remove static keys from AMIs, and verify instances can read without embedded credentials. In practice, keep the break-glass IAM user disabled or tightly controlled until needed, attach the S3 read role to instance profiles, and scan AMIs for embedded access keys.