AWS Certified Solutions Architect Professional Practice Test (SAP-C02)

AWS Global Accelerator offers two static anycast IP addresses and continuously probes regional endpoints. When an endpoint or Region becomes unhealthy, Global Accelerator removes it from service in well under one minute and immediately routes new connections to healthy endpoints, so the 30-second objective is met. Because the same static IP addresses are used before and after failover, client devices and corporate firewalls require no DNS updates or configuration changes.

Route 53 DNS failover still depends on recursive resolvers honoring a low TTL; many resolvers cache records longer than the configured TTL, so convergence can exceed the 30-second goal and exposes changing IP addresses. CloudFront origin failover is limited to GET/HEAD/OPTIONS requests and, by default, can spend up to 30 seconds trying the primary origin before switching, which may breach the RTO and does not provide static IPs. Direct Connect is a private network link; shifting traffic between Regions requires BGP route manipulation and cannot guarantee automated failover within the required timeframe. Therefore, deploying AWS Global Accelerator in front of the existing Application Load Balancers is the most reliable and operationally efficient solution.

AWS Backup can automate snapshot creation and retention while handling encryption keys. For Amazon RDS snapshots, a single copy job can be either cross-account or cross-Region, but not both. The simplest compliant design therefore uses two managed copy rules:

1. A daily backup plan in the production account copies each snapshot to a backup vault that resides in the DR account but stays in the same Region (us-east-1).
2. A second backup plan that runs in the DR account automatically copies the incoming snapshots to a vault in us-west-2 and sets the 35-day retention.

Because the snapshots end up in the DR account, operators there can restore the database independently. All steps are fully managed once the plans and customer-managed CMKs are in place, so operational effort is minimal.

The alternative proposals fail at least one requirement:

• Cross-Region automated backups replicate only inside the same account and still need manual snapshot sharing, increasing effort.
• A cross-Region read replica provides replication, not immutable backups, and retention is lost if the replica is removed.
• A single AWS Backup rule that is simultaneously cross-account and cross-Region is not supported for RDS snapshots.

The correct answer is to use VPC Reachability Analyzer. This tool is specifically designed to perform static analysis of network paths between a source and a destination. It checks the configurations of route tables, security groups, network ACLs, and Transit Gateways without sending any live packets. This allows it to quickly identify the specific component that is blocking connectivity, making it the most efficient first step for this scenario.

• Using VPC Flow Logs and Amazon Athena is a valid troubleshooting method, but it is less efficient. It requires enabling logs, waiting for traffic to be captured, and then performing complex queries on potentially large datasets to find the problem. This is more time-consuming than using the purpose-built Reachability Analyzer.
• The Route Analyzer feature in Transit Gateway Network Manager is not the best tool for this task because it only analyzes routes within the Transit Gateway route tables. It does not analyze VPC route tables, security group rules, or network ACLs, which are common sources of connectivity problems.
• Configuring Route 53 Resolver Query Logging would be appropriate if the problem were related to DNS name resolution. However, the scenario describes a failure to connect to a specific IP address, which points to a network path issue, not a DNS issue.

A warm-standby pattern keeps a scaled-down but fully functional copy of the entire stack running in a second Region. Aurora Global Database and ElastiCache for Redis Global Datastore replicate data with typical latencies of less than 1 second, so the RPO is well under 1 minute. Because the ECS services, ALB, and other infrastructure are already deployed (albeit at minimal size), the environment only needs to scale out and Route 53 needs to redirect traffic, which can be completed within the 5-minute RTO.

With AWS Elastic Disaster Recovery, compute resources are provisioned only after failover; its typical RTO is 5-20 minutes, so it cannot guarantee a 5-minute target. A pilot-light strategy runs no application tier at all, so provisioning the full stack usually takes tens of minutes, exceeding the RTO. An active-active design would meet the objectives but costs significantly more because both Regions run at full production scale at all times. Therefore, the warm-standby solution is the most cost-effective option that satisfies both the 1-minute RPO and 5-minute RTO.

ElastiCache Global Datastore replicates Redis data to up to two secondary Regions with typical cross-Region lag of less than 1 s, enabling sub-millisecond local reads while writes occur only in the primary Region. Using a write-through pattern keeps the cache hot and ensures replicas converge well inside the 2-minute consistency window. Because 90 % of requests are now served from in-memory caches close to users, p99 latency comfortably drops below 100 ms and Aurora writer CPU load is relieved without expensive multi-Region database clusters. Aurora Global Database would meet latency but requires full secondary clusters, dramatically increasing cost; migrating to DynamoDB with DAX demands a data-model change and additional engineering effort; edge caching with CloudFront cannot guarantee a warm cache globally, adds invalidation complexity, and leaves the database hot. Therefore, deploying an ElastiCache for Redis Global Datastore and adopting a write-through caching strategy is the most cost-effective way to satisfy all stated requirements.

The correct answer is to configure VPC Traffic Mirroring on the relevant ENIs and set the target to a Network Load Balancer (NLB) in the inspection VPC. VPC Traffic Mirroring is designed to copy network traffic from an Elastic Network Interface (ENI) and forward it to a target for out-of-band inspection. This is the ideal solution for an Intrusion Detection System (IDS), which passively analyzes traffic without being in the direct path. Using a Network Load Balancer as the target allows the mirrored traffic to be distributed across a fleet of IDS appliances, ensuring scalability and high availability. This approach has minimal performance impact because it duplicates the traffic rather than routing it through the appliances, avoiding any added latency or a potential single point of failure in the production traffic path.

• Incorrect: Enabling VPC Flow Logs is incorrect because Flow Logs capture metadata about IP traffic (e.g., source/destination IPs, ports, protocol) but do not capture the actual packet payloads. Deep packet inspection (DPI) requires analyzing the full packet content, which is not available in Flow Logs.
• Incorrect: Deploying AWS Network Firewall is incorrect because the requirement is to use a specific fleet of third-party IDS appliances. AWS Network Firewall is a managed AWS service and would not fulfill this explicit requirement.
• Incorrect: Using a Gateway Load Balancer (GWLB) in an in-line configuration is incorrect for this use case. A GWLB is designed to transparently insert appliances into the traffic path for in-line inspection, which is typical for an Intrusion Prevention System (IPS). Since the requirement is for a passive IDS, routing all traffic through the appliances would add unnecessary latency and complexity. The more appropriate and less impactful solution is to copy the traffic using Traffic Mirroring.

The correct answer identifies the fundamental networking challenge with inspecting east-west traffic for Fargate tasks. Fargate tasks are required to use the awsvpc network mode, where each task is assigned its own Elastic Network Interface (ENI) and a private IP address from the VPC's subnet. This means that when one microservice communicates with another in the same VPC, the traffic flows directly between their ENIs within the subnet. Standard VPC routing does not intercept this intra-subnet traffic, making it difficult to force it through a centralized inspection point. To solve this, an architect must implement an advanced networking pattern. Common solutions include using an AWS Transit Gateway to route traffic between different VPCs (or different subnets) to a dedicated 'inspection VPC' where the security appliances are hosted. Another modern approach involves using a service mesh that can control and redirect traffic at the application layer.

Incorrect answers are:

• Fargate tasks absolutely can and do use security groups. A security group is associated with each task's ENI, providing stateful, instance-level firewall capabilities. Stating that they cannot be assigned is factually incorrect.
• While it's true that Fargate does not support host network mode, this mode is irrelevant to the problem of inspecting traffic between separate tasks. Host mode ties a container's networking directly to the underlying host's network stack, which is a concept antithetical to the Fargate serverless model.
• An Application Load Balancer (ALB) primarily manages north-south (ingress) traffic from clients to the services. It does not typically handle direct east-west (service-to-service) communication. Even if it did, the challenge is routing the traffic for inspection, not the encryption itself.

The correct answer is to use AWS Glue and Amazon Athena. This combination is the AWS-recommended, serverless, and most operationally efficient method for querying AWS Cost and Usage Reports (CUR). When CUR is configured for Athena integration, AWS delivers the data in the optimal Apache Parquet format and provides a CloudFormation template to automatically create the necessary AWS Glue crawler and Data Catalog table. The Glue crawler automatically discovers the schema and partitions, making the data available for querying via Athena with standard SQL. This approach requires minimal setup and no infrastructure to manage, directly addressing the requirement for the least operational overhead.

• Using Amazon EMR is incorrect because it introduces significant operational overhead. While EMR is a powerful big data platform, it requires provisioning and managing a cluster of EC2 instances, which is more complex and costly than the serverless Athena model for this use case.

• Using AWS Lambda to load data into an Amazon RDS database is incorrect because it involves substantial development and maintenance effort. The architect would need to write and maintain code for parsing, data transformation, and loading. Furthermore, RDS is a transactional database and less cost-effective for the large-scale analytical queries typically run against CUR data compared to Athena.

• Using Amazon S3 Select is incorrect because it is designed to query data within a single S3 object. While useful for simple filtering, it is not suitable for running complex, ad-hoc analytical queries that span the thousands of files that make up a complete CUR dataset. This approach would require a complex client-side application to orchestrate queries and aggregate results, creating high operational overhead.

Running enable-organization-admin-account from the organization management account designates the security-tooling account as the Security Hub delegated administrator in the current Region; repeating the call (or using central-configuration) in every active Region ensures that the same account is admin everywhere. In the delegated administrator account, update-organization-configuration with AutoEnable=true (and the default standards setting) automatically adds every existing and future member account as a Security Hub member in every Region, so findings flow to the delegated administrator without additional setup. Finally, an SCP applied at the root that explicitly denies securityhub:EnableOrganizationAdminAccount (except for the management account) blocks any other account from changing the delegated administrator. This combination satisfies all three requirements with a single point of administration and no per-account maintenance. The other options either rely on manual EventBridge forwarding, require per-account StackSet deployments, or depend on Control Tower guardrails that neither auto-enable Security Hub in every Region nor prevent other accounts from changing the administrator.

The correct answer is to configure Provisioned Concurrency for the Lambda function. This feature is specifically designed for applications that require predictable, low-latency performance by keeping a specified number of execution environments initialized and ready to respond in double-digit milliseconds. This directly addresses the two main requirements: eliminating cold start latency to meet the sub-100ms SLA during sudden bursts and optimizing costs compared to running a constantly active EC2 fleet.

• Increasing the function's memory allocation does provide more CPU power, which can reduce both cold start duration and execution time. However, it does not eliminate the cold start itself. The first request to an idle function will still experience initialization latency, which could violate the strict SLA. This makes it a helpful optimization but not the primary solution for guaranteed low latency.
• Creating a scheduled Amazon EventBridge rule to invoke the function every few minutes is a technique known as a "pinger" or "warmer". This is an outdated practice that is now considered an anti-pattern. It typically only keeps a single execution environment warm, which is insufficient for handling high-throughput bursts of traffic, and it is less reliable and efficient than Provisioned Concurrency.
• While an Application Load Balancer (ALB) can use a Lambda function as a target, using its health check mechanism to keep the function warm is not a recommended or effective pattern for this use case. ALB health checks are designed to monitor target health and route traffic accordingly, not to manage Lambda execution environments for performance. Provisioned Concurrency is the purpose-built AWS feature for this scenario.

The correct answer is to create a VPC interface endpoint for the third-party's service. By using AWS PrivateLink, traffic from the EC2 instances to the third-party API will be routed through the interface endpoint over the AWS private network, completely bypassing the NAT Gateways. This directly eliminates the "NAT Gateway - Data Processed" charge for this traffic, which is the primary cost driver identified in the scenario. While the VPC endpoint has its own hourly and data processing fees, the data processing fee for an interface endpoint is significantly lower ($0.01 per GB) than that of a NAT Gateway ($0.045 per GB), resulting in substantial savings.

• Consolidating to a single NAT Gateway would actually increase costs for a multi-AZ application. Traffic originating from instances in other Availability Zones would first incur an inter-AZ data transfer fee ($0.01/GB) to reach the NAT Gateway, and then the standard NAT Gateway processing fee would still apply on top of that. This approach also introduces a single point of failure, which contradicts the high-availability requirement.
• A caching proxy layer only reduces costs for redundant data requests. Any request for new or unique data would still need to be fetched from the internet, incurring data transfer processing fees. Since AWS PrivateLink eliminates the NAT Gateway processing cost for all traffic to the provider, it is a more comprehensive and cost-effective solution.
• AWS Direct Connect is a service used to establish a dedicated private network connection from an on-premises data center to AWS. It cannot be used to connect resources within a VPC to a third-party service hosted on the public internet.

Deploying AWS Global Accelerator is the best solution. Global Accelerator allocates two static anycast IP addresses that serve as fixed entry points, simplifying firewall whitelisting for corporate clients. It supports both TCP and UDP, so it works with the company's custom TCP-based streaming protocol. Because Global Accelerator operates at the network layer and continuously health-checks all registered regional endpoints, traffic is automatically and almost immediately redirected to the nearest healthy Region-without waiting for DNS TTLs to expire.

Incorrect answers:

• Amazon CloudFront is optimized for HTTP/HTTPS and WebSocket traffic and cannot proxy an arbitrary TCP-based streaming protocol.
• Amazon Route 53 can perform DNS-based latency or failover routing, but failover depends on DNS TTLs and client caches, and it still exposes many NLB IP addresses that clients must whitelist.
• AWS Direct Connect is a private network service for on-premises connectivity and does not provide global static IPs or cross-Region failover for public internet users.

Using an IAM permissions boundary provides a built-in, automatic mechanism to restrict the maximum permissions that any developer-created role can receive. By requiring the iam:PermissionsBoundary condition key to match the ARN of the security team's guardrail policy, developers can freely call iam:CreateRole, iam:PutRolePolicy, or iam:AttachRolePolicy, but the resulting roles can never exceed the boundary's scope. This satisfies least-privilege goals without any manual review.

A service control policy that blocks iam:CreateRole (choice B) forces the security team to provision every role themselves, preventing developer self-service. AWS Config remediation (choice C) detects problems after the fact and allows overly broad roles to exist until the rule is evaluated and remediated, violating the requirement for immediate enforcement. ABAC based only on Environment tags (choice D) does not stop a developer from attaching AdministratorAccess or other excessive permissions to a role; it simply constrains which resources the role may act on.

Therefore, configuring and enforcing an IAM permissions boundary is the most secure and automated approach.

Aurora Global Database replicates storage to secondary Regions with a typical replication lag of less than one second, meeting the 30-second RPO. It also supports managed cross-Region failover that typically completes in well under a minute, satisfying the 60-second RTO. By combining it with Route 53 Application Recovery Controller routing controls, failover and DNS redirection can be triggered automatically without operators, achieving the operational-excellence goal.

A cross-Region read replica (distractor) offers a similar RPO but requires manual promotion via control-plane APIs; documented failover times are usually several minutes, so it misses the RTO. Multi-AZ deployments with replicated snapshots (distractor) provide only in-Region HA; restoring from snapshots after a regional outage far exceeds both RTO and RPO. Migrating to DynamoDB global tables (distractor) could achieve the objectives, but re-architecting the relational workload and running fully active resources in multiple Regions would significantly increase cost and complexity, violating the cost-effectiveness constraint.

An Amazon SQS FIFO queue guarantees strict message ordering and offers exactly-once processing through message deduplication. Enabling high-throughput mode allows the queue to scale automatically to many thousands of messages per second without manual sharding. Using the order ID as the MessageGroupId confines ordering to each individual order while permitting parallel processing across different orders, and turning on content-based deduplication prevents accidental re-submission of the same order from creating duplicates.

A standard queue does not guarantee ordering and can deliver duplicates, so the consumer would still have to guard against both issues. A FIFO queue that uses a single MessageGroupId preserves order and eliminates duplicates but limits throughput to a single message group, which cannot handle tens of thousands of orders per second. An SNS FIFO topic with an SQS FIFO queue subscription is a valid pattern for ordered, exactly-once delivery, but it adds an unnecessary additional service to manage and introduces complexity when an SQS FIFO queue alone can solve the problem.

A mixed-instances EC2 Auto Scaling group can combine On-Demand and Spot capacity in one fleet. Setting OnDemandBaseCapacity to 100 guarantees that the first 100 instances that launch-and any time the group scales-are On-Demand, so the SLA is always met. Setting OnDemandPercentageAboveBaseCapacity to 0 forces every additional instance to be Spot, maximizing cost savings. Using the capacity-optimized SpotAllocationStrategy directs the request to pools with the greatest spare capacity, which have the lowest probability of interruption. Enabling Capacity Rebalancing instructs the Auto Scaling group to launch replacement Spot Instances proactively when Amazon EC2 sends a rebalance recommendation, maintaining capacity even during interruptions. The other options either do not guarantee the 100-instance baseline, choose a lowest-price strategy with a higher interruption risk, or rely on external scripts rather than automated rebalance replacement.

The correct answer is to use AWS Compute Optimizer to generate recommendations and migrate the instances to a memory-optimized instance family. The workload is clearly memory-bound, not CPU-bound, as indicated by the high memory utilization and low CPU utilization. The m5 instance family is general-purpose. A memory-optimized family, such as the R-series, is better suited for this workload. AWS Compute Optimizer is the ideal tool for this scenario because it analyzes historical utilization data (including memory, if the CloudWatch agent is configured) and recommends optimal instance types, often suggesting changes across instance families (e.g., M to R) and to Graviton-based instances for further cost savings. It also supports cross-account recommendations, which fulfills the requirement for a systematic approach across the organization.

• Using Cost Explorer Rightsizing recommendations to downsize to m5.2xlarge is incorrect because it keeps the instance within the same general-purpose family, failing to address the core issue of the workload being memory-bound. While Cost Explorer provides rightsizing recommendations, Compute Optimizer offers more detailed performance-oriented analysis and is the superior tool for this specific optimization task.
• Implementing an Auto Scaling group is not suitable for a stateful, monolithic application without significant re-architecture. Furthermore, a scaling policy based on CPU utilization would be ineffective since the application's bottleneck is memory, not CPU.
• Refactoring the application to a containerized microservices architecture on Amazon EKS is a major modernization project, not a rightsizing strategy. While it could be a valid long-term goal, it does not address the immediate requirement to optimize the existing fleet for cost and performance.

The correct answer describes a classic warm standby architecture. In the DR region (us-west-2), a scaled-down but functional version of the application is running. This includes using an Amazon RDS cross-region read replica for asynchronous data replication, which is suitable for meeting a low RPO like 1 minute. A minimal Auto Scaling group (with a desired capacity of one) keeps the application tier running and ready to be scaled up quickly, which is a key characteristic of warm standby and essential for a 15-minute RTO. A small, single-node ElastiCache cluster is also provisioned to complete the minimal running environment. Upon failover, the RDS replica is promoted, the Auto Scaling group is scaled out, and Amazon Route 53 redirects traffic, all of which can be accomplished within the 15-minute RTO.

• The option suggesting deploying a new stack from AMIs and RDS snapshots describes a backup and restore strategy. This approach would have a much higher RTO and RPO, failing to meet the specified 15-minute RTO and 1-minute RPO.
• The option suggesting a fully scaled environment with latency-based routing describes a hot standby (or multi-site active/active) strategy. While it would meet the RTO/RPO, it is far more expensive than the required warm standby approach.
• The option suggesting an Auto Scaling group with a minimum capacity of zero describes a pilot light strategy, not a warm standby. A pilot light approach does not have servers running and ready to take traffic, which would make meeting a 15-minute RTO challenging.

The simplest native-service approach is to rely on the AWS cost-management stack that is already integrated with AWS billing data.

1. Activate a user-defined cost allocation tag such as "Team" in the management account so that the tag becomes visible in billing data. Activating the tag is required before it can be used for reporting.
2. Create an AWS Cost Category that inherits the Team tag and sets a default value (for example, NoOwner) for all line items that do not contain the tag. This automatically groups both tagged and untagged spend without any external processing.
3. Use AWS Cost Explorer to build a monthly view that is grouped by the new cost-category values. Cost Explorer can also display a forecast of up to 12 months, which covers the next quarter and requires no additional setup.
4. For each cost-category value, create an AWS Budget that has a forecasted alert threshold of 110 % (10 % over the team's budgeted amount). Configure the budget to send email (or SNS) notifications when the threshold is crossed.

This solution meets every requirement, is entirely managed by AWS, and avoids the data-pipeline maintenance associated with exporting and querying the Cost and Usage Report or building custom dashboards. The other options either require significantly more operational work (for example, CUR + Athena + QuickSight), do not identify untagged resources, or use services that do not provide the required forecasting and alerting capabilities.

Running the containers in an Amazon ECS service on AWS Fargate removes the need to manage servers or clusters. A target-tracking scaling policy on the ALBRequestCountPerTarget metric automatically adds or removes tasks so that each task handles roughly the specified number of requests, allowing the service to scale from one task during idle periods to hundreds of tasks within minutes and keep latency under 200 ms. A capacity-provider strategy that gives higher weight to FARGATE_SPOT than FARGATE launches tasks on discounted Fargate Spot whenever spare capacity is available, cutting compute cost by up to 70 percent, while still permitting on-demand Fargate tasks if Spot capacity is unavailable. The alternative solutions either retain idle EC2 or Provisioned Concurrency capacity, add operational overhead, or rely solely on Spot Instances without a cost-effective fallback, so they do not meet both the cost and performance goals as effectively.