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

The correct answer is AWS Systems Manager State Manager. State Manager is designed to be a scalable configuration management service that automates the process of keeping managed nodes in a defined state. It uses documents to define the desired configuration and 'associations' to apply that configuration to a target set of instances on a schedule. State Manager continuously monitors the fleet for configuration drift and reports compliance status to a central dashboard, which directly addresses the key requirements of the scenario.

• AWS Systems Manager Run Command is used for executing ad-hoc or on-demand commands on managed instances. While it can be used to apply a configuration once, it does not inherently maintain a persistent state or automatically scan for and remediate configuration drift over time, making it less effective for this use case than State Manager.
• AWS Systems Manager Distributor is used to securely store and distribute software packages to managed instances. While it can be used as part of a configuration management solution (for example, a State Manager association could use Distributor to install a package), it does not by itself enforce the configuration or manage drift. It is a tool for package distribution, not state management.
• AWS Systems Manager Patch Manager is a specialized service for automating the process of patching operating systems and applications with security and other updates. Its scope is limited to patching and does not cover general-purpose configuration management, such as installing specific software or enforcing custom security settings as required by the scenario.

Provisioning a second dedicated 10 Gbps Direct Connect connection in a different colocation facility and attaching private VIFs from both connections directly to the VPC's virtual private gateway meets all three requirements:

• Two geographically diverse connections protect against a complete location failure and allow active/active traffic flow for 20 Gbps aggregate bandwidth.
• MACsec can be enabled on each dedicated link to deliver Layer-2, near line-rate encryption between the customer router and the AWS Direct Connect device, eliminating the performance penalties of overlay IPsec tunnels.
• Direct Connect traffic is not encrypted by default, so MACsec satisfies the company's end-to-end encryption requirement.

Other choices are less suitable:

• Creating a Link Aggregation Group (LAG) in the same facility doubles bandwidth but still fails if the location goes offline.
• Adding IPsec VPN over Direct Connect provides encryption but lowers effective throughput and adds operational complexity.
• Upgrading to a single 100 Gbps port at the existing site increases bandwidth but does not address location-level availability or encryption.

The correct answer provides the most secure and least-privilege access by using a specific role-to-role trust relationship and resource-level permissions. An IAM role in the Production account (LambdaUpdateRole) is granted a narrow permission (lambda:UpdateFunctionCode) limited only to the specific Lambda function's ARN. Its trust policy explicitly allows only the EC2 instance's role (ToolsEC2Role) from the Developer Tools account to assume it. This ensures that only the designated EC2 instance can assume the role, and once assumed, the credentials can only be used to update that single Lambda function's code.

Using wildcards for the resource or action is overly permissive and violates the principle of least privilege, as it would allow the role to update any Lambda function, or perform any Lambda action, respectively.

Using an IAM user with long-lived access keys is not a best practice for programmatic access from an EC2 instance. IAM roles provide temporary, automatically rotated credentials, which is a more secure mechanism than managing static keys.

Configuring the trust policy in the Production account's role to trust the entire Developer Tools account root is less secure than trusting the specific role ARN. This configuration would allow any principal in the Developer Tools account with sts:AssumeRole permissions to assume the LambdaUpdateRole, not just the intended EC2 instance.

The correct answer is to use AWS Snowball Edge for the initial bulk transfer and AWS DataSync for the ongoing synchronization. A 1 Gbps connection has a theoretical maximum throughput of about 10.8 TB per day. With only 60% of the bandwidth available (600 Mbps), the effective throughput is approximately 6.5 TB per day. Transferring 500 TB would take roughly 77 days, which does not meet the 30-day requirement. Therefore, an offline transfer method like AWS Snowball Edge is necessary for the initial bulk migration. AWS Snowball Edge Storage Optimized devices are suitable for petabyte-scale transfers. For the ongoing synchronization of the 50 TB active dataset, AWS DataSync is the ideal managed service. It can operate over the existing Direct Connect link, fully automates the incremental data transfer, provides end-to-end encryption, and validates data integrity, making it more efficient and less operationally complex than custom-scripted solutions.

An AWS Cost and Usage Report (CUR) satisfies every requirement. CUR delivers the most granular cost and usage data-including resource IDs, tags, and cost categories-directly to an Amazon S3 bucket and updates it up to three times per day. The CUR data can be visualized without custom ETL by enabling the built-in Cost and usage dashboard powered by QuickSight, and the files stay in S3 for as long as the company's retention policy allows.

Cost Explorer exports do not meet the retention or granularity needs: Cost Explorer keeps only about 13 months of history and its resource-level API is limited to the last 14 days. AWS Budgets generates threshold notifications rather than full cost datasets and updates only a few times per day. AWS Trusted Advisor provides optimization recommendations, not detailed, tag-based cost records. Therefore, enabling CUR with QuickSight integration is the only option that fulfills all the stated requirements.

The correct answer is to create VPC Gateway Endpoints in each Application VPC. Gateway Endpoints are the ideal solution for connecting to Amazon S3 and DynamoDB privately from within a VPC. They provide several key benefits that directly address the requirements. First, they do not consume any IP addresses from your VPC's CIDR block, which is a critical advantage given the concern about IP address exhaustion. Second, they ensure traffic does not traverse the public internet by creating a private route between the VPC and the AWS services. Finally, you can attach an endpoint policy to a Gateway Endpoint to enforce fine-grained access control, restricting access to only the specified S3 buckets and DynamoDB tables, which satisfies the security mandate.

Incorrect options explained:

• Creating Interface Endpoints in each Application VPC is incorrect because Interface Endpoints, which use Elastic Network Interfaces (ENIs), consume private IP addresses from the subnets they are placed in. This would worsen the IP address exhaustion problem, making this solution less resource-efficient than using Gateway Endpoints.
• Centralizing Interface Endpoints in a Shared Services VPC is incorrect for two main reasons. While Interface Endpoints can be accessed over a Transit Gateway, Gateway Endpoints cannot; this architecture forces the use of the more expensive and IP-consuming Interface Endpoints. This design also introduces unnecessary complexity and potential data transfer costs associated with routing traffic through the Transit Gateway and the central VPC.
• Using a NAT Gateway is incorrect because it is designed to allow instances in private subnets to connect to the internet. Traffic routed through a NAT Gateway to access AWS services would traverse the public internet to reach the public service endpoints, which explicitly violates the security requirement that traffic must remain within the AWS network.

The correct answer is to implement shuffle sharding. Shuffle sharding is an advanced architectural pattern that provides a high degree of workload isolation and blast radius reduction. It works by creating many virtual shards from a smaller pool of resources (the worker fleet) and assigning each tenant to a unique combination of these resources. In the event of a poison pill taking down the resources in one virtual shard, only the very small number of tenants assigned to that specific combination are affected. This massively reduces the blast radius compared to traditional sharding.

Implementing a separate Auto Scaling group for each tenant is an example of a bulkhead pattern, but it is not practical or cost-effective for a large-scale, multi-tenant application with thousands of tenants due to the high operational overhead and resource underutilization.

Using a standard Multi-AZ Auto Scaling group with an Application Load Balancer is a fundamental high-availability pattern that protects against Availability Zone failures, not application-level correlated failures like a poison pill. A poison pill would cause instances in all Availability Zones to fail, eventually affecting the entire fleet.

Configuring a dead-letter queue (DLQ) on the SQS queue is an essential practice for handling poison pill messages, but it does not solve the architectural problem of blast radius for the compute fleet. The DLQ isolates the problematic message after it has failed processing multiple times, but during those failures, it would have already impacted the shared compute fleet, affecting all tenants. Shuffle sharding proactively contains the impact of the compute failure itself.

A centralized Amazon EKS cluster that runs all workloads on AWS Fargate removes the need to provision, patch, or scale EC2 worker nodes, satisfying the low-maintenance requirement. Subnets from the networking account can be shared with workload accounts by using AWS Resource Access Manager, so the network team retains control of VPC constructs while application teams can place ENIs for their pods in the shared subnets. The Amazon EFS CSI driver allows pods running on Fargate to mount the existing file system with static provisioning. Finally, mapping each Kubernetes service account to an IAM role by using IAM roles for service accounts provides temporary, least-privilege credentials inside the pod and avoids relying on the node's instance profile. The other options either require ongoing EC2 node management, store long-lived credentials inside pods, or fail to give the networking team continued ownership of the VPC.

The correct answer is to implement a blue/green deployment strategy using AWS CodeDeploy. This strategy involves creating a new, separate 'green' environment with the new application version that runs alongside the existing 'blue' production environment. Once the green environment is fully tested and ready, traffic is shifted from the blue environment to the green environment via the Application Load Balancer. This cutover is nearly instantaneous, eliminating downtime. If any issues are detected, a rollback is just as fast, as traffic can be immediately rerouted back to the old blue environment, which remains on standby until the green environment is deemed stable.

An in-place rolling update is incorrect because, while it avoids complete downtime, it introduces risk by having a mix of old and new application versions running simultaneously. This can be problematic for monolithic applications and makes rollbacks more complex than a simple traffic switch.

Using AWS Elastic Beanstalk with a managed rolling update policy is a plausible but less optimal choice. While Elastic Beanstalk simplifies deployments, it abstracts a significant amount of control. For a critical financial application, a more granular and customizable solution using a dedicated CI/CD pipeline with AWS CodeDeploy is generally preferred to maintain fine-grained control over the deployment process.

Automating the current all-at-once deployment with AWS Systems Manager Run Command is incorrect because it only automates a fundamentally flawed process. It would make the deployment faster but would not solve the core problems of application downtime and the high risk associated with an all-at-once cutover.

Publishing to a single Amazon SNS standard topic and attaching a filter policy to each subscription offloads all routing logic to the managed service. Each microservice still consumes from its own SQS queue, but it now receives only the event types that match its payload-based filter policy. This removes the custom Lambda router and scales automatically with no additional code or infrastructure.

EventBridge rules (second choice) could also filter messages, but it introduces another managed service and additional cost when SNS alone is sufficient. Creating three separate SNS topics (third choice) forces application changes and duplicates publishes, increasing complexity. Using an SNS FIFO topic with the eventType as the message-group ID (fourth choice) does not restrict delivery to particular subscribers-every subscribed queue still receives all messages unless a filter policy is added, so the router logic would remain necessary.

The correct answer is to use an EC2 Fleet with a Spot allocation strategy and launch instances into a Cluster Placement Group.

• Cluster Placement Group: This is the only placement strategy that groups instances into a low-latency, high-throughput network within a single Availability Zone. This directly addresses the requirement for the lowest possible inter-node latency for a tightly-coupled High-Performance Computing (HPC) workload.
• Spot Allocation Strategy: Since the workload is interruptible and cost-sensitive, Spot Instances are the most cost-effective compute pricing option.
• EC2 Fleet with Multiple Instance Types: Using an EC2 Fleet (or an Auto Scaling group with a mixed instances policy) with multiple suitable instance types specified (e.g., using attribute-based instance selection) addresses the need for compute capacity resilience. If one instance type has limited Spot capacity, the fleet can provision other specified instance types, ensuring the workload can run.

Incorrect answers explained:

• Partition Placement Group: This strategy is designed for large, distributed workloads like HDFS or Cassandra, where instances are spread across logical partitions on distinct hardware racks. It does not provide the lowest possible latency required for tightly-coupled workloads.
• Spread Placement Group: This strategy places each instance on distinct underlying hardware to reduce correlated failures. This maximizes the availability of individual critical instances but increases inter-node latency, making it unsuitable for this use case.
• Cluster Placement Group spanning multiple Availability Zones: This option is incorrect because a Cluster Placement Group, by design, cannot span multiple Availability Zones. This is a fundamental limitation that an architect must know when designing for low-latency networking.

A single AWS Organization keeps billing and top-level governance centralized, so the management account can continue to generate one consolidated invoice. Creating separate top-level workload OUs-one for HIPAA-regulated healthcare workloads and another for PCI-regulated payment workloads-provides clear isolation and lets the platform team attach distinct SCP sets to each OU for the relevant compliance framework. The existing Security OU can remain unchanged, allowing both subsidiaries to consume the shared log-archive and security-tooling accounts without duplication. Spinning up a second AWS Organization would eliminate the single bill and double the effort required to maintain guardrails, while keeping all workloads in one flat OU or (worse) in a single shared account would fail to provide the necessary regulatory isolation and granular policy control.

An Amazon EC2 Auto Scaling group that uses a mixed-instances policy meets every stated need:

• Low-latency networking - Launching the ASG in a cluster placement group keeps instances in the same AZ rack segment, achieving the high-bandwidth, sub-millisecond latency required.
• Key isolation - Enabling Nitro Enclaves in the launch template creates an isolated execution environment that even root on the parent instance cannot access and that integrates natively with AWS KMS. Nitro Enclaves is supported on Intel, AMD, and Graviton instance families.
• Graviton adoption with x86 compatibility - A mixed-instances ASG can reference multiple launch templates (one Arm64 AMI for M6g, one x86_64 AMI for M6i) and use instance weights so that capacity can be satisfied by either architecture, allowing a gradual, risk-free migration.
• Horizontal scaling & rolling updates - Auto Scaling handles scale-out/scale-in based on metrics, and Instance Refresh (or rolling updates in CloudFormation) provides zero-downtime deployments with minimal management.

The other options fail at least one requirement:

• ECS Fargate cannot run Nitro Enclaves and cannot guarantee sub-millisecond latency between tasks, so it does not satisfy the key-isolation or latency needs.
• Dedicated Hosts with CloudHSM isolate keys but add significant cost and operational overhead, and this option fails to address the requirement for a phased migration to Graviton.
• Lambda-based rewrite removes control over intra-function network latency, is not an ideal architectural fit for this type of sustained compute workload, and offers no enclave-like isolation for the key-handling service.

Therefore, the mixed-instances EC2 Auto Scaling solution is the only one that covers every constraint with the lowest operational burden.

Placing Amazon CloudFront in front of the ALB provides edge termination of TLS and a global network of edge locations that shorten round-trip times for viewers. Creating a cache behavior for /static/* with an optimized cache policy and compression lets CloudFront cache and compress static files, greatly reducing origin traffic. Configuring a second behavior for /api/* that uses the CachingDisabled managed policy (TTL 0) and forwards all headers prevents CloudFront from caching personalized API responses. Enabling Origin Shield adds an extra regional cache layer that further consolidates requests, improving cache hit ratio and offloading the ALB. Global Accelerator accelerates TCP handshakes but cannot cache content, S3 Transfer Acceleration requires rewriting URLs, and multi-region replication with Route 53 adds significant complexity and does not offload static traffic from a single origin.

Systems Manager is accessible from a VPC only through interface VPC endpoints (SSM, SSMMessages, and EC2Messages). Enabling private DNS on these endpoints ensures that the standard public service names resolve to the endpoints' private IP addresses, so application code does not need to change.

Amazon S3 can be reached over a gateway VPC endpoint, which is free of hourly and data-processing charges and keeps traffic on the AWS backbone without requiring NAT. Using the gateway endpoint for S3 and interface endpoints for Systems Manager removes the need for NAT gateways, satisfies the no-internet requirement, and keeps recurring costs lower than an all-interface-endpoint or NAT-based design.

The other choices fail because:

• Gateway endpoints exist only for S3 and DynamoDB, so they cannot be used for Systems Manager.
• Creating a user-managed endpoint service for S3 or Systems Manager is not supported and adds needless complexity.
• Retaining NAT gateways still violates the security mandate and continues to incur hourly and data-processing fees.