SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company runs a web application on EC2 instances in an Auto Scaling group. The application receives a variable workload. The company wants to scale based on a custom metric that tracks the number of active users. What is the MOST efficient way to achieve this?

⚠ Common exam trap

SAP-C02 often tests whether candidates over-engineer scaling with Lambda or step policies when the native target tracking policy already supports custom metrics.

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

✓

Create a target tracking scaling policy using the custom metric as the target.

Target tracking scaling is the most efficient because it automatically adjusts capacity to keep a chosen metric at a target value, using CloudWatch alarms under the hood. It supports custom metrics and eliminates the need to define step boundaries or thresholds manually, which is exactly what a variable workload with a custom metric requires.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use a scheduled scaling policy to add or remove instances based on historical usage patterns.
Why it's wrong here
Scheduled scaling acts on time-based predictions, not the live active-user metric, so it cannot track variable workload. It is tempting because it suits predictable diurnal traffic patterns, and would be correct if usage followed a known schedule rather than fluctuating with concurrent users.
✗
Use AWS Lambda to periodically evaluate the custom metric and adjust the desired capacity via API calls.
Why it's wrong here
Lambda polling adds custom code, invocation latency and API throttling risk versus native metric-driven scaling. It is tempting because it offers arbitrary logic, and would be correct where no CloudWatch metric can express the scaling signal and bespoke evaluation is genuinely required.
✗
Create a step scaling policy that uses CloudWatch alarms based on the custom metric.
Why it's wrong here
Step scaling adjusts capacity in predefined bands from a CloudWatch alarm, adding tuning overhead and coarser response than target tracking on the custom metric. It is tempting for non-linear thresholds, and would be correct if capacity needed distinct step increments at specific metric values.
✓
Create a target tracking scaling policy using the custom metric as the target.
Why this is correct
Target tracking adjusts capacity automatically to hold the custom metric at a specified target, so active-user load is matched without manual threshold tuning. This satisfies the variable workload and efficiency requirements, unlike step or simple scaling policies that need hand-tuned alarms.

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question