A company runs its applications on a large number of Amazon EC2 instances. A SysOps administrator must implement a solution to notify the operations team whenever an EC2 instance state changes. What…

Question

Options

• ACreate a script that captures instance state changes and publishes a notification to an Amazon
• BCreate an Amazon EventBridge event rule that captures EC2 instance state changes. Set an
• CCreate an Amazon EventBridge event rule that captures EC2 instance state changes. Set as the
• DCreate an AWS Config custom rule that evaluates instance state changes with automatic

• A
  5% (2)
• B
  81% (30)
• C
  3% (1)
• D
  11% (4)

Explanation

Option B is correct because Amazon EventBridge natively captures EC2 instance state-change events (e.g., pending → running → stopped) without any custom code, and routing those events directly to an SNS topic delivers immediate notifications to the operations team - fully managed, serverless, and zero infrastructure to maintain.

Why the distractors fail:

• A - Writing a custom script introduces maintenance overhead, likely requires polling or a scheduler, and is far less operationally efficient than a native AWS integration.
• C - This also uses EventBridge, but setting a Lambda function as the target adds an unnecessary intermediary layer when SNS can be the direct target; Lambda is appropriate only if custom processing logic is needed.
• D - AWS Config evaluates configuration compliance over time, not real-time state transitions; it's the wrong tool for event-driven notification and adds complexity with no benefit here.

Memory tip: Think of it as "EventBridge catches, SNS dispatches." Whenever an exam question asks about reacting to AWS service state changes with notifications, EventBridge (the event catcher) → SNS (the notifier) is the canonical serverless pattern - no code, no polling, no servers.

No community discussion yet for this question.