SAP-C02 - Continuous Improvement for Existing Solutions (25% of the exam) - Section 3.3

Translate business requirements into measurable metrics and rightsize existing resources using AWS Compute Optimizer and CloudWatch to remove waste while protecting performance.

Translate business requirements into measurable KPIs and use AWS Compute Optimizer recommendations alongside Amazon CloudWatch metrics to rightsize over-provisioned EC2, Lambda, and EBS resources. Distinguish rightsizing from general cost cutting by grounding every change in observed utilisation data rather than assumptions.

AWS Compute OptimizerRightsizingKey performance indicatorsAmazon CloudWatch metrics

Practice question for this objective

Free sampleContinuous Improvement for Existing Solutionsmedium

A data analytics team runs a memory-intensive Java application on a fleet of EC2 instances across an AWS Organizations environment. AWS Compute Optimizer is enabled organisation-wide and recommends downsizing many of these instances to smaller types based on their low CPU usage. The team is worried that acting on these recommendations would trigger out-of-memory failures, because the workload is constrained by heap usage rather than processor time, and Compute Optimizer is not currently seeing any memory data. Which action BEST ensures the rightsizing recommendations protect performance for this memory-bound fleet?

AInstall the CloudWatch agent to publish memory utilisation metrics and enable Compute Optimizer enhanced infrastructure metrics, so its recommendations account for memory before any instance is downsized. Correct
BDisable Compute Optimizer for these accounts and instead rely on AWS Cost Explorer rightsizing recommendations, which always factor in application heap usage when proposing smaller EC2 instance types for Java workloads.
CSet the Compute Optimizer CPU utilisation lookback window to the maximum length, on the assumption that a longer history of processor metrics alone is sufficient to reveal the memory pressure the workload is experiencing.
DSwitch the instances to burstable T-family types and let CPU credits absorb demand, trusting that the burst model removes the need to measure memory utilisation before downsizing the fleet.

Feed CloudWatch agent memory metrics into Compute Optimizer so rightsizing recommendations on memory-bound workloads protect performance. Compute Optimizer bases EC2 recommendations on CloudWatch utilisation data, and by default it sees only CPU, network and disk, not memory. For a heap-constrained Java fleet it therefore recommends smaller types from low CPU alone. Installing the CloudWatch agent to publish memory metrics and enabling enhanced infrastructure metrics gives Compute Optimizer the memory signal it needs, so its recommendations stop suggesting instances that would cause out-of-memory failures.

Why A is correct: Compute Optimizer only models memory when the CloudWatch agent supplies memory utilisation metrics and enhanced infrastructure metrics are enabled, so providing that data makes the recommendations memory-aware and prevents it from proposing instances too small for the heap.

Why B is wrong: Cost Explorer rightsizing suggestions are driven mainly by CPU and cost and do not ingest memory data either, so switching to them would suffer the same blind spot and still risk recommending instances that starve the heap.

Why C is wrong: A longer lookback period gathers more CPU history but never introduces memory data, so it cannot expose heap pressure and the recommendations would remain based only on the low CPU usage that is misleading here.

Why D is wrong: Burstable instances address short CPU spikes, not sustained memory demand, and moving a heap-constrained workload to a smaller burstable type would make out-of-memory failures more likely rather than protecting performance.

See more SAP-C02 practice questions, answers explained.

Exam traps in Continuous Improvement for Existing Solutions

Answers that look right on this material and are not. Each one is a distractor from a different question in the SAP-C02 bank for this domain.

Open AWS Trusted Advisor and read its underutilised EBS volume check to list volumes whose provisioned IOPS exceed observed demand, then resize those volumes.
Why it is wrong: Trusted Advisor surfaces idle or unattached volumes but does not produce per-volume rightsizing recommendations from observed IOPS and throughput the way Compute Optimizer does for volume optimisation.
Lower the Compute Optimizer recommendation preference to the most aggressive headroom level, reasoning that minimising spare capacity is the way to guarantee each instance can still absorb sudden traffic spikes.
Why it is wrong: The most aggressive setting deliberately leaves the least spare capacity and sizes instances closest to observed peaks, which is the opposite of the headroom the team wants and would make spike absorption harder, not easier.
Enable AWS Cost Explorer and read its Lambda spend breakdown, then manually raise or lower the memory of the functions that appear in the most expensive accounts until the monthly Lambda bill stops growing.
Why it is wrong: Cost Explorer shows Lambda spend but offers no per-function utilisation analysis or memory recommendation, so the team would be guessing at settings from cost alone, which is both manual and unlikely to find the optimal memory for each function.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.