Amazon Web Services Updated SAP-C02 Exam Questions and Answers by mathias

Kinesis Data Streams is a real-time streaming service and provide near-real-time analytics. Also the question " Deliver results of processing to a data warehouse " and this option has redshift cluster which is a powerful data warehousing solution that can handle large-scale analytics workloads.

B is correct because the problem is caused by inconsistent query-string casing leading to CloudFront cache misses, and the best place to normalize the request is at the CloudFront edge before cache-key evaluation. CloudFront Functions run at the edge with very low latency and are intended for lightweight request manipulations (for example, normalizing URLs, headers, and query strings) on viewer request events. By sorting query parameters and converting them to lowercase on the viewer request, CloudFront will treat semantically equivalent requests as the same cache key, increasing cache hit ratio and reducing the number of origin calls to API Gateway and downstream Lambda invocations. This directly reduces latency for global users.

Why the other options are less suitable:

A (Lambda@Edge on origin request): Lambda@Edge can also modify requests, but it is heavier-weight than CloudFront Functions for simple normalization logic. Also, doing this on origin request occurs after CloudFront has already decided whether there is a cache hit. If the cache key is still based on the original mixed-case query string at the viewer side, you won’t consistently prevent cache misses. Normalization must happen before cache lookup to maximize cache hits.

C (API Gateway mapping templates): This normalizes the request only after it has already missed in CloudFront and reached the origin. It does not fix CloudFront cache fragmentation, so it does not meet the “minimal latency” goal as effectively.

D (Lambda authorizer): Lambda authorizers are for authorization/authentication decisions. Using an authorizer for query normalization adds unnecessary overhead and still happens at API Gateway (origin), not at CloudFront before cache evaluation.

The requirement is to reduce application latency for a globally distributed user base, with users primarily in the United States but increasing usage in Europe and the Middle East. The application is read-heavy and uses Amazon DynamoDB as its data store. Reducing latency for global users requires placing both the application compute and the data closer to users in each Region.

Option D uses the correct multi-Region architecture. Deploying the application to multiple AWS Regions places Amazon EKS workloads closer to end users. Converting the DynamoDB table to a global table creates fully managed, multi-Region replicas of the data with low-latency replication. This allows reads to be served locally from the nearest DynamoDB replica, significantly reducing read latency for users outside the primary Region. Because the workload is read-heavy, this design is particularly effective.

Route 53 geolocation routing directs users to the Region closest to them based on their geographic location. Combined with health checks and Evaluate Target Health, this ensures users are routed to the nearest healthy Region, improving both latency and availability.

Option A is incorrect because global secondary indexes do not replicate data across Regions. GSIs operate within a single Region and are used to support alternative query patterns, not global data distribution. Additionally, Route 53 failover routing is designed for disaster recovery, not for performance optimization or global load balancing.

Option B uses DynamoDB Accelerator (DAX), which improves read latency by caching data in memory, but DAX is Region-specific and does not reduce cross-Region network latency for users in Europe and the Middle East accessing a US-based application. It also does not address application-level latency caused by distance to the EKS cluster.

Option C is not valid because DynamoDB does not support read replicas in the same way relational databases do. DynamoDB replication for latency and global access is achieved through global tables, not through read replicas in a single Region. CloudFront can reduce latency for static or cacheable HTTP content, but it does not solve backend application latency or DynamoDB access latency for dynamic, read-heavy requests.

Therefore, deploying the application and DynamoDB as global tables across Regions and using Route 53 geolocation routing is the correct solution to minimize latency for all global users.

CodeCommit may use S3 on the back end (and it also uses DynamoDB on the back end) but I don ' t think they ' re stored in buckets that you can see or point Macie to. In fact, there are even solutions out there describing how to copy your repo from CodeCommit into S3 to back it up:https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-event-driven-backups-from-codecommit-to-amazon-s3-using-codebuild-and-cloudwatch-events.html