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

Improve the performance of an existing solution using Amazon CloudFront, AWS Global Accelerator, caching and identification of bottlenecks against measurable SLAs and KPIs.

Improve existing solution performance by offloading static and dynamic content with Amazon CloudFront and routing global TCP/UDP traffic through AWS Global Accelerator to reduce latency. Identify bottlenecks by measuring against defined SLAs and KPIs, and apply targeted caching or compute changes rather than broad re-architecture.

Amazon CloudFrontAWS Global AcceleratorPerformance bottlenecksService level agreements

Practice question for this objective

Free sampleContinuous Improvement for Existing Solutionshard

A trading platform exposes a stateful real-time order API over TCP and a separate UDP market-data feed from Network Load Balancers in three Regions. Users worldwide report inconsistent connection setup times and occasional jitter that breaches the platform's sub-50ms regional latency KPI, and packet captures show traffic taking variable public-internet paths to the nearest Region. The responses are user-specific and cannot be cached. The team wants to route each client to the closest healthy Region over the AWS backbone with stable entry points and the least operational overhead. Which approach MOST effectively improves performance?

APlace an Amazon CloudFront distribution in front of both endpoints and disable caching with a zero time to live, so requests ride the edge network to the origin Regions while every response is fetched live from the load balancers.
BAdd AWS Global Accelerator with the regional Network Load Balancers as endpoints, so clients connect to static anycast addresses and traffic enters the AWS backbone at the nearest edge and is routed to the closest healthy Region. Correct
CCreate Amazon Route 53 latency-based records for the three load balancers with health checks, so DNS resolution sends each client to the Region that currently measures the lowest latency from its resolver location.
DPublish the elastic IPs of the existing Network Load Balancers directly and let clients connect to those fixed regional addresses, so the TCP and UDP traffic reaches the application tier without any added global routing layer.

Choose AWS Global Accelerator to improve latency and jitter for non-cacheable global TCP and UDP traffic with stable anycast entry points. Non-cacheable TCP and UDP traffic that must reach the closest healthy Region quickly benefits from Global Accelerator, which pulls connections onto the AWS backbone at the nearest edge and routes them over private links, reducing the variable-path latency and jitter that DNS or plain regional load balancer IPs leave on the public internet.

Why A is wrong: CloudFront accelerates HTTP and is optimised for cacheable content, but it does not front raw TCP and UDP listeners and adds little for fully dynamic, non-HTTP order and market-data traffic.

Why B is correct: Global Accelerator ingests TCP and UDP at the nearest edge onto the AWS backbone, gives fixed anycast entry points, and routes to the closest healthy endpoint, which cuts latency and jitter for non-cacheable traffic.

Why C is wrong: Latency-based DNS steers clients per Region but resolves to public IPs over variable internet paths and is subject to resolver caching, so it does not deliver the stable backbone-routed entry points the workload needs.

Why D is wrong: Publishing the regional Network Load Balancer IPs gives fixed entry points but keeps clients on public-internet paths to a single Region each, so it neither uses the AWS backbone nor routes globally to the closest healthy Region.

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.

Put an Amazon CloudFront distribution in front of the Network Load Balancers so viewers connect to the nearest edge location and CloudFront forwards each session over the AWS backbone to the origin Region.
Why it is wrong: CloudFront is an HTTP and HTTPS content delivery network optimised for cacheable web traffic and does not proxy a custom UDP game protocol, so it cannot front this session workload despite also using the edge network.
Remove CloudFront for the API paths and point viewers straight at the single-Region origin Application Load Balancer using latency-based DNS records and health checks, so the dynamic calls avoid the extra edge hop and connect directly to the closest available origin endpoint each time.
Why it is wrong: Sending viewers directly to a single-Region origin forces every distant client to pay the full long-distance TLS and TCP handshake itself, which is exactly the connection-setup overhead the monitoring identified as the bottleneck.
Read the CloudWatch CPUUtilization metric on the RDS instance during peaks and, if it is high, immediately scale the database to a larger instance class to clear the assumed bottleneck.
Why it is wrong: Database CPU is one signal, but acting on it alone assumes the bottleneck before measuring the edge and application tiers, so it risks scaling the wrong component and still missing the real source of the latency.

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