A software company is reviewing IAM in a mature application account where many roles were granted broad managed policies long ago. The security team wants evidence-based least privilege: it must continuously identify roles that have not used a granted service or have entire permissions sitting unused, and it must confirm before tightening a role that a proposed narrower policy still grants no more than intended. They want managed analysis rather than hand-built log parsing. Which TWO capabilities together meet these needs? (Select TWO.)
- AEnable an IAM Access Analyzer unused access analyzer for the account, which continuously reviews roles and reports unused permissions and roles that have not accessed granted services within a tracking period, surfacing exactly where privileges can be trimmed. Correct
- BUse IAM Access Analyzer custom policy checks to compare a proposed tightened policy against the existing one and confirm the new version grants no new or broader access before it is applied, failing the check if the change would widen permissions. Correct
- CTurn on Amazon GuardDuty in the account and rely on its anomaly findings about unusual IAM activity to identify which granted permissions on each role have gone unused over the review period so the team can remove them.
- DSchedule a recurring Amazon Athena query over AWS CloudTrail logs that lists every action each role invoked, then have engineers diff that against the attached policies by hand to find unused grants and to judge whether a tightened policy is safe to apply.
- EAttach a permissions boundary to each role listing only the services the application team believes are still required, treating the boundary as both the way to find unused grants and the proof that a tightened policy is safe.
Why A is correct: An Access Analyzer unused access analyzer continuously inspects roles and reports unused permissions, unused roles, and services not accessed within the tracking window, so it directly surfaces over-grants that should be removed using observed activity rather than manual review.
Why B is correct: Custom policy checks use automated reasoning to compare two policies and confirm the proposed one is not more permissive than intended, so the team can prove a tightened policy does not widen access before applying it, satisfying the pre-change validation need.
Why C is wrong: GuardDuty detects suspicious or anomalous behaviour from logs and threat intelligence, but it does not enumerate which granted permissions on a role are unused, so it cannot drive the systematic least-privilege trimming the requirement describes.
Why D is wrong: Athena over CloudTrail can expose used actions, but manually diffing them against policies for many roles and judging policy equivalence by hand is the laborious, error-prone effort the team wants to avoid, duplicating what the managed analyser provides.
Why E is wrong: A permissions boundary caps a role from belief rather than observed usage, so it neither discovers which grants are genuinely unused nor proves a proposed policy grants no more than intended, failing both halves of the requirement.