SAA-C03 Practice Question 78: CloudFront Functions vs Lambda Edge

CloudFront Functions is built for exactly this profile. AWS lists cache key normalisation and request authorisation (validating hashed tokens such as JSON web tokens by inspecting headers) as two of its headline use cases. It runs on viewer request and viewer response, executes in submilliseconds, and scales to millions of requests per second, which matches the traffic figure. The constraints the function accepts are the ones this workload does not care about: no network access, no request body access, and a 10 KB code limit are irrelevant for a few lines of JavaScript doing string work.

Option A puts the logic in the wrong place for cache key normalisation. An origin request trigger fires only after the cache key has already been computed and missed, so it cannot make equivalent requests share a cache entry, the whole point of the change. Token validation there would also let unauthorised requests be served from cache.

Option B is the right trigger with the wrong runtime for this scale. Lambda@Edge on viewer request would work functionally, but it is limited to about 10,000 requests per second per Region against a 2-million-per-second peak, and its per-invocation duration is measured in milliseconds rather than submilliseconds. You choose it when you need network access, larger code, third-party libraries or the request body, none of which apply here.

Option D uses a service that cannot do the job. AWS WAF inspects and allows or blocks requests against rules; it does not rewrite URLs or query strings, and it has no mechanism for verifying a JWT signature.

Reference: Differences between CloudFront Functions and Lambda@Edge