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

This explanation is based on AWS documentation and best practices but is paraphrased, not a literal extract.

The company needs two things:

To serve static content from the AWS Region geographically closest to each customer.

To send data from on premises to Amazon S3 with minimal latency and without traversing the public internet, while keeping operational overhead low.

S3 Multi-Region Access Points provide a single global endpoint that fronts multiple S3 buckets in different Regions. Multi-Region Access Points use latency-based routing and failover capabilities to direct client requests automatically to the closest healthy Regional S3 bucket that is part of the Multi-Region Access Point. This directly addresses the requirement to serve content from the closest Region with high performance and reliability, and it avoids the need to build and maintain custom routing logic.

Behind the scenes, S3 Multi-Region Access Points rely on S3 Replication between the Regional buckets that participate in the Multi-Region Access Point. When you configure a Multi-Region Access Point, you set up the participating buckets and replication configuration once; AWS then manages routing and failover, reducing operational overhead compared to manually configuring and managing multiple S3 endpoints and application logic.

For the on-premises environment, the company wants to send data to S3 with minimal latency and without using the public internet. AWS Direct Connect provides a dedicated network connection from the on-premises network into AWS, avoiding the public internet and generally providing lower and more consistent latency. AWS PrivateLink allows private connectivity to supported AWS services (such as S3 Multi-Region Access Points via interface endpoints) from within a VPC using private IP addresses. When you combine Direct Connect with PrivateLink, traffic flows from on-premises over a private dedicated connection into a VPC and then privately to the Multi-Region Access Point through an interface VPC endpoint, satisfying the requirement for no public internet exposure.

Therefore, implementing S3 Multi-Region Access Points (option A) addresses the global content serving and Regional routing, and using AWS PrivateLink together with AWS Direct Connect (option E) provides low-latency, private network connectivity from on premises to the Multi-Region Access Point with minimal operational overhead.

Option B, S3 Cross-Region Replication alone, would replicate data across Regions but would not automatically route customers to the closest Region; application changes and manual routing would be required, increasing operational overhead.

Option C would require building and maintaining a custom Lambda-based routing system, which is unnecessary when S3 Multi-Region Access Points provide managed routing and failover.

Option D, AWS Site-to-Site VPN, encrypts traffic over the public internet; it does not satisfy the explicit requirement to avoid public internet exposure and typically has less predictable latency than Direct Connect.

A is the correct answer because it uses Amazon DocumentDB (with MongoDB compatibility) as a key-value database that can scale based on demand and supports encryption in transit and at rest. Amazon DocumentDB is a fully managed document database service that is designed to be compatible with the MongoDB API. It is a NoSQL database that is optimized for storing, indexing, and querying JSON data. Amazon DocumentDB supports encryption in transit using TLS and encryption at rest using AWS Key Management Service (AWS KMS). Amazon DocumentDB also supports provisioned IOPS volumes that can scale up to 64 TiB of storage and 256,000 IOPS per cluster. To connect to Amazon DocumentDB, you can use the instance endpoint, which connects to a specific instance in the cluster, or the cluster endpoint, which connects to the primary instance or one of the replicas in the cluster. Using the cluster endpoint is recommended for high availability and load balancing purposes. References:

https://docs.aws.amazon.com/documentdb/latest/developerguide/what-is.html

https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.html

https://docs.aws.amazon.com/documentdb/latest/developerguide/limits.html

https://docs.aws.amazon.com/documentdb/latest/developerguide/connecting.html

Cross account role should be created in destination(member) account. The role has trust entity to master account.

The requirements specify cross-Region failover with an RPO of 5 minutes and an RTO of 20 minutes for a large (10 TB) database. Achieving a low RPO in a secondary Region typically requires near-continuous replication, not periodic snapshots. Achieving a 20-minute RTO requires that the standby data store already exists in the secondary Region and can be promoted quickly.

A cross-Region read replica provides continuous asynchronous replication from the primary Region to a replica in the secondary Region. This is the standard managed approach for cross-Region disaster recovery for Amazon RDS engines that support read replicas. With a read replica already running in the secondary Region, failover can be accomplished by promoting the replica to a standalone primary database instance. This supports an RTO target like 20 minutes because the data is already present and the promotion operation is typically faster than restoring from a full snapshot, especially at 10 TB scale.

Option B describes creating an RDS Multi-AZ DB cluster in the primary Region and a cross-Region read replica in the secondary Region. Multi-AZ addresses high availability within the primary Region, while the cross-Region replica addresses disaster recovery. The option also includes automation using CloudWatch alarms and a Lambda function to promote the replica when a failure is detected. This supports the required RTO by reducing manual intervention time and supports the RPO by using continuous replication.

Option A is not practical for RPO 5 minutes at 10 TB. Taking and copying snapshots every 5 minutes would be operationally heavy and would not complete within the required window; snapshot creation and cross-Region copy are not designed for such high-frequency near-real-time DR. It also risks missing the RPO due to snapshot completion time.

Option C introduces unnecessary complexity and additional services. Creating a second cluster only at failure time is not compatible with a 20-minute RTO for a 10 TB database, and using DMS for continuous sync is more development and operational work than using native RDS replication. This is not the least overhead or most direct DR design.

Option D is incorrect as stated because cross-Region read replicas are not automatically failed over and promoted by an “automated failover” feature in the way Multi-AZ failover works within a Region. Automated backups do not provide near-real-time cross-Region recovery to meet a 5-minute RPO. The usual approach for cross-Region is to create the replica and then promote it through a controlled process, which can be automated via monitoring and Lambda as in option B.

Therefore, using a cross-Region read replica with automation to promote it provides the necessary RPO/RTO with a managed service approach.