A developer for a county tax service chains three AssumeRole hops because a blog sample did, which complicates audits. What should the team prefer?
Select an answer to reveal the explanation.
Short Explanation
Each extra AssumeRole hop is another hallway camera auditors have to rewind. Keep the path short and the trust policy readable. Blog-driven chain gymnastics and shared long-term keys just muddy the trail.
Full Explanation
Unnecessary multi-hop AssumeRole chains complicate audits for a county tax service and obscure which human or service identity ultimately reached citizen financial data. Prefer clear, minimal role assumption paths with understandable trust policies so CloudTrail tells a straight story from the caller to the data plane. Blog samples that chain three hops with no architectural trust boundary should be simplified until each remaining hop has a concrete justification such as cross-account isolation.
Adding two more hops so every microservice owns a unique chain length increases confusion without improving security. Replacing all roles with a single long-term access key shared in Slack destroys temporary-credential benefits and accountability. Deleting trust policies so any principal can assume any role removes the control that makes IAM roles safe to use.
Exam caveat: some cross-account designs legitimately need a hop; the exam distinguishes necessary trust boundaries from accidental complexity copied from tutorials. Operational check: map the current AssumeRole chain in CloudTrail for one tax-service transaction, collapse redundant hops, re-run the call path, and confirm auditors can name the principal that accessed the resource in one clear step or a justified cross-account pair.