How to Automatically Modify EC2 Spot Requests When Capacity Is Unavailable?
A gaming company uses Amazon EC2 Spot Instances to run game servers. Currently, the company uses small instance types. However, the company occasionally experiences spot unavailability. The company needs a solution that can automatically modify a spot request and add a new instance family when current instance types are unavailable. Which solution will meet this requirement?
Community Insight
The exam tests event-driven remediation for Spot capacity shortfalls; the trap is assuming CloudTrail records Spot request status changes when it only logs API activity.
This scenario tests how to detect EC2 Spot request capacity failures and automatically modify the request to add another instance family. The correct approach uses CloudWatch Events to match the instance-stopped-no-capacity status and invoke Lambda, not CloudTrail API logging.
Most candidates pick CloudTrail plus EventBridge because it sounds like the standard event-driven pattern, but CloudTrail does not emit Spot request state changes such as capacity-not-available.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option A is correct because EC2 Spot request problems are surfaced through CloudWatch Events/EventBridge status events, including theinstance-stopped-no-capacity status that indicates the current instance type cannot be fulfilled. A CloudWatch Events rule can match that event and trigger an AWS Lambda function to modify the Spot request or Spot Fleet request configuration. The Lambda function can then add a new instance family and preserve capacity for the game servers. This gives the gaming company automated remediation instead of manual monitoring of Spot availability.Why the Other Options Are Wrong
Option B is wrong because AWS CloudTrail records API calls such asRequestSpotInstances and CancelSpotInstanceRequests, not internal Spot request status transitions like instance-stopped-no-capacity. Creating an EventBridge rule on CloudTrail logs therefore does not reliably detect the capacity failure described in the question. Option C is too vague because CloudWatch logs and metrics alone do not invoke Lambda without a defined event rule or subscription filter, and it does not identify the Spot capacity event. Option D is also wrong because Systems Manager Automation can run a runbook, but it does not natively detect Spot request failures; you still need an event source such as CloudWatch Events, and the runbook alone does not add a new instance family.Community Comment Notes
Bad_Mat selected option B and described using "CloudTrail to log EC2 spot request state changes" with an EventBridge rule invoking Lambda. That reflects the common misconception that CloudTrail is the event source for resource state changes, when CloudTrail is primarily an API activity log. The single learner comment is useful context, but it is not evidence that CloudTrail captures Spot capacity status changes.Official Reference
Exam Strategy
When an option claims CloudTrail captures a resource's internal state, challenge it: CloudTrail captures API calls, not Spot request status transitions. For Spot capacity automation, look for CloudWatch Events/EventBridge matching a Spot status code and a Lambda remediation action.
Frequently Asked Questions
Why is CloudTrail not the right event source for Spot request state changes?
CloudTrail records API calls such as RequestSpotInstances, not internal Spot status transitions like instance-stopped-no-capacity; CloudWatch Events/EventBridge emits those status events.
Can Lambda add a new instance family to an existing Spot request?
A Lambda function can cancel and recreate the request or modify a Spot Fleet request configuration to include the additional instance family.
Related Analysis
Practice All SOA-C03 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SOA-C03 Practice Test →