AWS Solutions Architect High-Performing 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 High-Performing Architectures: 256 practice questions

AWS Solutions Architect 256 questions 12 shown free

12 of the 256 Design High-Performing 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. AWS Direct Connect with a dedicated 10 Gbps connection: Which connectivity solution meets these requirements?

Hard
A company processes 50 TB of daily data transfers between its on-premises HPC cluster and Amazon S3. The data transfer must complete within an 8-hour nightly window and requires consistent bandwidth without competition from internet traffic. The company cannot tolerate jitter or variable latency. Which connectivity solution meets these requirements?
  1. AWS Site-to-Site VPN over the public internet, encrypting traffic across shared and highly variable network paths
    AWS VPN encrypts traffic over the public internet. Internet routing introduces variable latency, jitter, and bandwidth variability depending on internet congestion — directly violating the 'consistent bandwidth, no jitter' requirement.
  2. Amazon S3 Transfer Acceleration, speeding uploads through CloudFront while still using the public internet
    S3 Transfer Acceleration speeds up S3 uploads via CloudFront edge locations but still uses the public internet for the on-premises segment. It does not provide dedicated bandwidth or eliminate jitter from internet routing.
  3. AWS DataSync running over an AWS VPN tunnel, inheriting the bandwidth variability and jitter of the public internet
    DataSync accelerates and manages data transfers, but when combined with VPN (public internet), it inherits the bandwidth variability and jitter of the public internet. DataSync over Direct Connect would be more appropriate, but that option is not listed.
  4. AWS Direct Connect with a dedicated 10 Gbps connection providing private, consistent, and jitter-free bandwidth ✓
    AWS Direct Connect provides a private, dedicated physical connection between on-premises and AWS. It delivers consistent bandwidth, deterministic latency, and no bandwidth competition with public internet traffic — meeting all requirements. A 10 Gbps connection can transfer 50 TB in ~11 hours at full speed (or faster with multiple connections/ECMP).
The trap
Choosing VPN because 'it's encrypted and connects on-prem to AWS' — VPN uses the public internet, which has variable bandwidth and jitter. Direct Connect is the private, dedicated connection.

AWS Direct Connect provides a dedicated private connection with consistent bandwidth, no internet jitter, and deterministic latency — required for high-volume HPC data transfers with SLA constraints.

2. CloudFront Functions for URL path rewriting: Which combination of CloudFront compute options is most appropria

Hard
A company uses Amazon CloudFront for its global web application. They need to implement two features: (1) rewrite URL paths for A/B testing (append ?version=B to 5% of requests based on a simple cookie check) and (2) perform JWT authentication validation by calling an external authorization service before forwarding to the origin. Which combination of CloudFront compute options is most appropriate?
  1. CloudFront Functions for JWT validation at the viewer request and Lambda@Edge for the simple URL path rewriting at the origin request
    This reverses the capabilities: CloudFront Functions cannot make the outbound network call that external JWT validation needs, while a simple path rewrite needs no network call and fits CloudFront Functions, so the roles are swapped.
  2. CloudFront Functions for URL path rewriting (viewer request), Lambda@Edge for JWT validation with external service call (origin request) ✓
    CloudFront Functions run at viewer request/response events with sub-millisecond execution, sub-1ms latency, and JavaScript-only runtime — perfect for simple path rewrites. Lambda@Edge is needed for JWT validation because it can make external network calls (to the auth service), has longer execution time limits (5 seconds at viewer events), and full Node.js/Python runtimes.
  3. Lambda@Edge for both the A/B URL path rewriting at viewer request and the JWT validation with the external authorization service call at the origin
    Lambda@Edge can do both, but using it for a trivial cookie-based path rewrite is wasteful; CloudFront Functions cost about one-sixth as much and run faster for simple rewrites, so this pairing is not the most appropriate.
  4. CloudFront Functions for both the A/B URL path rewriting and the JWT validation call out to the external authorization service before the origin
    CloudFront Functions have no outbound network access, so they cannot call the external authorization service for JWT validation; that requirement forces Lambda@Edge for the origin-request step.
The trap
CloudFront Functions cannot make network calls to external services — Lambda@Edge is required for any edge function that needs to communicate with external systems like authentication services.

CloudFront Functions handle simple, sub-millisecond URL rewrites (no network calls); Lambda@Edge handles complex logic requiring external network calls like JWT validation with an auth service.

3. Amazon FSx for NetApp ONTAP: Which AWS storage service meets all these requirements?

Hard
A company is migrating an on-premises NetApp ONTAP storage system to AWS. Their applications require simultaneous access via NFS (Linux), SMB (Windows), and iSCSI protocols to the same storage volume. They also need to replicate data to AWS using NetApp SnapMirror. Which AWS storage service meets all these requirements?
  1. Amazon EFS with multi-protocol gateway
    Amazon EFS supports NFSv4 only. It does not support SMB or iSCSI. There is no 'multi-protocol gateway' service that adds these protocols to EFS. EFS cannot serve as a SnapMirror replication target.
  2. Amazon FSx for OpenZFS
    FSx for OpenZFS provides NFS-accessible storage based on OpenZFS. It does not support SMB or iSCSI, and it is not NetApp ONTAP — it cannot be a SnapMirror replication target from on-premises NetApp systems.
  3. Amazon FSx for NetApp ONTAP ✓
    FSx for NetApp ONTAP is a fully managed service that runs ONTAP file system software on AWS. It supports NFS, SMB, and iSCSI simultaneously from the same volume, and supports NetApp SnapMirror replication from on-premises ONTAP systems to AWS — making it the only service that meets all three requirements.
  4. Amazon FSx for Windows File Server
    FSx for Windows File Server supports SMB protocol and Windows-based access. It does not support NFS or iSCSI, and it is not NetApp ONTAP software — it runs Windows Server storage technology and cannot use SnapMirror.
The trap
Assuming a combination of EFS (NFS) and Storage Gateway (SMB) satisfies multi-protocol requirements — only FSx for NetApp ONTAP serves NFS, SMB, and iSCSI from the same volume.

FSx for NetApp ONTAP is the only AWS storage service that supports NFS, SMB, and iSCSI simultaneously on the same volume and acts as a SnapMirror replication target from on-premises ONTAP systems.

4. Use a Cognito User Pool authorizer for standard user: Which authorizer configuration supports both requirement

Medium
A company builds an API with Amazon API Gateway. Authenticated users from a mobile app (using Amazon Cognito User Pools) should access most endpoints. However, one endpoint must also accept requests from third-party services using their own JWT tokens from a different identity provider (not Cognito). Which authorizer configuration supports both requirements with least development effort?
  1. Use a single Lambda authorizer on all endpoints that validates both Cognito-issued and third-party JWT tokens in code
    A single Lambda authorizer can validate both token types with custom code, but this requires more development effort than using the built-in Cognito authorizer for Cognito tokens. The question asks for least development effort — using the native Cognito authorizer where possible minimizes custom code.
  2. Use IAM authorization on all endpoints and register both the Cognito users and the third-party services as IAM principals
    IAM authorization uses AWS SigV4 signed requests — it requires all callers to have AWS credentials. Third-party services with their own JWT tokens would need AWS credentials, which is impractical and defeats the purpose of federated identity.
  3. Use a Cognito User Pool authorizer for standard user endpoints and a Lambda authorizer for the third-party JWT endpoint ✓
    Cognito User Pool authorizers natively validate JWTs issued by Cognito User Pools with zero code — ideal for the mobile app endpoints. Lambda authorizers execute custom logic to validate any token format or call any identity provider — perfect for third-party JWT validation where Cognito authorizer cannot be used.
  4. Use an API key on all endpoints and distribute separate keys to the mobile users and to the third-party services
    API keys are for usage plans and throttling control, not authentication. They do not verify user identity, cannot enforce fine-grained access control, and are not a substitute for JWT-based authentication.
The trap
Choosing a single Lambda authorizer for all endpoints when the Cognito User Pool authorizer handles Cognito JWT validation natively with zero development effort.

A Cognito User Pool authorizer handles native Cognito JWT validation with no code; a Lambda authorizer handles custom third-party JWT validation — combining both minimizes development effort while supporting both identity providers.

5. Amazon Timestream: Which AWS database service is purpose-built for this?

Easy
A company collects sensor readings from 100,000 IoT devices every second — each reading includes device ID, timestamp, temperature, humidity, and pressure metrics. They need a database that automatically aggregates and compresses older data, supports SQL-like queries with time functions (e.g., time_series, interpolate, smooth), and scales to handle 100,000 writes/second without DBA intervention. Which AWS database service is purpose-built for this?
  1. Amazon DynamoDB with a composite key of DeviceId + Timestamp
    DynamoDB can store time-series data using DeviceId + Timestamp composite keys. However, it does not provide built-in time-series aggregation functions, data tiering/compression based on age, or time-series-specific SQL functions (interpolate, smooth, bin). DynamoDB requires custom application logic for time-series analysis.
  2. Amazon Timestream ✓
    Amazon Timestream is a fully managed time-series database built for IoT and operational metrics. It automatically organizes data in a memory store (recent data, fast writes) and a magnetic store (historical data, compressed), with automatic tiering. Timestream provides a SQL-like query language with built-in time-series functions (time_series, interpolate, smooth, bin) and scales to trillions of events per day.
  3. Amazon RDS PostgreSQL with a TimescaleDB extension for time-series optimization
    TimescaleDB extends PostgreSQL with time-series optimization (hypertables, continuous aggregations). While powerful, it requires managing RDS instances, defining partition intervals, and configuring aggregations — more operational overhead than Timestream. TimescaleDB is not a native AWS managed service.
  4. Amazon OpenSearch Service with an index template using timestamp-based index patterns
    OpenSearch can store and query time-series data using Kibana dashboards, but it is optimized for log analytics and full-text search, not time-series metrics with interpolation and aggregation. It lacks Timestream's purpose-built time-series SQL functions and automatic storage tiering for IoT sensor data.
The trap
Using DynamoDB for time-series IoT analytics — while valid for storage, DynamoDB lacks built-in time-series SQL functions (interpolation, smoothing, binning) that Timestream provides natively.

Amazon Timestream is purpose-built for IoT time-series data — automatic memory/magnetic storage tiering, built-in time-series SQL functions, and scales to trillions of events per day without DBA management.

6. CloudFront Functions for the cookie-based A/B URL: Which combination should the solutions architect use?

Hard
A media company uses Amazon CloudFront to deliver content globally. They need to perform two request-time operations: (1) A/B testing by rewriting URLs to different origins based on a cookie (execution needed at viewer request); (2) Fetching a JWT from Amazon DynamoDB to validate user entitlements before serving content (requires network access and >5ms execution time). Which combination should the solutions architect use?
  1. CloudFront Functions for both operations, with DynamoDB Global Tables replicated into every CloudFront edge location so the JWT lookup can run at viewer request without a network hop
    DynamoDB Global Tables replicate to specific AWS Regions, not to the hundreds of CloudFront edge PoPs, and CloudFront Functions cannot make network calls regardless of where DynamoDB lives.
  2. CloudFront Functions for both the A/B URL rewriting and the DynamoDB JWT lookup, relying on their sub-millisecond runtime to validate entitlements at viewer request before serving content
    CloudFront Functions cannot make any network calls (no DynamoDB access), are limited to about 1ms, and only manipulate request/response data already present. The JWT lookup cannot run there.
  3. CloudFront Functions for the cookie-based A/B URL rewriting at viewer request, and Lambda@Edge at the viewer-request event to query DynamoDB and validate the JWT before serving content ✓
    CloudFront Functions handle lightweight sub-millisecond rewrites and A/B tests but cannot make network calls. Lambda@Edge can query DynamoDB, run longer (up to 5s at viewer events), and validate the JWT.
  4. Lambda@Edge for both the cookie-based A/B URL rewriting and the DynamoDB JWT validation, running each at the viewer-request event so entitlements are checked before serving content
    Lambda@Edge can do both, but it is heavier and costlier for a simple URL rewrite, with higher latency and cold starts. The optimal design uses CloudFront Functions for the rewrite and reserves Lambda@Edge for the DynamoDB call.
The trap
Candidates default to Lambda@Edge for all CloudFront customizations, unaware that CloudFront Functions exist for simpler, cheaper, lower-latency manipulations.

CloudFront Functions handle lightweight viewer-request manipulations; Lambda@Edge handles operations requiring network calls or longer execution times.

7. Create three AWS Batch job queues with different: Which AWS Batch architecture achieves this?

Medium
A genomics company runs three types of batch jobs: (1) urgent clinical analysis (must complete within hours), (2) research analysis (can wait 24 hours), and (3) archival reprocessing (can wait days). All jobs run as Docker containers. The company wants to maximize Spot Instance usage for cost savings while ensuring urgent jobs always run immediately. Which AWS Batch architecture achieves this?
  1. Deploy every job on Amazon ECS with Fargate, using Fargate Spot for archival and research jobs while running the urgent clinical jobs on standard on-demand Fargate capacity
    ECS with Fargate can run batch containers but lacks AWS Batch's job queue priority system, job dependencies, array jobs, and managed Spot interruption handling built for batch computing. AWS Batch is purpose-built for this pattern and manages retry logic, queuing, and scaling automatically.
  2. Create three AWS Batch job queues with different priorities; connect each queue to a separate compute environment: urgent → On-Demand, research → Spot, archival → Spot with lower max vCPUs ✓
    AWS Batch job queues have priorities—higher priority queues get resources first when multiple queues target the same compute environment. By separating compute environments: urgent jobs use On-Demand (guaranteed capacity), research and archival use Spot (cost savings). Queues with different priorities ensure urgent jobs are never preempted by research or archival jobs.
  3. Create one AWS Batch job queue connected to a single Spot compute environment, then assign a higher job priority value to each urgent clinical job at submission time so it schedules first
    A single Spot compute environment means all job types compete for the same Spot capacity, so urgent clinical jobs could be disrupted by Spot interruptions. Job priorities set scheduling order, but Spot reclaims can terminate any running job regardless of priority—urgent jobs need guaranteed On-Demand capacity.
  4. Run the urgent clinical jobs on AWS Lambda for immediate execution while sending the research and archival jobs to AWS Batch on Spot compute environments for cost savings
    Lambda functions have a 15-minute maximum execution time and limited compute (up to 10 GB memory). Genomics analysis jobs typically run for hours and require significant compute. Lambda is not suitable for long-running batch genomics workloads.
The trap
Candidates create a single Spot compute environment for all jobs to maximize savings, not realizing urgent jobs need On-Demand to guarantee availability. Spot instances can be interrupted at any time, disqualifying them for time-sensitive clinical workloads.

Three AWS Batch job queues with different compute environments (On-Demand for urgent, Spot for lower-priority) ensures urgent jobs run immediately while research and archival maximize Spot savings.

8. Amazon Managed Streaming for Apache Kafka: Which AWS service should a solutions architect recommend?

Hard
A company is migrating an on-premises data pipeline that uses Apache Kafka with multiple consumer groups. The pipeline processes 1 TB of streaming data per day. The company's existing applications use Kafka client libraries and must continue to work without code changes. The company wants to minimize infrastructure management overhead while maintaining Kafka compatibility. Which AWS service should a solutions architect recommend?
  1. Self-managed Apache Kafka running on Amazon EC2 instances with Auto Scaling groups, giving full broker control while preserving complete Kafka client compatibility.
    Incorrect. Self-managed Kafka on EC2 maintains Kafka compatibility but does NOT minimize infrastructure management overhead — it maximizes it. The company must manage broker configuration, patching, monitoring, and failure handling themselves. Amazon MSK provides the same compatibility with significantly less management overhead.
  2. Amazon Managed Streaming for Apache Kafka (MSK), which provides a fully managed Kafka service compatible with existing Kafka clients and APIs. ✓
    Correct. Amazon MSK is a fully managed Apache Kafka service. Existing Kafka client applications work without code changes because MSK is fully API-compatible with Apache Kafka. MSK manages broker provisioning, patching, and availability, significantly reducing infrastructure management overhead compared to self-managed Kafka clusters.
  3. Amazon Kinesis Data Streams, which provides a fully managed, scalable streaming service exposing Kafka-compatible APIs for all existing consumer applications.
    Incorrect. Amazon Kinesis Data Streams does NOT have Kafka-compatible APIs. Kinesis uses its own SDKs and APIs (PutRecord, GetRecord, Kinesis Client Library). Migrating from Kafka to Kinesis requires rewriting all producer and consumer applications — violating the no-code-change requirement.
  4. Amazon Kinesis Data Firehose, which auto-scales to ingest 1 TB per day and routes streaming records without any infrastructure management.
    Incorrect. Amazon Kinesis Data Firehose is a data delivery service for loading streaming data into destinations like Amazon S3, Redshift, and OpenSearch. It does not support Kafka client protocols, consumer groups, or the pub/sub model. It is a near-real-time delivery pipeline, not a general-purpose Kafka replacement.
The trap
Recommending Kinesis Data Streams as a Kafka replacement — Kinesis has its own proprietary API and requires code changes to migrate from Kafka producers/consumers.

Amazon MSK is fully API-compatible with Apache Kafka, allowing existing Kafka client applications to work without code changes, while managing the underlying Kafka infrastructure.

9. Amazon FSx for Windows File Server: Which AWS storage service should a solutions architect recommend?

Medium
A company is migrating a Windows-based application from on-premises to AWS. The application uses SMB file shares to share data between multiple Windows EC2 instances and requires Active Directory integration for access control, NTFS permissions, and support for Windows-native features. Which AWS storage service should a solutions architect recommend?
  1. Amazon FSx for NetApp ONTAP, which is optimized for Linux NFS workloads and cannot enforce NTFS permissions or join an Active Directory domain for Windows SMB clients.
    Incorrect. This description is wrong: FSx for NetApp ONTAP is a multi-protocol service that does support SMB and Active Directory. However, for a Windows-only migration that needs native Windows file sharing, the purpose-built choice is FSx for Windows File Server, so ONTAP is not the recommended answer here.
  2. Amazon EFS, which offers elastic NFSv4 shared storage but relies on POSIX permissions and cannot present SMB shares or honor NTFS Active Directory access controls.
    Incorrect. Amazon EFS uses the NFSv4 protocol with POSIX permissions and targets Linux workloads. It does not expose SMB shares, enforce NTFS permissions, or integrate with Active Directory, so Windows EC2 instances cannot use it with native Windows file sharing.
  3. Amazon EBS Multi-Attach with io2 volumes, which shares a raw block device across instances but exposes no SMB file share and requires a cluster-aware filesystem to coordinate writes.
    Incorrect. EBS Multi-Attach lets an io2 volume attach to multiple Nitro-based instances, but it presents a raw block device and needs a cluster-aware filesystem to manage concurrent writes. It provides no SMB file share, NTFS permissions, or Active Directory integration, so it is not a Windows file sharing solution.
  4. Amazon FSx for Windows File Server, which provides a fully managed native Windows file system with SMB protocol, NTFS, Active Directory integration, and DFS Namespaces support. ✓
    Correct. Amazon FSx for Windows File Server is a fully managed Windows-native shared file system. It supports SMB protocol, NTFS permissions, Active Directory integration (AWS Managed AD or self-managed AD), DFS Namespaces, and Windows ACLs. It is the purpose-built AWS service for Windows file sharing workloads.
The trap
Choosing EFS as the shared file system for Windows workloads — EFS uses NFS protocol and is incompatible with Windows SMB file sharing. FSx for Windows File Server is the correct Windows-native managed file system.

Amazon FSx for Windows File Server is the purpose-built managed service for Windows SMB file shares with full NTFS, Active Directory, and DFS support — the correct choice for Windows file sharing migrations.

10. Use a provisioned IOPS SSD EBS volume for the application: Which solution best meets the requirements?

Medium
A solutions architect is reviewing an EC2-hosted transactional application. It requires persistent block storage, consistently demanding random I/O with predictable low latency, and high IOPS. The volume is attached to one instance, and the team wants storage designed specifically for this performance profile. Which solution best meets the requirements?
  1. Use a provisioned IOPS SSD EBS volume for the application data. ✓
    Provisioned IOPS SSD is intended for demanding workloads that require predictable latency and high IOPS while retaining EBS block-storage semantics.
  2. Use a gp3 EBS volume and rely on its independent IOPS and throughput settings.
    gp3 permits independent provisioning, but the stated consistently demanding, predictable performance profile is better matched to provisioned IOPS SSD.
  3. Use Regional EFS mounted by the instance for the transactional block data.
    Regional EFS provides shared managed NFS file storage, but it does not provide the required EBS block-storage model for this single-instance transactional workload.
  4. Use a st1 Throughput Optimized HDD EBS volume for the transactional data.
    st1 is designed for large sequential workloads, not demanding random transactional I/O, so it does not satisfy the access pattern.
The trap
Identify the access pattern first: demanding random low-latency I/O points toward provisioned IOPS SSD, whereas large sequential streams point toward HDD options.

Provisioned IOPS SSD EBS is the appropriate fit for persistent block storage requiring demanding, predictable random I/O performance.

11. Create a Regional EFS file system and mount it: Which solution best meets these requirements?

Medium
A Linux web workload currently stores user-uploaded files on a single-attached EBS volume. Requests are distributed across instances in three Availability Zones, and users intermittently receive missing-file errors when requests reach another instance. The company requires shared file access, continued operation after an Availability Zone failure, and minimal storage administration. Which solution best meets these requirements?
  1. Create a Regional EFS file system and mount it from the Linux instances with appropriate network permissions. ✓
    Regional EFS provides managed shared NFS access for Linux instances across Availability Zones and is designed for resilient regional file storage.
  2. Use FSx for Windows File Server with Active Directory integration and mount its SMB share from the Linux instances.
    FSx for Windows addresses Windows-compatible SMB and Active Directory requirements, which are not the workload’s Linux shared-NFS requirement.
  3. Create a One Zone EFS file system and mount it from all instances to minimize latency and administration.
    One Zone EFS can provide shared file access but does not meet the stated Availability Zone failure requirement.
  4. Attach one gp3 EBS volume to instances in each Availability Zone and synchronize files between the volumes.
    Separate EBS volumes do not provide one shared filesystem; synchronization adds application and operational complexity and can produce inconsistent copies.
The trap
When several Linux instances need the same files across Availability Zones, evaluate Regional EFS before block-storage or object-storage alternatives.

Regional EFS supplies shared Linux file access with regional Availability Zone resilience and managed operations.

12. Use a persistent FSx for Lustre file system integrated: Which solution best meets these requirements?

Medium
A solutions architect is reviewing storage for a multi-AZ Linux analytics platform. Hundreds of compute instances concurrently process large datasets, requiring high-throughput shared file access and rapid repeated reads. The source dataset must remain durable if the file system is replaced, and administrators want minimal data-movement operations. Which solution best meets these requirements?
  1. Use a persistent FSx for Lustre file system integrated with an S3 data repository. ✓
    Persistent FSx for Lustre provides shared, high-performance Linux file storage while S3 retains the durable source dataset.
  2. Attach a provisioned-IOPS EBS volume to one instance and expose it through that instance.
    A normally attached EBS volume is not a suitable shared file system for hundreds of concurrent instances across Availability Zones.
  3. Use an FSx for Lustre scratch file system and periodically copy results to S3.
    Scratch storage is intended for temporary workloads and cannot be the sole durable copy during file-system loss.
  4. Use Regional EFS mounted by every compute instance, with S3 storing the source dataset.
    Regional EFS provides resilient shared Linux files, but it does not target the high-performance compute-intensive access pattern as directly as Lustre.
The trap
Separate the performance tier from the durable source of truth; scratch capacity is not a backup.

Persistent FSx for Lustre supplies high-performance shared Linux file access, while S3 provides the durable repository.

244 more Design High-Performing Architectures questions

The remaining 244 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 High-Performing Architectures · Every answer, right and wrong, comes with its own explanation.