DOP-C02 - Resilient Cloud Solutions (15% of the exam) - Section 3.3

Scale and accelerate workloads with Amazon CloudFront, Amazon ElastiCache and Amazon API Gateway caching and request throttling.

Reduce latency and protect origins by serving content through Amazon CloudFront edge locations and caching hot data in Amazon ElastiCache. Apply Amazon API Gateway request throttling to prevent sudden traffic spikes from overwhelming backend services.

Amazon CloudFrontAmazon ElastiCacheAPI Gateway cachingRequest throttling

Practice question for this objective

Free sampleResilient Cloud Solutionsmedium

An internal Amazon API Gateway REST API fronts a fragile legacy backend that can handle only a limited number of concurrent requests before it degrades. The provider wants API Gateway itself to reject excess traffic with a throttling response so the backend is protected, and wants the limit applied to one specific high-volume method rather than to the whole stage. Which configuration achieves this?

ALower the account-level throttle and burst limits for the Region so the whole account is capped, which keeps total request volume to the legacy backend within the level it can tolerate during peak periods.
BAttach an AWS WAF web ACL with a rate-based rule to the API stage so requests beyond a threshold per source address are blocked before they are forwarded to the legacy backend integration.
CConfigure a per-method throttle on the high-volume method by overriding its stage method settings with a specific rate and burst, so API Gateway returns throttling responses once that method exceeds the limit. Correct
DEnable response caching on the high-volume method with a long time-to-live so most requests are served from the cache and never reach the legacy backend, reducing the concurrent load it has to handle.

Apply Amazon API Gateway method-level throttling overrides to cap one specific method and shed excess load before it reaches a fragile backend. API Gateway lets you override the default stage throttle on individual methods with their own rate and burst values; when requests to that method exceed the configured limit the service responds with a throttling error instead of forwarding the call, so the legacy backend behind that one method is protected without affecting other methods on the stage.

Why A is wrong: The account-level throttle applies across every API and method in the Region, so it would constrain unrelated APIs as well and is far broader than the single fragile method, which is not the targeted protection requested.

Why B is wrong: A WAF rate-based rule throttles per source IP and applies to the whole stage rather than one method, so it neither targets the specific high-volume method nor enforces a backend concurrency-safe rate as a method throttle would.

Why C is correct: Method-level throttling overrides let you set a rate and burst on just the chosen method, so API Gateway returns a throttling response when that one method exceeds the limit while leaving other methods unaffected, which precisely protects the fragile backend.

Why D is wrong: Caching only helps for cacheable repeated responses and does nothing to cap concurrency for cache-miss or non-idempotent traffic, so the backend can still be overwhelmed and this is not a throttling control.

See more DOP-C02 practice questions, answers explained.

Exam traps in Resilient Cloud Solutions

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

Set a single account-level throttle and burst limit on the API so all incoming requests share one rate ceiling, then track each developer's monthly usage from CloudWatch metrics and revoke access manually when a quota is exceeded.
Why it is wrong: An account-level throttle applies one shared ceiling to all callers rather than per consumer, and manual quota tracking and revocation is operationally heavy and not enforced by the service, so it fails the per-developer enforcement requirement.
Lower the cache time-to-live on every object so CloudFront refreshes content more often, which keeps the edge caches current and spreads the load across the regional points of presence during busy periods.
Why it is wrong: A shorter time-to-live makes edge caches expire sooner and fetch from the origin more frequently, so it increases the number of origin requests during a spike rather than reducing the duplication the team is trying to remove.
Enable stage-level caching for the whole stage with a long time-to-live, so every method benefits from cached responses and the backend is called far less often across all resources during peak load.
Why it is wrong: Caching the entire stage would also cache the per-user methods, and without distinguishing callers it risks returning one user's response to another, which violates the requirement that per-user data is never shared.

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