A company gives its employees limited rights to AWS. DevOps engineers have the ability to assume an administrator role. For tracking purposes, the security team wants to receive a near- real-time…

The correct answer is D. Create an Amazon EventBridge events rule using an AWS API call that uses an AWS CloudTrail. Explanation Option D is correct because AWS CloudTrail captures API calls in near-real-time, and sts:AssumeRole is the specific API action triggered when a role is assumed. By creating an EventBridge rule that monitors CloudTrail for this API call, you can trigger notifications…

Submitted by kavita_s· Mar 6, 2026Security and Compliance

Question

A company gives its employees limited rights to AWS. DevOps engineers have the ability to assume an administrator role. For tracking purposes, the security team wants to receive a near- real-time notification when the administrator role is assumed. How should this be accomplished?

Options

AConfigure AWS Config to publish logs to an Amazon S3 bucket. Use Amazon Athena to query the
BConfigure Amazon GuardDuty to monitor when the administrator role is assumed and send a
CCreate an Amazon EventBridge event rule using an AWS Management Console sign-in events
DCreate an Amazon EventBridge events rule using an AWS API call that uses an AWS CloudTrail

How the community answered

(26 responses)

A
4% (1)
B
4% (1)
C
8% (2)
D
85% (22)

Explanation

Option D is correct because AWS CloudTrail captures API calls in near-real-time, and sts:AssumeRole is the specific API action triggered when a role is assumed. By creating an EventBridge rule that monitors CloudTrail for this API call, you can trigger notifications (via SNS, Lambda, etc.) almost immediately when the administrator role is assumed, satisfying the near-real-time requirement.

Why the distractors are wrong:

Option A (AWS Config + Athena) is incorrect because Athena is a query service used for retrospective analysis, not near-real-time notifications - it requires manual querying of S3 logs.
Option B (GuardDuty) is incorrect because GuardDuty focuses on threat detection (malicious activity, anomalies), not routine role assumption tracking, and isn't designed for this specific use case.
Option C (Console sign-in events) is incorrect because assuming a role via sts:AssumeRole is an API call, not a Console sign-in event - these are two distinct CloudTrail event categories.

Memory Tip: Think "Role = API call = CloudTrail + EventBridge" - any time a question asks about tracking or alerting on IAM role actions in near-real-time, the winning combination is CloudTrail (captures the API call) + EventBridge (triggers the alert). If it's about login, use sign-in events; if it's about assuming a role, use API calls.

Topics

#EventBridge#CloudTrail#Security Monitoring#Real-time Alerting

Community Discussion

No community discussion yet for this question.

Full DOP-C02 Practice