SAP-C02 Practice Questions

The application's reliability issues stem from single points of failure in both the web and database tiers. To address the website outages, the single EC2 instance must be replaced with a scalable and fault-tolerant architecture. Placing the Tomcat servers into an Auto Scaling group behind an Application Load Balancer (A) allows the application to handle traffic spikes and recover from instance failures. For this architecture to be highly available, it must operate across multiple Availability Zones (AZs), necessitating the creation of an additional public subnet in a different AZ (F). Furthermore, the single MySQL database instance is a critical single point of failure. Migrating to Amazon Aurora with a replica (C) introduces a managed, fault-tolerant database with automatic failover, significantly enhancing data tier reliability.

B. A single VPC peering connection is managed by AWS and is not a single point of failure; adding another is unnecessary and not possible between the same two VPCs.

D. NAT gateways are for outbound internet access from private subnets and do not help resolve outages caused by high inbound traffic to the website.

E. Moving the Tomcat server to the database VPC does not resolve the core issue of it being a single, non-scalable instance that fails under load.

1. Auto Scaling and Load Balancing (A

F): The AWS documentation states that to achieve high availability

you should distribute traffic across instances in multiple Availability Zones. An Application Load Balancer requires at least two AZs to be configured for fault tolerance. An Auto Scaling group works with the load balancer to automatically adjust capacity.

Source: AWS Documentation

"Tutorial: Set up a scaled and load-balanced application"

Step 2: Choose a VPC and subnets. The tutorial specifies selecting at least two public subnets in different Availability Zones.

2. Amazon Aurora for High Availability (C): Amazon Aurora is designed for high availability. An Aurora DB cluster consists of a primary DB instance and one or more Aurora Replicas. If the primary instance fails

Aurora automatically fails over to a replica.

Source: AWS Documentation

"High availability for Amazon Aurora"

Section: "Amazon Aurora high availability".

3. VPC Peering Redundancy (B): The infrastructure for a VPC peering connection is created to be neither a single point of failure nor a bandwidth bottleneck.

Source: AWS Documentation

"VPC Peering Guide"

Section: "VPC peering basics"

under "What is VPC peering?".

AWS Database Migration Service (DMS) is the ideal solution for this scenario as it is specifically designed for migrating databases with minimal downtime. DMS performs an initial full load of the data from the source Aurora cluster to the target cluster in the new account. Following the full load, DMS captures and applies ongoing changes from the source to the target using Change Data Capture (CDC). This continuous replication keeps the target database synchronized with the source, allowing the company to perform the DNS cutover at a planned time with virtually no service interruption.

A. Taking and sharing a snapshot is a point-in-time migration method. It requires downtime to restore the database and does not replicate any data changes that occur after the snapshot is taken.

C. Using AWS Backup to share and restore a backup is functionally equivalent to the snapshot method. It is a point-in-time recovery process, not a continuous replication solution, and thus does not minimize downtime.

D. AWS Application Migration Service (MGN) is designed for migrating servers (IaaS), such as EC2 instances or on-premises virtual machines, not for managed database services (PaaS) like Amazon Aurora.

1. AWS Database Migration Service User Guide: In the "What Is AWS Database Migration Service?" section

the documentation states

"AWS DMS can also be used for continuous data replication with high availability... This process occurs with virtually no downtime to the source database...". This confirms DMS's capability for minimal downtime migrations through continuous replication.

Source: AWS Database Migration Service User Guide

"What Is AWS Database Migration Service?".

2. Amazon Aurora User Guide: The guide discusses migration strategies and explicitly recommends AWS DMS for scenarios requiring minimal downtime. It contrasts this with snapshot-based methods. For example

in the section on migration

it states

"To perform a minimal downtime migration

you can use AWS Database Migration Service (AWS DMS)."

Source: Amazon Aurora User Guide for Aurora MySQL

"Migrating data to an Amazon Aurora DB cluster".

3. AWS Documentation - Sharing a DB cluster snapshot: This document describes the process of sharing snapshots across accounts. The process involves taking a snapshot and then restoring it

which is a point-in-time operation and does not account for ongoing changes

thus not minimizing downtime for a live application.

Source: Amazon Aurora User Guide

"Sharing a DB cluster snapshot".

4. AWS Application Migration Service User Guide: The introductory section explains its purpose: "AWS Application Migration Service (AWS MGN) is the primary migration service recommended for lift-and-shift migrations to AWS." It operates by replicating block devices from source servers

which is inapplicable to a managed service like Aurora.

Source: AWS Application Migration Service User Guide

"What is AWS Application Migration Service?".

The solution must address scaling for both the stateful application tier and the database tier.

1. Stateful Application Tier: The application is stateful, meaning user session data is stored on the specific EC2 instance they are connected to. To ensure a consistent user experience as the application scales horizontally with an Auto Scaling group, the load balancer must direct all requests from a user's session to the same instance. An Application Load Balancer (ALB) with sticky sessions (session affinity) enabled is the standard and most effective way to achieve this for web applications.

2. Database Tier: Amazon Aurora has a single writer instance and can have multiple read replicas. To scale database read capacity, which is common for web applications, you add more read replicas. Aurora Auto Scaling is a feature specifically designed to automatically adjust the number of Aurora Replicas based on performance metrics like CPU utilization, thus scaling the database's read throughput. You cannot "auto scale" the number of writer instances.

Therefore, combining an ALB with sticky sessions for the application and Aurora Auto Scaling for the read replicas provides a complete, scalable, and consistent solution.

A: A Network Load Balancer (NLB) does not support the "least outstanding requests" routing algorithm; it uses a flow hash algorithm. While it supports sticky sessions, an ALB is generally better suited for HTTP/HTTPS web traffic.

B: "Aurora Auto Scaling for Aurora writers" is incorrect. An Aurora cluster has only one writer instance. Scaling the writer is a vertical scaling operation (changing instance size), not an auto-scaling of the instance count.

D: This option is incorrect for two reasons: it incorrectly suggests auto-scaling Aurora writers, and it incorrectly pairs the "least outstanding requests" algorithm with a Network Load Balancer.

1. AWS Documentation - Elastic Load Balancing

Application Load Balancers: "Sticky sessions are a mechanism to route requests from the same client to the same target. Elastic Load Balancing supports sticky sessions for Application Load Balancers." (Source: AWS Documentation

User Guide for Application Load Balancers

section on "Sticky sessions").

2. AWS Documentation - Amazon Aurora: "With Aurora Auto Scaling

you can have Amazon Aurora automatically adjust the number of Aurora Replicas in an Aurora DB cluster... Aurora Auto Scaling is useful for workloads that have predictable cyclical traffic patterns or unpredictable traffic spikes." (Source: AWS Documentation

Amazon Aurora User Guide

section on "Using Amazon Aurora Auto Scaling with Aurora replicas").

3. AWS Documentation - Amazon Aurora Architecture: "Every Aurora DB cluster has one primary DB instance [writer]... An Aurora DB cluster can also have up to 15 Aurora Replicas... Aurora Replicas are used for read scaling." (Source: AWS Documentation

Amazon Aurora User Guide

section on "Amazon Aurora DB clusters").

4. AWS Documentation - Elastic Load Balancing

Network Load Balancers: "The load balancer routes each request to a single target in a target group. The routing algorithm it uses is a flow hash algorithm." (Source: AWS Documentation

User Guide for Network Load Balancers

section on "Routing").

This solution meets all the stringent Recovery Point Objective (RPO) and Recovery Time Objective (RTO) requirements. AWS Elastic Disaster Recovery (DRS) uses continuous, block-level data replication for the EC2 instances, which can achieve an RPO of seconds, easily satisfying the 2-minute requirement. An Amazon RDS cross-Region read replica uses asynchronous replication, which typically has a lag of seconds to a few minutes, meeting the 5-minute database RPO. Promoting the read replica is a fast operation, meeting the 30-minute RTO. AWS Global Accelerator provides static IP addresses and intelligently routes traffic to the nearest healthy regional endpoint (the ALBs), ensuring rapid failover and optimal latency for users.

B: Amazon Data Lifecycle Manager (DLM) automates EBS snapshots, but the minimum creation frequency is one hour. This cannot meet the required 2-minute RPO for the application tier.

C: AWS Backup for EC2 instances is also based on snapshots, which have a minimum frequency of one hour, failing to meet the 2-minute RPO. CloudFront is a CDN, not the optimal service for this type of DR traffic routing.

D: This option fails for the same reason as option B. Amazon DLM's minimum snapshot frequency of one hour is insufficient to meet the 2-minute application RPO.

1. AWS Elastic Disaster Recovery (DRS): "AWS Elastic Disaster Recovery (DRS) minimizes downtime and data loss with fast

reliable recovery of on-premises and cloud-based applications... It enables an RPO of seconds and an RTO of minutes."

Source: AWS Documentation

"What is AWS Elastic Disaster Recovery?"

Introduction.

2. Amazon RDS Cross-Region Read Replicas: "You can reduce the risk of a regional disruption by using cross-Region read replicas as part of your disaster recovery strategy... In the event of a regional disruption

you can promote the read replica to be a new standalone DB instance."

Source: Amazon RDS User Guide

"Working with read replicas"

Section: "Cross-Region read replicas".

3. AWS Global Accelerator: "AWS Global Accelerator improves the availability and performance of your applications with local or global users... It provides static IP addresses that act as a fixed entry point to your application endpoints in a single or multiple AWS Regions... If there's a failure

Global Accelerator instantly directs traffic to the next available endpoint."

Source: AWS Documentation

"What Is AWS Global Accelerator?"

Introduction.

4. Amazon Data Lifecycle Manager (DLM): "You can create policies that create snapshots on a schedule. The schedule can be as frequent as every 1 hour."

Source: Amazon EC2 User Guide for Linux Instances

"Amazon Data Lifecycle Manager"

Section: "How Amazon DLM works".

This solution provides the lowest operational overhead by leveraging AWS managed services. AWS Elastic Beanstalk is a Platform as a Service (PaaS) that automates the deployment, scaling, and management of the Java/Tomcat application directly from the JAR file. It automatically provisions necessary resources, including an Application Load Balancer and an Auto Scaling group across multiple Availability Zones to handle traffic spikes. Amazon RDS for PostgreSQL offloads database administration tasks like patching, backups, and scaling. This combination directly addresses all requirements (Java/Tomcat, PostgreSQL, no source code, scaling) with minimal management effort.

A. This manual IaaS approach requires significant operational overhead for configuring EC2 instances, software, and a complex scaling mechanism using Step Functions.

B. Amazon EKS has a higher operational learning curve and management overhead than Elastic Beanstalk. Running a stateful database in a container adds further complexity.

C. This option is invalid because refactoring the application is not possible without access to the source code, a key constraint mentioned in the scenario.

1. AWS Elastic Beanstalk Developer Guide: "AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java

.NET

PHP

Node.js

Python

Ruby

Go

and Docker... You can simply upload your code and Elastic Beanstalk automatically handles the deployment

from capacity provisioning

load balancing

auto-scaling to application health monitoring." (Source: AWS Documentation

What is AWS Elastic Beanstalk?)

2. AWS Documentation - Deploying Java applications to Elastic Beanstalk: "For Java web applications

you can deploy source bundles in a web application archive (.war file) or a Java archive (.jar file)." This confirms the ability to deploy the application without source code. (Source: AWS Elastic Beanstalk Developer Guide

Deploying Java applications to Elastic Beanstalk)

3. Amazon RDS User Guide: "Amazon RDS is a managed relational database service... It frees you to focus on your applications by managing time-consuming database administration tasks including backups

software patching

monitoring

scaling and replication." This supports using RDS for PostgreSQL to minimize overhead. (Source: AWS Documentation

What is Amazon RDS?)

4. AWS Whitepaper - An Overview of AWS Cloud for Java Developers: This paper discusses various migration paths

highlighting Elastic Beanstalk as a suitable option for developers who want to deploy and manage applications in the AWS Cloud without worrying about the infrastructure that runs those applications. (Source: AWS Whitepapers & Guides

An Overview of AWS Cloud for Java Developers

Page 10)

This solution meets all requirements with the least operational overhead. AWS Transfer Family is a fully managed, highly available service for SFTP. Configuring an internet-facing VPC endpoint allows you to assign a static Elastic IP address in each Availability Zone, fulfilling the vendor whitelisting requirement. Using Amazon EFS as the storage backend provides a highly available, multi-AZ, NFS-compatible file system that directly replaces the on-premises NFS share for downstream applications. This combination of managed services (Transfer Family, EFS, VPC Endpoints) minimizes the need for server management, patching, and manual high-availability configuration, thus ensuring the lowest operational overhead.

B. The default "publicly accessible" endpoint for AWS Transfer Family uses a rotating pool of IP addresses from the AWS fleet and does not support assigning your own static Elastic IPs.

C. Migrating to a single Amazon EC2 instance is not a highly available solution. It also incurs significant operational overhead for managing the OS, SFTP software, and security patching.

D. AWS Application Migration Service (MGN) migrates servers to Amazon EC2, not to a managed service like AWS Transfer Family. This option describes a technically infeasible migration path.

1. AWS Transfer Family Documentation - Endpoint types: "For an internet-facing endpoint in your VPC

you can associate an Elastic IP address with your endpoint. This allows you to provide a fixed IP address for your end users."

Source: AWS Transfer Family User Guide

"Create an internet-facing endpoint in a virtual private cloud".

2. AWS Transfer Family Documentation - EFS Integration: "You can use AWS Transfer Family to transfer files into and out of your Amazon EFS file systems... Amazon EFS provides a simple

scalable

fully managed elastic NFS file system for use with AWS Cloud services and on-premises resources."

Source: AWS Transfer Family User Guide

"Using Amazon EFS storage".

3. AWS Documentation - High Availability for Transfer Family: "AWS Transfer Family is a highly available and scalable service... The service is designed to operate across multiple Availability Zones (AZs) in an AWS Region."

Source: AWS Transfer Family User Guide

"Resilience in AWS Transfer Family".

4. AWS Application Migration Service Documentation: "AWS Application Migration Service (AWS MGN) is the primary migration service recommended for lift-and-shift migrations to AWS. Application Migration Service simplifies and expedites your migration to AWS by automatically converting your source servers from physical

virtual

or cloud infrastructure to run natively on AWS." (Note: "run natively on AWS" refers to EC2 instances).

Source: AWS Application Migration Service User Guide

"What is AWS Application Migration Service?".

The problem describes a brute-force login attack characterized by a high volume of requests ("spike") from a large, rotating set of IP addresses. The most operationally efficient solution is an automated one that does not require manual intervention. An AWS WAF rate-based rule automatically mitigates such attacks by tracking the rate of requests from individual source IP addresses. When an IP exceeds a configured threshold within a 5-minute period, WAF automatically blocks it. This directly addresses the "spike" from numerous IPs without needing to know the specific addresses in advance, making it the most efficient solution.

A. Using a security group to deny specific IPs is operationally inefficient because the list of 500 source IPs changes weekly, requiring constant manual identification and updates.

C. Allowing access only from specific CIDR ranges is not a viable solution for a global application, as it would block legitimate students from unlisted locations.

D. An AWS WAF IP set match rule requires a manually defined list of IP addresses. This is not operationally efficient as the malicious IPs change weekly, necessitating frequent manual updates.

1. AWS WAF Developer Guide

"Rate-based rule statement": This document states

"A rate-based rule tracks the rate of requests for each originating IP address... If an IP address breaches the limit

the rule action is applied to that IP address." This directly supports the automated

efficient nature of the solution in option B for handling brute-force attempts.

2. AWS WAF Developer Guide

"How AWS WAF works": This guide explains that you can "associate a web ACL with one or more AWS resources

" including an Application Load Balancer. This confirms the integration described in the question.

3. AWS WAF Developer Guide

"IP set match rule statement": This document describes IP set match rules as checking "if the IP address of a web request is in a set of IP addresses and address ranges that you specify." This highlights the manual configuration required

making option D less efficient than option B.

4. Amazon VPC User Guide

"Security groups for your VPC": This guide details that security groups act as a firewall for associated instances

controlling inbound and outbound traffic at the instance level. While powerful

they are less suited for application-layer threats and less efficient for managing large

dynamic IP blocklists compared to AWS WAF.

The most secure method for granting a third-party, cross-account access is to use an IAM role with a trust policy that requires an external ID. This approach provides temporary credentials via the sts:AssumeRole action, adhering to the principle of least privilege. The external ID is a unique value shared between the customer and the partner, which the partner must include in the assume-role request. This prevents the "confused deputy" problem, where the partner could be tricked into using its permissions to act on an unauthorized account's resources.

A. Sharing root account access keys provides unrestricted access and is the least secure method, violating fundamental AWS security best practices.

B. Using long-lived IAM user credentials is less secure than using temporary credentials obtained by assuming a role, as they are more susceptible to compromise.

C. While using an IAM role is the correct pattern, it is not the most secure method without an external ID, leaving it vulnerable to the confused deputy problem.

1. AWS IAM User Guide

"How to use an external ID when granting access to your AWS resources to a third party": This document explicitly states

"For security

we recommend that you use an external ID... The external ID is a piece of information that you can use in an IAM role trust policy to designate who can assume the role." It further explains how this mitigates the confused deputy problem.

2. AWS IAM User Guide

"IAM tutorial: Delegate access across AWS accounts using IAM roles": This tutorial outlines the standard procedure for cross-account access using roles. The section on "Role trust policy" shows how to specify the trusted account principal

which is the foundation for the solution.

3. AWS Security Best Practices Whitepaper

"AWS Security Best Practices" (Page 21): This whitepaper advises

"When you grant a third party access to your AWS resources

you should use an IAM role. In the role's trust policy

you should use an external ID." This reinforces the use of an external ID as a best practice for third-party access scenarios.

This solution provides a highly scalable and resilient architecture for handling unpredictable traffic bursts without data loss. Amazon API Gateway is a managed service designed to handle API traffic at scale. By using a direct AWS service integration, API Gateway can place incoming requests directly into an Amazon SQS queue. This decouples the API ingress from the backend processing. The SQS queue acts as a durable buffer, absorbing traffic spikes and ensuring that no data is lost. An AWS Lambda function is then triggered by messages in the SQS queue, providing a scalable, event-driven compute layer to process the data asynchronously. This serverless pattern is cost-effective and automatically scales with the workload.

A. This architecture is not valid. An Application Load Balancer (ALB) cannot directly add an SQS queue as a target for its target group. ALB targets must be instances, IP addresses, Lambda functions, or other ALBs.

C. This synchronous pattern is less resilient to unpredictable bursts. A sudden traffic spike could overwhelm the EC2 instances before the Auto Scaling group can react, leading to request throttling and potential data loss.

D. This architecture is not valid. Amazon CloudFront cannot use an Amazon Kinesis Data Stream as a direct origin. A CloudFront origin must be an accessible HTTP endpoint, such as an S3 bucket, an ELB, or API Gateway.

1. API Gateway to SQS Integration: AWS API Gateway Developer Guide

"Working with AWS service integrations for HTTP APIs". The guide details how to configure an integration to send requests to other AWS services

including SQS. The tutorial "Creating an HTTP API with an AWS service integration" provides a concrete example.

2. Decoupling with SQS: AWS Documentation

Amazon SQS Developer Guide

"Common Amazon SQS use cases". Section "Decouple microservices" explains how SQS queues can be used as a buffer between components of an application that may produce and consume messages at different rates

which is ideal for handling traffic bursts.

3. ALB Target Groups: AWS Documentation

Elastic Load Balancing User Guide for Application Load Balancers

"Target groups for your Application Load Balancers". This page lists the valid target types for an ALB target group as: instance

ip

lambda

and application-load-balancer. SQS is not a supported target type.

4. CloudFront Origins: AWS Documentation

Amazon CloudFront Developer Guide

"Working with origins". This section specifies that origins can be Amazon S3 buckets

MediaStore containers

MediaPackage channels

or custom origins (like an HTTP server

which includes an ELB or EC2 instance). Kinesis Data Streams is not a valid origin type.

This solution addresses cost optimization for both the frontend and backend tiers. The frontend is a static website, which is ideally suited for hosting on Amazon S3. This serverless approach is highly available, scalable, and significantly more cost-effective than running dedicated EC2 instances and a load balancer.

For the backend, the application is fault-tolerant (running on three instances behind an ALB) and has a spiky usage pattern. Switching from On-Demand to Spot Instances for the backend EC2 instances can provide savings of up to 90%. Because the application is already designed to be resilient to the failure of a single instance, it is a perfect candidate for Spot Instances, which can be interrupted. This combination maximizes cost savings without impacting availability.

A. Changing instance families does not address the core problem of over-provisioning for a workload that is only busy for a short period.

C. AWS Elastic Beanstalk still runs on EC2 instances, and using the same instance type would not result in any cost savings.

E. Burstable (T-family) instances are not ideal for sustained peak loads like a lunchtime rush, as they can exhaust their CPU credits and be throttled, negatively affecting performance.

1. Hosting a static website using Amazon S3: AWS Documentation clearly states

"You can host a static website on Amazon S3. On a static website

individual webpages include static content... In contrast

a dynamic website relies on server-side processing... A simple and low-cost way to host a static website is to use Amazon S3."

Source: AWS S3 Developer Guide

"Hosting a static website using Amazon S3".

2. Amazon EC2 Spot Instances Best Practices: AWS documentation recommends using Spot Instances for fault-tolerant and flexible applications. "Because Spot Instances are tightly integrated with AWS services such as Auto Scaling... you can leverage Spot Instances for a variety of fault-tolerant and flexible applications. Examples include... web services..."

Source: AWS EC2 User Guide for Linux Instances

"Spot Instance requests"

Section: "Spot best practices".

3. Cost Optimization Pillar

AWS Well-Architected Framework: This whitepaper advises using the most cost-effective resources. "Use serverless architectures to remove the need for you to run and maintain servers to carry out traditional compute activities. For example

storing static assets in Amazon S3 instead of on servers."

Source: AWS Well-Architected Framework

Cost Optimization Pillar whitepaper (aws-well-architected-framework.pdf)

Page 18

Section: "Cost-effective resources".

4. Burstable performance instances: The documentation explains the CPU credit mechanism and the risk of throttling. "If your instance requires high CPU for a prolonged period

you can... pay a flat additional fee per vCPU-hour... Or

we recommend using a fixed performance instance size..." This indicates burstable instances are not suited for sustained peaks.

Source: AWS EC2 User Guide for Linux Instances

"Burstable performance instances".