A company has multiple Amazon EC2 instances that run a resource-intensive application in a development environment. A SysOps administrator is implementing a solution to stop these EC2 instances when…

Question

Options

• AAssess AWS CloudTrail logs to verify that there is no EC2 API activity. Invoke an AWS Lambda
• BCreate an Amazon CloudWatch alarm to stop the EC2 instances when the average CPU
• CCreate an Amazon CloudWatch metric to stop the EC2 instances when the VolumeReadBytes
• DUse AWS Config to invoke an AWS Lambda function to stop the EC2 instances based on

• A
  6% (2)
• B
  82% (28)
• C
  9% (3)
• D
  3% (1)

Explanation

Option B is correct because Amazon CloudWatch natively supports alarms that trigger EC2 actions - including stop - when a metric like average CPU utilization drops below a threshold (e.g., <5% for 30 minutes), making it the most direct and purpose-built solution for detecting idle instances.

Why the distractors are wrong:

• A is wrong because CloudTrail logs API calls, not resource utilization - absence of API activity doesn't mean the instance is idle, and this approach adds unnecessary complexity.
• C is wrong because VolumeReadBytes measures disk read activity, which is not a reliable proxy for whether an application is actively in use; CPU utilization is the standard idle indicator.
• D is wrong because AWS Config is designed for configuration compliance and drift detection, not for monitoring runtime metrics or workload activity.

Memory tip: Think "CloudWatch = watches what's happening right now (metrics/alarms) → act on it." CloudTrail = trail of past API events (audit log), Config = configuration compliance. When the question asks "detect idle and stop," the answer is almost always CloudWatch + a CPU alarm with a stop action.

No community discussion yet for this question.