SAP-C02 Continuous Improvement for Existing Solutions Practice Question
A company runs a critical application on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The application experiences intermittent high latency due to CPU spikes on some instances. The company wants to automatically replace unhealthy instances and optimize costs. What should a solutions architect do?
⚠ Common exam trap
Candidates may think that lifecycle hooks are needed to replace unhealthy instances, but ALB health checks integrated with Auto Scaling already handle this automatically.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure a target tracking scaling policy based on average CPU utilization.
A target tracking scaling policy dynamically adjusts the number of instances based on average CPU utilization, which addresses intermittent CPU spikes. The Auto Scaling group also automatically replaces instances that fail ALB health checks, ensuring unhealthy instances are replaced. This optimizes costs by scaling down during low usage. Option B is incorrect: lifecycle hooks are for custom actions during instance launch or termination, not for replacing unhealthy instances. Option C is incorrect: terminating instances with high CPU via Lambda does not integrate with Auto Scaling and could cause instability. Option D is incorrect: scheduled scaling is for predictable traffic patterns, not intermittent spikes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure a target tracking scaling policy based on average CPU utilization.
Why this is correct
Target tracking adjusts desired capacity automatically to hold average CPU at a defined target, adding instances when spikes occur and removing them when demand falls. This addresses the CPU-driven latency while optimising cost, and unhealthy instances are replaced by the Auto Scaling group's health checks.
- ✗
Use a lifecycle hook to perform a health check and terminate unhealthy instances.
Why it's wrong here
Lifecycle hooks pause instances during launch or termination for custom actions; they do not evaluate CPU metrics or trigger replacement of unhealthy instances. They are tempting because they integrate custom health checks into scaling events, which is correct when instances need validation before entering or leaving service.
- ✗
Use an AWS Lambda function to terminate instances with high CPU.
Why it's wrong here
Using Lambda to terminate instances with high CPU bypasses the Auto Scaling group's inherent capability to automatically replace unhealthy instances based on health checks, which is its core function for maintaining desired capacity and application health. The ASG is specifically designed for this scenario, making Lambda redundant and less integrated. Lambda is tempting as it offers custom event-driven automation and can respond to CloudWatch alarms. It would be suitable for bespoke remediation actions outside an ASG's lifecycle, such as terminating standalone development instances or non-ASG resources based on custom criteria for cost optimisation.
- ✗
Implement a scheduled scaling policy to increase instances during peak hours.
Why it's wrong here
Scheduled scaling adjusts capacity at predetermined times, so it cannot react to intermittent CPU spikes or replace individual unhealthy instances. It is tempting because it handles predictable traffic patterns cost-effectively, and would be correct if latency correlated with known peak hours rather than unpredictable spikes.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
One of 984 original SAP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAP-C02 exam.