CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
AWS Certified Solutions Architect - Professional (SAP-C02)
AWS Certified Solutions Architect - Professional (SAP-C02)

Practice Test #2

Simulate the real exam experience with 75 questions and a 180-minute time limit. Practice with AI-verified answers and detailed explanations.

75Questions180Minutes750/1000Passing Score
Browse Practice Questions

AI-Powered

Triple AI-Verified Answers & Explanations

Every answer is cross-verified by 3 leading AI models to ensure maximum accuracy. Get detailed per-option explanations and in-depth question analysis.

GPT Pro
Claude Opus
Gemini Pro
Per-option explanations
In-depth question analysis
3-model consensus accuracy

Practice Questions

1
Question 1

An ad-tech startup is building a metrics ingestion API with Amazon API Gateway and AWS Lambda. Across 12 Lambda functions written in Python 3.11, the team must reuse five internal libraries and custom classes maintained by a central platform team (about 15 MB when compressed). The security team requires production deployments to pull artifacts only from an approved registry; Amazon ECR is approved, but build jobs are not allowed to upload artifacts to S3 in the production account. A solutions architect must simplify deployments for all functions and maximize code reuse with minimal packaging complexity. Which approach meets these requirements?

Incorrect. It violates the security requirement because artifacts would be stored in S3, which is not the approved registry. Also, Lambda layers are ZIP archives, not created from a Docker image stored in S3. While attaching a layer to multiple ZIP-based functions is a common reuse pattern, it conflicts with the stated production constraint and misstates how layers are built and published.

Incorrect. Although ECR is the approved registry, Lambda layers are not created directly from an ECR container image. Layers are published as ZIP archives (uploaded to Lambda), and typical deployment workflows often involve S3 as a staging location. The option’s premise (layer-from-ECR-image) is not a supported Lambda feature, making it an invalid approach despite sounding governance-friendly.

Incorrect. ECS/Fargate runs long-lived containers, but Lambda cannot “reference a running container” as a Lambda layer. Layers are static dependency bundles mounted into the Lambda execution environment at init time. Using ECS would also add unnecessary operational overhead (service management, scaling, networking) and does not solve the packaging/reuse requirement for Lambda runtimes.

Correct. Build one container image per Lambda function, inheriting from a standardized base image that contains the shared internal libraries. Push images to ECR so production deployments pull only from the approved registry, avoiding S3 artifact uploads in the production account. This maximizes reuse (shared base image), reduces packaging complexity across 12 functions, and leverages Lambda’s native container image deployment model.

Question Analysis

Core Concept: This question tests AWS Lambda deployment packaging choices (ZIP vs container images), code reuse strategies (layers vs shared base images), and supply-chain controls (approved artifact registries such as Amazon ECR). It also implicitly tests Lambda limits and operational simplicity across multiple functions. Why the Answer is Correct: Option D best satisfies all constraints: the security team requires production deployments to pull artifacts only from an approved registry (ECR is approved), and build jobs cannot upload artifacts to S3 in the production account. Lambda container image support allows each function’s deployment package to be an OCI image stored in ECR, eliminating the need to place ZIPs or layer artifacts into S3 in the production account. Code reuse is achieved by standardizing on a common base image that contains the 15 MB compressed internal libraries and shared classes; each function image then adds only its handler code. This approach minimizes packaging complexity for 12 functions because the shared dependencies are managed once in the base image and inherited consistently. Key AWS Features: - AWS Lambda container image support (up to 10 GB image size) with images stored in Amazon ECR. - Docker multi-stage builds and a shared base image pattern to maximize reuse and reduce duplication. - ECR repository policies, image scanning, immutable tags, and lifecycle policies to meet governance and security requirements. - CI/CD can build and push images to ECR, and deployments update the Lambda function image URI/digest. Common Misconceptions: A and B may look attractive because Lambda layers are the classic reuse mechanism. However, Lambda layers are not created “from a Docker image in ECR” in the way described; layers are published as ZIP archives (typically uploaded to Lambda, often sourced from S3 during deployment tooling). Additionally, A violates the “approved registry” requirement by using S3 as the artifact store, and B incorrectly assumes ECR can directly back a layer. C is incorrect because Lambda cannot reference a running ECS/Fargate container as a layer; layers are static artifacts, not network-attached runtime dependency services. Exam Tips: When you see “approved registry = ECR” and restrictions on S3 artifact uploads, strongly consider Lambda container images. Use layers for ZIP-based functions, but for strict registry-based supply chain controls and simplified dependency reuse, a shared base image in ECR is often the cleanest pattern. Also remember: Lambda layers are ZIP-based, while Lambda container images are pulled from ECR.

2
Question 2
(Select 3)

A travel-tech company operates a partner webhook ingestion API on Amazon API Gateway with a Regional endpoint and an AWS Lambda backend that calls a third-party risk-scoring REST API using an API key stored in AWS Secrets Manager encrypted with a customer managed key in AWS Key Management Service (AWS KMS), persists and reads records from an Amazon DynamoDB global table, and is currently deployed only in us-east-1; the company must change the API components so the workload runs active-active across us-east-1, eu-west-1, and ap-southeast-2 with the least operational overhead—Which combination of changes will meet these requirements? (Choose three.)

Correct. API Gateway Regional endpoints are deployed per Region, so active-active requires separate APIs in us-east-1, eu-west-1, and ap-southeast-2. Route 53 with a custom domain can map to each Regional API endpoint and provide global routing. A multivalue answer policy can return multiple healthy endpoints and supports health checks, helping achieve active-active with low operational overhead.

Correct. The secret is encrypted with a customer managed KMS key; to decrypt in multiple Regions with minimal overhead and consistent key management, use a KMS multi-Region customer managed key and create replica keys in each target Region. Note that you cannot convert an existing single-Region CMK into multi-Region; you create a new multi-Region key and then replicate it.

Correct. Secrets Manager supports replicating a secret to other Regions, keeping the value synchronized automatically. Each replica can be encrypted with a KMS key in that Region; pairing this with a KMS multi-Region key (and its regional replicas) is a clean, low-ops design. This avoids manual copying and reduces the risk of secret drift across Regions.

Incorrect. You cannot convert an existing KMS key into a multi-Region key. Also, AWS managed keys are not multi-Region keys you can replicate across Regions in the way required here, and you cannot “reuse” an AWS managed key across Regions. The correct approach is to create a new multi-Region customer managed key and replicate it.

Incorrect. Manually creating separate secrets and copying values increases operational overhead and introduces drift risk (values can diverge across Regions). It also complicates rotation and auditing. The requirement explicitly asks for least operational overhead, which is best met by Secrets Manager replication rather than manual duplication.

Incorrect. While you do need to deploy Lambda and API Gateway in each Region for active-active, the option claims there is a “multi-Region option” for the existing API to attach each Region’s Lambda as the backend. API Gateway does not provide a single multi-Region API deployment that fans out to regional Lambdas; you deploy separate regional APIs and use DNS/global routing to distribute traffic.

Question Analysis

Core Concept: This question tests designing an active-active, multi-Region API on API Gateway + Lambda, and handling multi-Region dependencies (Secrets Manager and KMS) with minimal operational overhead. It also implicitly checks understanding of what is and is not “multi-Region” for API Gateway and KMS. Why the Answer is Correct: To run active-active in us-east-1, eu-west-1, and ap-southeast-2, you must deploy the Regional API Gateway and Lambda in each Region and provide a global entry point that routes clients to healthy endpoints. Option A accomplishes this using a custom domain in Route 53 mapped to each Regional API endpoint and a routing policy (multivalue) that can return multiple healthy endpoints. Because the Lambda function reads an API key from Secrets Manager encrypted with a customer managed KMS key, you must ensure the secret is available in each Region and can be decrypted locally. Secrets Manager supports secret replication across Regions, but each replica uses a KMS key in that Region. The lowest-overhead approach is to use a KMS multi-Region customer managed key (Option B) with replicas in each Region, then replicate the secret and select the appropriate KMS key per replica (Option C). This avoids manual secret copying and simplifies key management consistency. Key AWS Features: - API Gateway Regional endpoints are Region-scoped; multi-Region requires separate deployments. - Route 53 custom domain + health checks + multivalue (or other policies like latency/failover) provides global routing. - AWS KMS multi-Region keys allow consistent key material replicated to other Regions (still separate key ARNs per Region). - Secrets Manager cross-Region replication keeps secret value synchronized and supports per-Region KMS encryption. Common Misconceptions: - Assuming API Gateway has a “multi-Region option” to attach multiple Lambda backends (it does not; deployments are per Region). - Thinking you can “convert” an existing single-Region CMK into a multi-Region key (you must create a new multi-Region key). - Manually copying secrets seems simple but increases operational overhead and drift risk. Exam Tips: For active-active multi-Region, look for: (1) deploy compute/API per Region, (2) global DNS routing with health checks, (3) replicate state/secrets/keys appropriately. Remember: KMS multi-Region keys must be created as multi-Region from the start, and Secrets Manager replication is the managed, low-ops method versus manual duplication.

3
Question 3

A media analytics startup needs to migrate its third-party thumbnail rendering engine to AWS; the vendor provides a supported Docker image from a public registry that can run in any number of containers, the company has 12 content categories (Kids, Sports, News, etc.) and wants each category to run its own isolated set of containers with a small custom configuration (category-specific environment variables and S3 prefix filters) so that each container processes only that category, peak load requires up to 50 simultaneous containers per category with jobs that last 3–5 minutes and do not need persistent storage, finance requires per-category cost allocation using tags on the running units, and the operations team needs the ability to scale resources cost-effectively purely based on the number of running containers with the least possible operational overhead; which solution meets these requirements?

EKS on EC2 fails the “least operational overhead” requirement because you must manage EC2 node groups, scaling, patching, and Kubernetes lifecycle. Also, the statement about using an EKS CLI “--tags” to tag a pod is misleading for cost allocation: Kubernetes pod labels are not AWS billing tags. Even if you tag underlying AWS resources, mapping per-pod costs is nontrivial and not aligned with the requirement for tagging running units per category.

EKS on Fargate reduces node management, but still carries Kubernetes operational overhead (cluster operations, add-ons, RBAC, networking policies, upgrades). More importantly, tagging a Kubernetes pod via AWS tag-resource is not a standard/clean mechanism for cost allocation; cost allocation relies on AWS resource tags on billable resources. EKS/Fargate cost attribution is typically at namespace/label via Kubecost or CUR analysis, not simple per-pod AWS tags.

ECS on EC2 supports task tagging with --tags, but it does not meet the requirement to “scale resources cost-effectively purely based on the number of running containers with the least possible operational overhead.” You would need to manage EC2 capacity (Auto Scaling groups, capacity providers, bin packing, scaling policies) to handle bursts up to 600 concurrent containers (12x50). That adds operational burden and risks capacity shortfalls.

ECS on Fargate is the best fit: it runs the vendor Docker image as an ECS task with no server management, scales simply by launching tasks (or scaling ECS services), and supports per-category configuration via task definition variants or run-task overrides (environment variables/S3 prefix filters). Using enableECSManagedTags and --tags enables consistent tagging of tasks for per-category cost allocation in AWS billing/Cost Explorer with minimal operational overhead.

Question Analysis

Core Concept: This question tests choosing the lowest-ops container orchestration approach for short-lived, bursty workloads while meeting isolation and cost allocation requirements. The key services are Amazon ECS with AWS Fargate (serverless containers) and AWS tagging/Cost Allocation Tags. Why the Answer is Correct: Option D (ECS on Fargate + run-task + task tags + ECS managed tags) best matches all constraints: the vendor provides a Docker image (easy fit for ECS tasks), jobs are ephemeral (3–5 minutes) and stateless (no persistent storage), and peak burst is high (up to 50 concurrent containers per category across 12 categories). Fargate removes the need to provision/scale EC2 nodes and lets operations scale purely by launching more tasks. Per-category isolation is achieved by running separate ECS services or task definitions per category (or passing category-specific environment variables/command overrides and S3 prefix filters at run time). Finance’s per-category cost allocation is addressed by tagging each task with a category tag; ECS supports propagating and managing tags (enableECSManagedTags) and passing tags at run-task, which can be activated for AWS Cost Explorer and detailed billing. Key AWS Features: - AWS Fargate: serverless compute for containers; no cluster capacity management; scales by task count. - ECS run-task / services: straightforward launching of many short-lived tasks; supports overrides for environment variables. - Resource tagging: ECS task tags (and managed tags) for cost allocation; align with AWS Billing Cost Allocation Tags. - Isolation patterns: separate ECS services per category, separate task definitions, or distinct IAM roles/task roles and security groups if needed. Common Misconceptions: EKS can run on Fargate too, but it introduces Kubernetes operational overhead (cluster add-ons, RBAC, networking, upgrades) that conflicts with “least possible operational overhead.” Also, tagging “pods” is not the same as AWS resource tags used for billing allocation; Kubernetes labels/annotations do not automatically become AWS cost allocation tags. Exam Tips: When you see “short-lived containers,” “no persistent storage,” “burst scaling,” and “least ops,” default to ECS on Fargate unless there’s a strong Kubernetes requirement. For cost allocation, look for AWS resource tags on billable resources (tasks/services) rather than in-cluster metadata (pod labels).

4
Question 4

A healthcare analytics firm operates a HIPAA-compliant internal web application in AWS eu-central-1; the firm has a 1 Gbps AWS Direct Connect private VIF from its Frankfurt data center to a VPC where the application runs on Amazon EC2 instances across three Availability Zones behind an internal Application Load Balancer (ALB); staff access the app from the on-premises network over HTTPS, with TLS terminated at the ALB, and the ALB uses multiple target groups with path-based routing for /api, /images, and /admin. The network team is deploying an on-premises next-generation firewall that only permits outbound traffic to an allow list of destination IP addresses, and the firm must keep TLS termination and routing on the ALB without changing the application. Which solution enables continued access from on premises while meeting the allow list requirement with static IP addresses?

Incorrect. Application Load Balancers do not support assigning Elastic IP addresses or otherwise guaranteeing static IPs. ALB nodes scale and their underlying IP addresses can change over time. For allow-listing by destination IP, you need a service that supports static IPs (typically NLB with EIPs) or another fixed egress/ingress mechanism. Therefore, you cannot meet the firewall allow list requirement by “reconfiguring” the ALB.

Correct. An NLB can be provisioned with one Elastic IP per Availability Zone, providing stable destination IPs that the on-prem firewall can allow list. By using an ALB-type target group, the NLB forwards connections to the existing internal ALB, allowing the ALB to continue terminating TLS and performing path-based routing across multiple target groups. This satisfies both constraints: static IPs and unchanged ALB L7 behavior.

Incorrect. While an NLB can provide static IPs, it operates at Layer 4 and cannot perform HTTP path-based routing (e.g., /api, /images, /admin). Migrating ALB target groups directly to an NLB would remove L7 routing and TLS termination behavior as described. To keep routing and TLS termination on the ALB, the ALB must remain in the data path.

Incorrect. Gateway Load Balancer is designed to deploy and scale third-party virtual appliances (firewalls/IDS/IPS) using GENEVE tunneling and is not intended as a client-facing load balancer for web applications. It does not provide the required pattern of “clients connect to GWLB, GWLB targets ALB for HTTPS and path routing.” Using GWLB here is an architectural mismatch and would not meet the stated requirements.

Question Analysis

Core Concept: This question tests how to provide static, allow-listable IP addresses for clients while preserving Application Load Balancer (ALB) Layer 7 features (TLS termination and path-based routing). ALBs do not support fixed IPs; Network Load Balancers (NLBs) can use static IPs via Elastic IPs (EIPs). Why the Answer is Correct: Placing an NLB in front of the existing internal ALB allows on-premises clients to connect to stable EIP addresses (one per AZ) that the firewall can allow list. The NLB forwards traffic to the ALB (using an ALB-type target group), and the ALB continues to terminate TLS and perform path-based routing to /api, /images, and /admin without any application changes. This meets the requirement to keep TLS termination and routing on the ALB while satisfying the on-prem firewall’s destination IP allow list constraint. Key AWS Features: - NLB supports static IP addresses by associating EIPs per Availability Zone, which is ideal for strict firewall allow lists. - NLB can target an ALB using an ALB-type target group, enabling L4 pass-through to an L7 load balancer. - ALB retains HTTPS listener, certificate management (ACM), and path-based routing across multiple target groups. - Works with Direct Connect private VIF because traffic remains private to the VPC; clients simply resolve/connect to the NLB endpoint. Common Misconceptions: A is tempting because it suggests “assigning EIPs to an ALB,” but ALBs do not support EIPs or static IPs; their IPs can change. C is tempting because NLB has static IPs, but NLB is Layer 4 and cannot do path-based routing; migrating target groups would break the routing requirement. D misuses Gateway Load Balancer, which is for inserting virtual appliances via GENEVE, not for fronting web apps or providing L7 routing. Exam Tips: When you see “static IPs required” plus “must keep ALB features,” think “NLB in front of ALB.” Remember: ALB = L7 (host/path routing, TLS termination), NLB = L4 (static IP/EIP, high performance). GWLB is for firewall/appliance insertion, not client-facing web access.

5
Question 5

A digital ticketing company is modernizing its checkout application that currently runs a monolithic, load-balanced Amazon EC2 fleet serving the static web frontend, checkout/database APIs, and payment orchestration logic; the company wants a fully decoupled, serverless-first architecture that can process an average of 10,000 checkouts per hour with bursts up to 30,000 within 10 minutes, retain any failed checkout events for at least 7 days for later replay, independently scale each component, and minimize operational costs by eliminating server management. Which solution will meet these requirements?

S3 + API Gateway + SQS are aligned, but ECS is not “serverless-first” in the exam sense because you still manage task definitions, scaling, capacity (Fargate would be closer), and operational overhead. Also, “SQS long polling to retain failed checkouts” is incorrect: long polling reduces empty receives; it does not provide failure retention. Proper failure handling is via DLQ and retention/redrive policies.

Elastic Beanstalk introduces server/instance management (even if simplified), conflicting with eliminating server management. Amazon MQ is typically chosen for JMS/AMQP compatibility and is not the simplest low-ops choice for high-throughput burst buffering compared to SQS. Storing failed events in S3 Glacier Deep Archive meets retention but is poor for “later replay” due to retrieval delays and operational complexity versus SQS DLQ redrive.

Meets all requirements: S3 static hosting removes servers for the frontend; API Gateway provides a managed API layer; SQS Standard absorbs bursty checkout events and decouples ingestion from processing; Lambda scales automatically and independently for payment orchestration. An SQS DLQ with retention set to at least 7 days preserves failed events and supports later replay via redrive back to the main queue.

Lightsail and EKS are not serverless-first and require server/cluster management, which violates the cost/ops requirement. SES is not an order queueing service and does not provide the semantics needed for reliable event buffering and replay. OpenSearch is not an appropriate mechanism for retaining failed checkout events for replay; it’s a search/analytics engine, not a durable failure queue with redrive.

Question Analysis

Core Concept: This question tests serverless-first decoupled design using managed event buffering (SQS), serverless compute (Lambda), and failure handling with durable retention (dead-letter queues) to absorb bursts and enable replay. Why the Answer is Correct: Option C delivers a fully decoupled architecture: S3 hosts the static frontend with no servers; API Gateway provides a managed, scalable API layer for the checkout/database APIs; SQS Standard buffers checkout events to decouple request ingestion from payment processing and to absorb burst traffic (30,000 in 10 minutes). Lambda scales automatically with SQS event source mapping, allowing independent scaling of payment orchestration logic without managing instances/containers. Failed messages are routed to an SQS dead-letter queue (DLQ) with message retention configured up to 14 days, satisfying the “retain failed checkout events for at least 7 days” requirement and enabling later replay by redriving messages from the DLQ back to the source queue. Key AWS Features: - Amazon SQS Standard: virtually unlimited throughput, at-least-once delivery, and buffering to smooth bursts. - SQS retention: configurable 1 minute to 14 days; set DLQ retention to >= 7 days. - Lambda + SQS integration: automatic scaling via polling and batching; supports partial batch response to reduce retries for successful items. - API Gateway: managed scaling, throttling, auth, and integration with Lambda or other backends. - S3 static website hosting: low-cost, highly durable static content delivery (often paired with CloudFront, though not required by the prompt). Common Misconceptions: A common trap is assuming “queue + containers” is still serverless. ECS removes some ops burden but still requires cluster/task sizing, scaling policies, and patching responsibility compared to Lambda. Another misconception is using archival storage (e.g., Glacier Deep Archive) for operational replay; it’s not designed for quick redrive workflows. Exam Tips: When you see “serverless-first,” “bursty traffic,” “decouple components,” and “retain failed events for replay,” think: API Gateway/S3 for front door, SQS for buffering, Lambda for compute, and DLQ with retention/redrive for failures. Also remember SQS max retention is 14 days—so “7 days” strongly points to SQS DLQ as a clean fit.

Want to practice all questions on the go?

Download Cloud Pass — includes practice tests, progress tracking & more.

6
Question 6

A video annotation company is re-platforming a Docker-based tagging service to AWS that requires a shared POSIX-compliant NFSv4 mount at /data concurrently accessible by up to 200 tasks across two Availability Zones, must scale on demand, encrypt data at rest, control access with IAM, and must not require provisioning or managing any servers or cluster infrastructure; which solution meets these requirements?

Correct. ECS on Fargate satisfies the requirement to avoid managing servers/cluster capacity. Amazon EFS provides a managed, elastic, POSIX-compliant NFSv4.1 file system that supports concurrent access from many tasks across multiple AZs. Using an EFS Access Point helps enforce a consistent /data directory and POSIX permissions. EFS supports encryption at rest (KMS), in-transit encryption (TLS), and IAM authorization for access control.

Incorrect. Amazon FSx for Lustre is a high-performance parallel file system, not a POSIX-compliant NFSv4 shared file system like Amazon EFS. More importantly for this scenario, ECS tasks on AWS Fargate support Amazon EFS integration for persistent shared storage, not FSx for Lustre mounts in the task definition. The requirement explicitly calls for a shared NFSv4 mount across tasks in multiple AZs with IAM-based access control and no server management, which aligns directly with EFS rather than FSx for Lustre. Even though FSx for Lustre is managed and POSIX-compliant, it does not satisfy the specific NFSv4 and Fargate integration requirements in this question.

Incorrect. While EFS is the right shared storage, using ECS with the EC2 launch type requires provisioning and managing EC2 container instances and an Auto Scaling group (capacity management, patching, AMIs, scaling policies). That violates the explicit requirement: “must not require provisioning or managing any servers or cluster infrastructure.” Fargate is the intended compute model when the question emphasizes no server management.

Incorrect. EBS Multi-Attach is block storage, not a shared NFS file system, and it has significant limitations (only certain volume types, same AZ attachment constraints, and application-level coordination requirements). It does not provide an NFSv4 POSIX shared mount across two Availability Zones. Additionally, the EC2 launch type with an ASG again violates the “no servers/cluster infrastructure management” requirement.

Question Analysis

Core Concept: This question tests choosing the correct serverless container compute plus shared POSIX file storage for many concurrent tasks across multiple Availability Zones. The key services are Amazon ECS on AWS Fargate (no server/cluster management) and Amazon EFS (managed NFSv4, multi-AZ, elastic). Why the Answer is Correct: The workload requires a shared POSIX-compliant NFSv4 mount at /data that can be concurrently accessed by up to 200 tasks across two AZs, scales on demand, encrypts at rest, and controls access with IAM—without provisioning or managing servers. Amazon EFS is a fully managed, elastic NFS file system that supports NFSv4.1, provides POSIX semantics, and is designed for concurrent access from many clients across multiple AZs. ECS Fargate removes the need to manage EC2 instances or an ECS cluster’s underlying capacity. EFS can be mounted directly from Fargate tasks via task definition volume configuration, meeting the “no servers” requirement. Key AWS Features: - EFS multi-AZ availability: EFS stores data redundantly across multiple AZs in a Region, enabling concurrent access from tasks in different AZs. - Elastic scaling: EFS automatically scales throughput/storage with demand (and can use throughput modes as needed). - Encryption: EFS supports encryption at rest (KMS) and in transit (TLS). - IAM access control: EFS supports IAM authorization for NFS clients (when using EFS mount helper/IAM integration) and EFS Access Points to enforce a specific POSIX identity and root directory, which is ideal for mounting at /data with consistent permissions. - Fargate integration: ECS task definitions can specify EFS volumes and mount points without managing instances. Common Misconceptions: FSx for Lustre is also a shared POSIX file system, but it is optimized for HPC and typically integrated with S3; it’s not the standard choice for NFSv4 shared storage for containers and does not align as cleanly with the IAM/EFS access point pattern commonly tested. EC2 launch type options may appear viable because EFS works well there, but they violate the requirement to avoid provisioning/managing servers. EBS Multi-Attach is block storage with strict constraints and is not an NFS shared file system. Exam Tips: When you see “shared POSIX, NFSv4, multi-AZ, many concurrent containers, serverless/no infrastructure management,” map it to “ECS Fargate + EFS (Access Points + encryption + IAM/TLS).” Reserve FSx for Lustre for HPC/high-performance scratch and EBS for single-instance (or limited multi-attach) block storage, not shared NFS mounts.

7
Question 7
(Select 3)

A research lab runs an MPI-based, tightly coupled seismic inversion workload on an AWS HPC cluster that writes millions of shared files to an Amazon EFS file system; the job met performance objectives with 120 EC2 compute nodes, but when the cluster scaled to 1,200 nodes the overall throughput and time-to-solution degraded significantly due to I/O and inter-node communication bottlenecks. Which combination of design choices should a solutions architect implement to maximize the HPC cluster’s performance? (Choose three.)

Correct. Tightly coupled MPI workloads are highly sensitive to latency and jitter. Keeping the cluster in a single Availability Zone avoids cross-AZ network hops and variability, improving determinism for collectives and synchronization. This is a common HPC best practice on AWS, often combined with cluster placement strategies to maximize bandwidth and minimize latency between nodes.

Incorrect. Attaching additional ENIs is not a typical or reliable way to improve MPI performance, and “multiples of four” is not an HPC scaling rule. MPI bottlenecks are usually about latency/message rate and network fabric behavior, where EFA is the purpose-built solution. More ENIs can add complexity and may not increase effective bandwidth for MPI traffic.

Correct. EFA provides low-latency, high-throughput networking with OS-bypass capabilities for supported instance types, significantly improving MPI scaling and inter-node communication. For large node counts, EFA is a primary AWS recommendation for tightly coupled HPC workloads. It directly targets the inter-node communication bottleneck described in the scenario.

Incorrect. Distributing a tightly coupled MPI cluster across multiple AZs generally harms performance due to increased latency, jitter, and reduced effective bandwidth between nodes. While multi-AZ improves resiliency, the question prioritizes maximizing performance and time-to-solution. For HPC, resiliency is often handled via checkpointing rather than cross-AZ placement.

Incorrect. A single instance hosting a RAID 0 EBS set as a shared store becomes a massive bottleneck and single point of failure at 1,200 nodes. It cannot provide the parallel metadata and throughput characteristics required for millions of shared files. This design also undermines scalability and availability compared to purpose-built parallel file systems.

Correct. Amazon FSx for Lustre (scratch) is designed for HPC and supports high concurrent I/O and metadata operations, making it far better suited than EFS for millions of shared files at large scale. It can deliver high aggregate throughput across many clients and integrates with Amazon S3 for durable datasets, using Lustre as high-performance scratch.

Question Analysis

Core Concept: This question tests AWS HPC design for tightly coupled MPI workloads at scale, focusing on low-latency networking and high-concurrency shared file system performance. The key services/concepts are placement/latency (single AZ), Elastic Fabric Adapter (EFA) for MPI, and using a parallel file system (Amazon FSx for Lustre) instead of Amazon EFS for extreme metadata and small-file I/O. Why the Answer is Correct: At 1,200 nodes, both inter-node communication and shared storage become dominant bottlenecks. (A) keeps all nodes in one Availability Zone, avoiding cross-AZ latency, jitter, and bandwidth constraints that are especially harmful to tightly coupled MPI collectives. (C) enables EFA on supported instance types, providing OS-bypass (via libfabric) and very low latency/high message rate networking that scales MPI performance far better than standard ENA networking. (F) replaces EFS with FSx for Lustre (scratch), a high-performance parallel file system designed for HPC with high aggregate throughput and metadata performance, well-suited to “millions of shared files” and high concurrent access. Key AWS Features: Single-AZ cluster placement reduces network variability and enables best use of cluster placement groups (commonly paired with HPC). EFA integrates with MPI stacks to improve latency and throughput for tightly coupled jobs. FSx for Lustre provides scalable throughput/IOPS and supports integration with Amazon S3 for durable data repositories (import/export), while using the Lustre file system as a fast scratch/work space. Common Misconceptions: Spreading across AZs (D) improves resiliency but typically degrades tightly coupled HPC performance due to added latency and reduced determinism. Adding ENIs (B) does not meaningfully improve MPI latency and is not a standard method to scale HPC interconnect performance; EFA is the purpose-built solution. Using a single instance with RAID0 EBS as “shared storage” (E) creates a severe single-node bottleneck and single point of failure and cannot serve 1,200 nodes with high metadata concurrency. Exam Tips: For tightly coupled MPI: prioritize low latency, low jitter, and high message rate (single AZ + EFA). For massive shared-file concurrency: choose a parallel file system (FSx for Lustre) over general-purpose NFS (EFS). Multi-AZ is usually a red flag for tightly coupled HPC performance questions unless the workload is loosely coupled or explicitly requires HA over performance.

8
Question 8

A pharmaceutical research firm must spin up short‑lived validation sandboxes for each tagged build; each sandbox is a single Amazon EC2 instance managed by an Auto Scaling group and must reach an on‑premises license server over TCP 8443 to report results. The firm needs to create and delete up to 30 sandboxes per business day, each lasting fewer than 3 hours, with no manual intervention and consistent connectivity to the on‑prem network (172.16.0.0/16). The company already operates an AWS Transit Gateway (tgw-0abc123def4567890) with a Site‑to‑Site VPN to its data center and wants the solution with the least operational overhead. Which approach best meets these requirements?

Creating a new VPC and TGW attachment per sandbox adds significant operational overhead and increases the chance of transient failures (attachment creation, TGW route propagation/updates, quota limits). TGW attachments are relatively heavyweight compared to launching an EC2 instance. For 30 sandboxes/day, this approach is slow, complex, and harder to troubleshoot, even if automated with StackSets.

A shared VPC with a single TGW attachment and prebuilt routing provides consistent, always-on connectivity to 172.16.0.0/16. Each sandbox becomes only an ASG/EC2 lifecycle event, which is fast and easy to automate with CloudFormation. This minimizes moving parts (no repeated TGW attachment churn), aligns with least operational overhead, and meets the requirement for frequent create/delete with no manual intervention.

Using AWS Organizations and creating a new account per sandbox is operationally excessive and slow (account vending, guardrails, SCPs, baseline setup). It also introduces additional TGW attachment and routing work per account/VPC. This pattern is appropriate for strong isolation boundaries for long-lived environments, not for <3-hour sandboxes created up to 30 times per day.

EKS in a new VPC plus TGW attachment is a major increase in complexity and operational overhead (cluster lifecycle, node groups/Fargate, networking, upgrades). The workload is explicitly a single EC2 instance managed by an Auto Scaling group, so containerization and Kubernetes orchestration are unnecessary. This option modernizes the stack without addressing the core requirement of minimal ops and rapid ephemeral provisioning.

Question Analysis

Core Concept: This question tests designing ephemeral environments with consistent hybrid connectivity while minimizing operational overhead. Key services/concepts are AWS Transit Gateway (TGW) attachments and routing, VPC sharing/reuse, and infrastructure as code (CloudFormation) for repeatable sandbox provisioning. Why the Answer is Correct: Option B is the lowest-ops design that still guarantees reliable connectivity to the on-premises network (172.16.0.0/16) over the existing TGW + Site-to-Site VPN. By using a single shared VPC with one TGW VPC attachment and stable route tables, the network plumbing is created once and reused. Each sandbox is just an Auto Scaling group/EC2 instance launched into preconfigured subnets and security groups, which is fast to create/delete up to 30 times per day and avoids repeated TGW attachment lifecycle operations (which add complexity, time, and potential failure points). Key AWS Features / Configurations: - TGW VPC attachment from the shared sandbox VPC to tgw-0abc123def4567890. - VPC route tables: add a route for 172.16.0.0/16 pointing to the TGW attachment; ensure TGW route tables have return routes to 10.20.0.0/16 (or the chosen VPC CIDR) via that attachment. - Security groups/NACLs: allow outbound TCP 8443 to 172.16.0.0/16 and allow return traffic (stateful SGs simplify this). On-prem firewall must allow the VPC CIDR to reach the license server on 8443. - CloudFormation to create/delete the ASG/Launch Template/Instance Profile per tagged build; use tags for lifecycle automation. Common Misconceptions: It can seem “cleaner” to create a brand-new VPC and TGW attachment per sandbox (Option A), but that multiplies networking resources and operational risk for short-lived workloads. Creating a new account per sandbox (Option C) is far too heavy for <3-hour environments. EKS (Option D) modernizes unnecessarily and increases operational burden. Exam Tips: When you see frequent short-lived environments plus hybrid connectivity, prefer reusing stable network constructs (VPC/TGW attachment/routes) and only cycling compute. TGW attachments are not intended to be created/destroyed dozens of times daily for ephemeral sandboxes; keep the network steady and automate the workload layer with CloudFormation and Auto Scaling.

9
Question 9

A digital ticketing company runs microservices on Amazon EKS with Fargate profiles in eu-west-1, persists about 600 write transactions per second to an Amazon Aurora PostgreSQL cluster, and must fail over to a different AWS Region with an RPO ≤ 1 second and an RTO ≤ 15 minutes while minimizing ongoing operational overhead; which approach best meets these requirements?

Aurora Global Database is the native, managed solution for cross-Region DR with Aurora. It provides storage-level replication to a secondary Region with typically sub-second lag, aligning with RPO ≤ 1 second. Managed promotion/failover of the secondary cluster can meet an RTO of ≤ 15 minutes, and operational overhead is low because Aurora manages replication and the global topology.

AWS DMS can perform ongoing replication, but it adds operational overhead (replication instances, task management, monitoring, schema evolution handling) and may not reliably meet an RPO ≤ 1 second under sustained 600 writes/sec. DMS is primarily a migration/replication tool, not the preferred mechanism for stringent Aurora DR objectives compared to Aurora Global Database.

AWS DataSync is designed for file/object transfer (NFS/SMB/EFS/FSx/S3) and is not a database replication service. Copying database files to S3 and restoring during failure is effectively a backup/restore workflow, which will not achieve RPO ≤ 1 second and is unlikely to meet RTO ≤ 15 minutes due to restore time, consistency concerns, and operational complexity.

Automated snapshots every 5 minutes with cross-Region copy provide a backup strategy, not near-real-time DR. The best-case RPO is roughly the snapshot interval (minutes, not ≤ 1 second), and RTO includes snapshot copy lag, restore time, and application cutover—often exceeding 15 minutes. This option is suitable for less stringent DR requirements, not near-zero RPO.

Question Analysis

Core Concept: This question tests multi-Region disaster recovery for Amazon Aurora PostgreSQL with very low RPO (≤ 1 second) and moderate RTO (≤ 15 minutes), while minimizing operational overhead. The key service is Amazon Aurora Global Database, which provides managed, low-latency cross-Region replication and a designed failover mechanism. Why the Answer is Correct: Aurora Global Database is purpose-built for cross-Region DR with near-real-time replication (typically sub-second) from a primary Region to secondary Regions using dedicated storage-level replication. That aligns directly with the RPO ≤ 1 second requirement at ~600 writes/sec. For RTO, Aurora Global Database supports managed cross-Region failover/promote operations that can be executed quickly (often minutes), fitting within a 15-minute target. It also minimizes ongoing operational overhead because replication, monitoring, and the cross-Region topology are managed by Aurora rather than requiring custom replication pipelines. Key AWS Features: Aurora Global Database uses asynchronous replication at the storage layer to secondary clusters in other Regions, enabling low replication lag and reducing impact on the primary. You can create a secondary Aurora cluster in another Region and keep it continuously updated. During a disaster, you promote the secondary to read/write and redirect applications (typically via DNS such as Route 53 failover records, or application-level configuration). This is a standard DR pattern in the AWS Well-Architected Reliability pillar: design for failure, automate recovery, and use managed services. Common Misconceptions: AWS DMS can replicate data cross-Region, but it’s not designed to guarantee sub-second RPO under sustained write load and introduces operational complexity (tasks, instance sizing, monitoring lag, schema changes, failover runbooks). DataSync and snapshot-based approaches are backup/restore mechanisms, not continuous DR; they cannot meet a 1-second RPO and typically miss the 15-minute RTO once restore time and replay are considered. Exam Tips: When you see Aurora + cross-Region DR + very low RPO, think “Aurora Global Database.” Snapshot copy and file-based copy are for backup/archival, not near-zero RPO. DMS is for migrations and some replication use cases, but for stringent DR objectives with minimal ops, prefer native managed database DR features.

10
Question 10

A telematics startup operates 2,500 delivery drones across two metro regions. Each drone publishes JSON telemetry (GPS, temperature, vibration) every 100 ms with an average record size of 1.5 KB. The company needs an AWS solution to ingest this continuous stream and deliver events in near-real time (end-to-end under 3 seconds) to a database that does not require fixed schemas so attributes can evolve without migrations. Which solution will meet these requirements?

Kinesis Data Firehose to Redshift is a common analytics pipeline, but it conflicts with two requirements. Redshift is a schema-based data warehouse, so evolving attributes typically require schema changes. Firehose also buffers data before delivery (by size/time), which can introduce latency that may exceed a strict <3 second end-to-end target, especially under variable load.

Kinesis Data Streams provides low-latency ingestion at high throughput and is well-suited for continuous telemetry. A Lambda consumer can process records in near-real time and write to DynamoDB. DynamoDB is schema-less at the item level (attributes can vary per item and evolve over time) and can scale write throughput to handle tens of thousands of events per second with proper key design.

Amazon MSK can handle streaming, but streaming directly into Aurora MySQL is not a natural fit for high-rate telemetry without additional consumers/connectors and careful batching. Aurora MySQL is relational and schema-based, which contradicts the requirement for evolving attributes without migrations. Also, achieving consistent sub-3-second end-to-end latency into Aurora at this write rate can be challenging and costly.

Kinesis Data Firehose does not natively deliver to Amazon Keyspaces as a direct destination. Even if an intermediate step were added, Firehose buffering can add latency that risks missing the <3 second requirement. Keyspaces is schema-based in the Cassandra sense (tables/columns are defined), so while it is flexible, it is not “schema-less” in the same way as DynamoDB for evolving JSON attributes.

Question Analysis

Core Concept: This question tests selecting the right streaming ingestion service and a target database that supports flexible (schema-less) attributes with near-real-time delivery. It also implicitly tests understanding Kinesis delivery semantics (Streams vs Firehose), latency, and DynamoDB’s document-style item model. Why the Answer is Correct: With 2,500 drones publishing every 100 ms, the system ingests ~25,000 records/second. At 1.5 KB each, that is ~37.5 MB/s of payload. Amazon Kinesis Data Streams is designed for high-throughput, low-latency streaming ingestion (milliseconds to sub-second). A Lambda consumer (enhanced fan-out or standard polling) can process records continuously and write them to Amazon DynamoDB, which does not require a fixed schema: each item can have different attributes, and JSON-like nested attributes (Map/List) can evolve without migrations. This architecture can meet an end-to-end target under 3 seconds when configured with sufficient shards/throughput, appropriate batching, and DynamoDB capacity (on-demand or provisioned with auto scaling). Key AWS Features: Kinesis Data Streams provides ordered, durable stream storage with configurable retention and scaling via shards. Lambda event source mapping supports batch size and maximum batching window tuning; enhanced fan-out can reduce consumer latency and isolate throughput per consumer. DynamoDB supports flexible attributes, TTL (useful for expiring old telemetry), and partition key design to distribute writes (for example, partition by droneId with a sort key timestamp). Common Misconceptions: Firehose is often chosen for “streaming to a database,” but Firehose is optimized for delivery to S3/Redshift/OpenSearch/Splunk with buffering (size/time) that can add seconds to minutes of latency, and it does not natively deliver to DynamoDB or Keyspaces. Aurora MySQL and Redshift are schema-oriented relational/warehouse targets, conflicting with the “no fixed schema” requirement. Exam Tips: When you see “near-real time” with strict sub-seconds-to-few-seconds latency, prefer Kinesis Data Streams (or Kafka) over Firehose. When you see “schema can evolve without migrations,” think DynamoDB (or document databases). Always sanity-check throughput (records/sec and MB/sec) and ensure the chosen service supports the destination and latency requirements.

Success Stories(9)

S
s******Nov 24, 2025

Study period: 3 months

I used these practice questions and successfully passed my exam. Thanks for providing such well-organized question sets and clear explanations. Many of the questions felt very close to the real exam.

T
t**********Nov 13, 2025

Study period: 3 months

Just got certified last week! It was a tough exam, but I’m really thankful to cloud pass. the app questions helped me a lot in preparing for it.

효
효**Nov 12, 2025

Study period: 1 month

앱 이용 잘했습니다 ^^

P
p*******Nov 7, 2025

Study period: 2 months

These practice exams are help for me to pass the certification. A lot of questions are mimicked from here.

D
d***********Nov 7, 2025

Study period: 1 month

Thanks. I think I passed because of high quality contents here. I am thinking to take next aws exam here.

Other Practice Tests

Practice Test #1

75 Questions·180 min·Pass 750/1000

Practice Test #3

75 Questions·180 min·Pass 750/1000

Practice Test #4

75 Questions·180 min·Pass 750/1000

Practice Test #5

75 Questions·180 min·Pass 750/1000
← View All AWS Certified Solutions Architect - Professional (SAP-C02) Questions

Start Practicing Now

Download Cloud Pass and start practicing all AWS Certified Solutions Architect - Professional (SAP-C02) exam questions.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT Certification Practice App

Get it on Google PlayDownload on the App Store

Certifications

AWSGCPMicrosoftCiscoCompTIADatabricks

Legal

FAQPrivacy PolicyTerms of Service

Company

ContactDelete Account

© Copyright 2026 Cloud Pass, All rights reserved.

Want to practice all questions on the go?

Get the app

Download Cloud Pass — includes practice tests, progress tracking & more.