AWS Solutions Architect Resilient practice questions
7-day money-back guarantee — full refund within 7 days of purchase if you've completed under 20% of the questions. See pricing →
Certifications Tools Flashcards Career Paths Exam Guides Blog Pricing For Teams About

Language

✓ EnglishDeutschEspañolFrançaisPortuguês
Check readiness — free →

AWS Solutions Architect Design Resilient Architectures: 272 practice questions

AWS Solutions Architect 272 questions 12 shown free

12 of the 272 Design Resilient Architectures questions in the Certsqill AWS Solutions Architect bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS Solutions Architect? Take the free 5-min readiness check →

1. Amazon SNS: Which AWS service best supports this pattern?

Easy
A company wants to send order confirmation notifications to multiple downstream services simultaneously when an order is placed. Each downstream service must receive every notification. Which AWS service best supports this pattern?
  1. AWS Step Functions
    AWS Step Functions orchestrates multi-step workflows. It is not a messaging or notification service and does not fan out messages to independent subscribers.
  2. Amazon SQS
    Amazon SQS is a message queue where each message is consumed by one consumer. It does not natively fan out a single message to multiple independent consumers.
  3. Amazon SNS ✓
    Amazon SNS is a pub/sub service that fans out a single message to multiple subscribers simultaneously. Every subscriber receives every message published to the topic.
  4. Amazon Kinesis Data Streams
    Amazon Kinesis is designed for high-throughput streaming data, not for simple notification fan-out to a fixed set of downstream services.
The trap
Confusing SQS (one consumer per message) with SNS (all subscribers receive every message).

Amazon SNS implements the pub/sub pattern, delivering each published message to all subscribed endpoints simultaneously — ideal for fan-out notification scenarios.

2. Configure an Amazon SQS queue as the destination: Which design meets these requirements with the least operati

Medium
A company's video processing application receives upload events from Amazon S3. Processing each video takes up to 10 minutes. If the processing service is temporarily unavailable, events must be retained and retried automatically. Which design meets these requirements with the least operational overhead?
  1. Configure Amazon SNS to deliver the S3 event notifications directly to the processing service endpoint over HTTPS
    Incorrect. Amazon SNS delivers in real time and retries HTTP endpoints for a limited window (typically minutes). If the processing service is down longer than that window, messages are lost.
  2. Use Amazon Kinesis Data Streams to ingest the S3 upload events and have the processing service read them
    Incorrect. Amazon Kinesis Data Streams is built for high-throughput, ordered streaming analytics and adds unnecessary complexity compared to SQS for a simple retry-and-decoupling use case.
  3. Use Amazon EventBridge to capture the S3 events and invoke an AWS Lambda function that calls the service
    Incorrect. EventBridge with Lambda is bounded by the 15-minute Lambda timeout and has limited retry durability. For processing that may be unavailable for a while, SQS provides better durability and decoupling.
  4. Configure an Amazon SQS queue as the destination for the S3 event notifications and have the service poll it ✓
    Correct. Amazon SQS retains messages for up to 14 days and supports visibility timeouts and dead-letter queues, providing durable, automatic retry without any additional infrastructure to manage.
The trap
Choosing EventBridge for all event-driven patterns — SQS is the right tool when durable retry and offline consumer tolerance is required.

Amazon SQS provides durable message retention (up to 14 days), visibility timeout-based retry, and dead-letter queues — the standard pattern for decoupling producers and consumers with automatic retry.

3. AWS Lambda triggered by S3 event notifications: Which compute option is most appropriate?

Easy
A company wants to automatically resize images uploaded to Amazon S3. Each resize operation takes less than 30 seconds. The team wants to avoid managing servers. Which compute option is most appropriate?
  1. AWS Lambda triggered by S3 event notifications ✓
    AWS Lambda is serverless, event-driven, and supports execution durations up to 15 minutes. It triggers directly from S3 events and requires no server management.
  2. AWS Batch for processing image resize jobs
    AWS Batch is designed for large-scale batch computing jobs (HPC, data processing). It is over-engineered for simple sub-30-second image resize operations triggered by individual S3 uploads.
  3. Amazon ECS with Fargate running a container that polls S3
    ECS/Fargate is suited for long-running containerized workloads. For short, event-triggered tasks triggered by S3, Lambda is simpler and more cost-effective.
  4. Amazon EC2 instances in an Auto Scaling group polling S3
    EC2 instances require server management (patching, scaling configuration) and are more costly for short, infrequent tasks compared to Lambda's pay-per-invocation model.
The trap
Thinking ECS/Fargate means serverless — Fargate removes EC2 management but Lambda is the right choice for short, event-triggered functions.

AWS Lambda is purpose-built for short-lived, event-driven, serverless compute — triggered directly by S3 events with no server management required.

4. Amazon EventBridge with event rules that match: Which service provides content-based routing to multiple desti

Medium
A company processes orders from an e-commerce platform. Orders with a status of 'FRAUD_RISK' must be routed to a fraud review queue. Orders with a status of 'APPROVED' must be routed to a fulfillment queue. Orders with 'PAYMENT_FAILED' must trigger an email notification. Which service provides content-based routing to multiple destinations with the least development effort?
  1. Amazon SQS in a fan-out pattern where a consumer application reads each order and re-routes it by status
    Amazon SQS does not natively route messages based on content. Implementing content-based routing with SQS requires custom consumer logic to read and re-route messages.
  2. Amazon EventBridge with event rules that match on the order status field and route each to a different target ✓
    Amazon EventBridge supports content-based routing via event rules that match specific fields in the event payload and route to different targets (SQS, SNS, Lambda, etc.) based on those matches.
  3. Amazon SNS with message filtering policies on each subscription that match published message attribute key-value pairs
    Amazon SNS message filtering can route to different subscriptions based on attributes, but it requires publishing with explicit message attributes and is less flexible than EventBridge for complex content matching across multiple target types.
  4. AWS Step Functions with a Choice state that branches on the order status to reach each separate destination
    AWS Step Functions can branch on order status but requires a workflow definition for each order and cannot natively fan out to multiple external targets (SQS, email) without additional Lambda steps.
The trap
Choosing SNS for content-based routing — SNS filtering uses message attributes, not deep JSON content. EventBridge rules match event payload fields natively.

Amazon EventBridge rules match event content (specific field values) and route to multiple different target types — the native AWS solution for content-based routing without custom consumer code.

5. Amazon EKS with AWS Fargate as the compute provider: Which solution meets these requirements?

Medium
A company is migrating 15 microservices to AWS. Their DevOps team has extensive Kubernetes expertise and currently manages on-premises Kubernetes clusters. They want to minimize retraining effort while running containers on AWS without managing the underlying EC2 instances. Which solution meets these requirements?
  1. AWS Lambda with container image support
    Lambda container images are for serverless, short-lived functions. Lambda does not support Kubernetes orchestration and imposes strict timeout (15 min) and resource limits.
  2. Amazon ECS with AWS Fargate as the compute provider
    Amazon ECS uses AWS-proprietary task definitions and service concepts, not Kubernetes. This would require the team to retrain on ECS constructs, contradicting the requirement to minimize retraining.
  3. Amazon EKS with AWS Fargate as the compute provider ✓
    Amazon EKS is a managed Kubernetes service that preserves the team's existing Kubernetes skills (kubectl, Helm, manifests). Using Fargate as the compute provider eliminates EC2 instance management.
  4. Amazon ECS with EC2 launch type using Auto Scaling groups
    ECS with EC2 launch type requires managing EC2 instances. Additionally, ECS is not Kubernetes — the team would need to learn new ECS-specific tooling.
The trap
Choosing ECS/Fargate because 'Fargate removes server management' — Fargate removes EC2 management but ECS is not Kubernetes and would require retraining.

Amazon EKS is managed Kubernetes — it preserves the team's existing expertise. Fargate as the compute layer removes EC2 instance management, satisfying both requirements.

6. Publish events to an SNS topic subscribed to separate SQS: Which architecture best meets these requirements?

Medium
A company receives order events in bursts. Billing and analytics must each process every event independently, at their own pace, while temporary consumer failures must not lose events. Which architecture best meets these requirements?
  1. Deliver events through Amazon Data Firehose and let both applications replay them independently.
    Firehose is designed for buffered delivery to supported destinations, not as an application-managed replay log for independent consumers.
  2. Send events to one standard SQS queue, with billing and analytics using competing consumers.
    Competing consumers divide messages, so each event is processed by only one application rather than both.
  3. Publish events to an SNS topic subscribed to separate SQS queues for billing and analytics. ✓
    SNS delivers each event to both subscribed queues, allowing independent consumers to retry and process their copies.
  4. Publish events directly to separate SNS topics, with each application polling its topic.
    SNS topics are push-based notification endpoints and are not polled like SQS queues; durable independent buffering is missing.
The trap
Use one queue for competing workers; use separate queues behind a fanout publisher when each consumer needs its own copy.

SNS fanout to separate SQS queues gives each application its own durable processing path and retry pace.

7. Place jobs in an Amazon SQS Standard queue and run ECS: Which design best meets these requirements?

Medium
The image-processing workload receives unpredictable bursts of jobs and currently runs on manually maintained servers. Each job may be retried safely, processing capacity should scale independently from producers, and the team wants to avoid managing container hosts. Which design best meets these requirements?
  1. Publish jobs to one SQS queue and have separate processing services consume the queue so every service receives each job.
    Competing consumers divide messages; one shared queue does not broadcast every message to each service. Separate queues behind SNS fanout would be required for copies.
  2. Place jobs in an Amazon SQS Standard queue and run ECS services on Fargate as competing consumers, deleting messages after successful processing. ✓
    This decouples producers from workers, supports burst buffering and independent consumer scaling, and avoids EC2 host administration.
  3. Run the workers on an EC2 Auto Scaling group using target tracking based on total queue throughput.
    EC2 Auto Scaling can adjust capacity, but this retains host and container-management responsibilities the requirement seeks to eliminate.
  4. Use Amazon Data Firehose to buffer jobs and deliver them directly to the processing containers with minimal latency.
    Firehose is designed for buffered delivery to supported destinations, not for independently managed application consumers processing queued jobs.
The trap
For asynchronous Fargate workers, check both message-processing semantics and which IAM role performs ECS operations versus application calls.

SQS provides asynchronous buffering, while Fargate supplies managed container capacity for independently scalable workers.

8. Configure EC2 Auto Scaling target tracking: Which design best meets these requirements?

Medium
A company runs a stateless web tier on EC2 instances behind a load balancer. Request volume changes substantially throughout the day, and user sessions are stored outside the instances. The company must automatically maintain a suitable per-instance workload while keeping capacity between defined minimum and maximum bounds. Which design best meets these requirements?
  1. Configure target tracking on total request count, with the desired value equal to peak daily traffic and the same capacity bounds.
    A total metric can rise as instances are added, so it does not reliably represent workload per instance for target tracking.
  2. Keep a fixed instance count at the expected daily average and store sessions externally for failover.
    External session state supports replaceable instances, but a fixed count does not automatically respond to changing request volume.
  3. Use ElastiCache as the web tier and scale its nodes from the total request count, leaving the EC2 group fixed.
    ElastiCache can reduce repeated data-access latency, but it is not a replacement for scaling the stateless compute tier.
  4. Configure EC2 Auto Scaling target tracking on a per-instance request or utilization metric, with defined minimum and maximum capacity. ✓
    Target tracking adjusts the group toward a desired per-instance workload, while minimum and maximum settings bound scaling.
The trap
Prefer a per-instance utilization or throughput signal for target tracking; verify that the architecture does not depend on local session state.

Use EC2 Auto Scaling target tracking with a per-instance workload metric and explicit capacity bounds.

9. Use ElastiCache as a cache-aside layer: Which design best meets these requirements?

Medium
A solutions architect is reviewing a read-heavy product-catalog service. The authoritative database must remain durable, catalog responses should usually return with very low latency, and data may be up to 60 seconds stale. The application must tolerate cache loss and avoid serving stale values indefinitely. Which design best meets these requirements?
  1. Use an ElastiCache cluster as the sole catalog store and remove the database read path after population.
    An in-memory cache is not, by itself, a suitable durable authoritative record. Cache loss would jeopardize catalog availability or data.
  2. Use ElastiCache as a cache-aside layer, apply a 60-second TTL, and read the database on misses. ✓
    This provides low-latency reads while retaining the database as the durable source. TTL limits staleness, and miss handling allows recovery after cache loss.
  3. Cache catalog responses without expiration and rely on database updates to refresh them automatically.
    Caching does not automatically invalidate or refresh entries when the database changes. Without TTL or explicit invalidation, stale values can persist indefinitely.
  4. Use a database read replica for every catalog request and refresh replica data every 60 seconds.
    A read replica can distribute database reads, but it does not provide the requested in-memory low-latency cache layer or a cache-loss fallback pattern.
The trap
For cache scenarios, verify the source of truth, miss behavior, and the mechanism that limits stale data.

A cache-aside ElastiCache layer with a 60-second TTL balances latency, bounded staleness, and database durability.

10. Send events to an Amazon Kinesis Data Stream using: Which solution meets these requirements?

Medium
A company receives telemetry events from thousands of devices. The operations team needs to process each event with two independent applications, replay retained events after a processing defect, and preserve ordering for each device. Events must be ingested continuously without requiring the producer to coordinate directly with either consumer. Which solution meets these requirements?
  1. Send events to Amazon Data Firehose and configure buffering plus transformations before delivery to the destination.
    Firehose provides managed delivery and optional transformation, but it is not an application-managed replay log for independent consumers.
  2. Send events to one Amazon SQS Standard queue and have both applications poll that queue with competing consumers.
    Competing consumers divide messages, so each application would not receive every event; SQS Standard also provides only best-effort ordering.
  3. Send events to an Amazon Kinesis Data Stream using the device identifier as the partition key; let both applications consume the stream independently. ✓
    Kinesis Data Streams supports multiple consumers, retention and replay. A device-based partition key preserves ordering within each device’s partition-key scope.
  4. Publish events to an Amazon SNS topic with one shared SQS subscription consumed by both applications.
    A shared subscription queue still distributes messages among competing consumers instead of providing each application its own complete stream.
The trap
Check whether the requirement is managed delivery to a destination or a retained stream that several applications read independently.

Kinesis Data Streams provides independent consumers, retention and replay, while partition keys provide ordering within each device’s scope.

11. Allow the SNS topic to send messages to each subscribed: What should the architect configure?

Medium
A solutions architect is reviewing an event-processing design. An SNS topic has two SQS queues subscribed, each with an independent consumer. The topic, subscriptions, consumers, and permissions for publishing and reading are configured. Messages are published successfully, but neither queue receives them. What should the architect configure?
  1. Allow the SNS topic to send messages to each subscribed SQS queue in the queues’ resource policies. ✓
    SNS requires permission to deliver messages to each subscribed queue. Adding the appropriate queue-policy permissions enables fanout delivery.
  2. Configure an SQS consumer to republish each received message to the other queue.
    Republishing after consumption adds unnecessary coupling and still does not fix the missing permission that prevents SNS delivery.
  3. Increase each queue’s visibility timeout so SNS can retain messages until consumers become available.
    Visibility timeout only temporarily hides messages after receipt; it does not authorize SNS to deliver messages or retain undelivered events.
  4. Replace the two queues with one shared queue so both consumers can receive every published event.
    Competing consumers on one queue divide messages rather than each receiving a copy, so this would not provide broadcast behavior.
The trap
For SNS fanout, verify every subscribed queue’s resource policy before troubleshooting consumer behavior.

The missing prerequisite is an SQS resource policy permitting the SNS topic to deliver messages to each queue.

12. Add an SQS queue resource policy allowing the SNS topic: Which change should the solutions architect make?

Medium
A company publishes order events to an SNS topic. Two independently scaled applications must each receive every event and process it at their own pace. Each application has its own SQS Standard queue, both queues are subscribed to the topic, and consumer permissions and polling are configured correctly. One application receives no messages, while the other works normally. The affected queue has no resource policy allowing the SNS topic to deliver messages. Which change should the solutions architect make?
  1. Configure both applications to consume from the working queue so every consumer receives each published event.
    Consumers competing on one queue divide messages; they do not each receive a copy.
  2. Increase the affected queue's visibility timeout so SNS can deliver messages hidden during processing.
    Visibility timeout affects already-received messages and does not authorize SNS to deliver new messages.
  3. Add an SQS queue resource policy allowing the SNS topic to send messages to the affected queue. ✓
    The queue policy is the missing authorization required for SNS-to-SQS delivery.
  4. Replace the SNS topic with Kinesis Data Streams and have both applications read the same stream.
    A stream can support multiple consumers, but replacing the existing fanout design does not fix the missing queue-delivery permission.
The trap
For SNS-to-SQS fanout, verify the subscription and the destination queue policy before changing consumer behavior or delivery settings.

Permit the SNS topic to send messages to the affected SQS queue through the queue's resource policy.

260 more Design Resilient Architectures questions

The remaining 260 questions in this domain are part of the full AWS Solutions Architect bank — 1061 questions, every option explained. Start with the free five-minute check and see your score per domain.

Test your AWS Solutions Architect readiness — free

Other AWS Solutions Architect domains

Part of the Certsqill AWS Solutions Architect question bank · Design Resilient Architectures · Every answer, right and wrong, comes with its own explanation.