All practice questions

1462 questions

All types1,462 Multiple choice739 Multiple select723

A media streaming company is designing a global application and needs to store user profiles in Amazon DynamoDB. The application must run in an active-active configuration across two AWS Regions: us-east-1 and us-west-2. The database configuration must support local read and write operations in both Regions, maintain replica synchronization with a Recovery Point Objective (RPO) of less than 1 second, and provide a Recovery Time Objective (RTO) of near zero. Which database configuration should a solutions architect recommend to meet these requirements?

Create an Amazon DynamoDB global table replica in both us-east-1 and us-west-2.

Create a DynamoDB table in us-east-1, configure a Global Secondary Index (GSI) targeting us-west-2, and enable DynamoDB Streams to replicate write operations.

Deploy a DynamoDB table in us-east-1, configure an AWS Lambda function triggered by DynamoDB Streams to write updates to a DynamoDB table in us-west-2, and use Route 53 latency routing to distribute writes.

Configure a DynamoDB table in us-east-1, schedule an AWS Backup job to copy table backups to us-west-2 every 15 minutes, and deploy a warm standby table in us-west-2.

Show answer & explanation

Answer: Create an Amazon DynamoDB global table replica in both us-east-1 and us-west-2.

Answer

Create an Amazon DynamoDB global table replica in both us-east-1 and us-west-2.

Creating an Amazon DynamoDB global table replica in both target regions provides a fully managed, active-active multi-region configuration. It automatically replicates changes across regions, delivering local read and write performance with near-zero RTO and an RPO of under one second.

Step-by-Step Solution

Identify the primary architectural requirements.

The requirements are multi-region active-active writes, sub-second RPO, and near-zero RTO.

This establishes the constraints needed to select the correct database configuration.

Evaluate the capabilities of Amazon DynamoDB Global Tables.

DynamoDB Global Tables are designed for active-active multi-region configurations, providing automatic bi-directional replication with sub-second latency.

This matches all stated RPO, RTO, and active-active constraints out of the box.

Verify if the distractors meet the constraints.

GSIs are single-region only; custom Lambda stream replication is prone to high latency and replication loops; backup strategies fail the sub-second RPO requirement.

This eliminates the incorrect configurations.

Key Concept

DynamoDB Global Tables for Multi-Region Active-Active High Availability

Estimated Time:1m 30s

Question 662Question →

A media streaming platform needs to design a high-performing ingestion and transformation pipeline to process clickstream data generated by its web application. The platform receives user interaction events (play, pause, seek) at an average rate of $5\text{ MB/s}$ , peaking at $25\text{ MB/s}$ during major content releases.

The pipeline must satisfy two key requirements:
1. Deliver clickstream data with sub-second latency to a real-time personalization engine.
2. Store the clickstream data in Amazon S3 in Apache Parquet format, partitioned by date, with a maximum latency of 5 minutes for historical analytics.

Which combination of actions should a Solutions Architect recommend to build the most performant and scalable solution? (Select two.)

Select all that apply

Configure an Amazon Kinesis Data Stream in on-demand capacity mode to ingest the clickstream events, and configure the real-time personalization engine as a consumer of the stream.

Configure an Amazon Kinesis Data Firehose delivery stream to read from the Kinesis Data Stream, buffer the incoming data for

300\text{ seconds}

, use an AWS Glue schema to convert the JSON events to Apache Parquet, and write the files to Amazon S3.

Ingest the clickstream events using an Amazon SQS standard queue, and configure both the personalization engine and Amazon Kinesis Data Firehose to pull messages simultaneously from the queue.

Configure an Amazon Kinesis Data Stream in provisioned capacity mode with

2\text{ shards}

to ingest the clickstream events, and use an AWS Glue streaming ETL job to write data to both the personalization engine and Amazon S3.

Configure an Amazon Kinesis Data Firehose delivery stream with a buffering interval of

0\text{ seconds}

to ingest the clickstream, and write the data directly to both the personalization engine and Amazon S3.

Show answer & explanation

Answer: Configure an Amazon Kinesis Data Stream in on-demand capacity mode to ingest the clickstream events, and configure the real-time personalization engine as a consumer of the stream.; Configure an Amazon Kinesis Data Firehose delivery stream to read from the Kinesis Data Stream, buffer the incoming data for $300\text{ seconds}$ , use an AWS Glue schema to convert the JSON events to Apache Parquet, and write the files to Amazon S3.

Answer

To build a performant and scalable solution, configure an Amazon Kinesis Data Stream in on-demand capacity mode to ingest the clickstream events and serve the personalization engine, and configure an Amazon Kinesis Data Firehose delivery stream to read from the stream, buffer the data for

300\text{ seconds}

, convert it to Apache Parquet using AWS Glue, and deliver it to Amazon S3.

The correct solution involves ingesting the clickstream data into an Amazon Kinesis Data Stream in on-demand capacity mode and utilizing Amazon Kinesis Data Firehose to transform and load the data into Amazon S3. Kinesis Data Streams supports multiple consumers and provides sub-second latency for direct consumers like the personalization engine. Configuring Kinesis Data Streams in on-demand capacity mode allows it to scale automatically up to the peak write throughput of

25\text{ MB/s}

without manual provisioning. For downstream storage, Kinesis Data Firehose can consume from the same Kinesis Data Stream, buffer the records for

300\text{ seconds}

to meet the latency requirement, convert the JSON payloads into Apache Parquet format using a schema from AWS Glue, and write the partitioned files to Amazon S3.

Step-by-Step Solution

Analyze ingestion capacity and latency requirements.

Identify that a peak ingestion rate of

25\text{ MB/s}

requires dynamic scaling, and the sub-second personalization engine requires direct stream access, while the historical analytics can accept a latency of up to 5 minutes (

300\text{ seconds}

Establishing clear bounds for throughput and latency guides the selection of Kinesis Data Streams for sub-second ingestion and Kinesis Data Firehose for batched S3 delivery.

Select the ingestion mechanism for sub-second consumption and scaling.

Deploy Amazon Kinesis Data Streams in on-demand capacity mode.

On-demand capacity mode automatically scales to handle up to

200\text{ MB/s}

(well above the

25\text{ MB/s}

peak), avoiding ProvisionedThroughputExceededException errors and allowing the personalization engine to read data immediately (sub-second latency).

Select the downstream delivery and format transformation mechanism.

Deploy Amazon Kinesis Data Firehose pointing to the Kinesis Data Stream as a source, with format conversion enabled via AWS Glue and a

300\text{ seconds}

buffer interval, writing to Amazon S3.

Kinesis Data Firehose natively integrates with Kinesis Data Streams to pull data, buffers it to meet the 5-minute requirement, transforms JSON to Parquet using AWS Glue schemas, and writes the output directly to S3 without custom processing code.

Key Concept

Leveraging Kinesis Data Streams for real-time, multi-consumer data ingestion alongside Kinesis Data Firehose for managed ETL and buffering into Amazon S3.

Question 663Question →

An environmental agency needs to ingest real-time air quality metrics from $10,000$ weather monitoring stations across a country. The frequency of data transmissions varies unpredictably based on weather events. The agency requires a serverless ingestion solution that automatically scales to handle traffic spikes and prevents data loss from write throttling, without requiring manual capacity planning or shard provisioning. Which AWS solution meets these requirements?

Amazon Kinesis Data Streams configured in Provisioned capacity mode with a static shard allocation

Amazon Kinesis Data Streams configured in On-Demand capacity mode

Amazon SQS standard queues to buffer the telemetry data under the assumption that message order is preserved

Amazon DynamoDB configured in Provisioned capacity mode to store raw metrics during peak events

Show answer & explanation

Answer: Amazon Kinesis Data Streams configured in On-Demand capacity mode

Answer

Amazon Kinesis Data Streams configured in On-Demand capacity mode

Amazon Kinesis Data Streams configured in On-Demand capacity mode is the correct choice because it automatically manages shard provisioning and scales capacity to accommodate the unpredictable, fluctuating data volume. This ensures high performance without manual administration or write throttling.

Step-by-Step Solution

Analyze the workload characteristics and operational constraints.

The workload requires real-time streaming ingestion from

10,000

endpoints with unpredictable traffic fluctuations, zero manual shard management, and no write throttling.

This establishes the requirements for selecting a dynamically scaling real-time ingestion service.

Evaluate Kinesis Data Streams capacity modes.

On-Demand mode automatically allocates and scales shards based on data volume, whereas Provisioned mode requires manual scaling and risks throttling during traffic spikes.

On-Demand mode eliminates the operational overhead of shard calculations and manual adjustments.

Compare against queue and database alternatives.

SQS standard queues do not guarantee strict ordering, and DynamoDB Provisioned capacity mode does not scale instantly to handle rapid spikes without proactive provisioning.

This confirms that Kinesis Data Streams On-Demand is the optimal, low-overhead solution.

Key Concept

Amazon Kinesis Data Streams On-Demand capacity mode automatically scales to accommodate unpredictable streaming data ingestion without manual shard management.

Estimated Time:50s

Question 664Question →

An enterprise is migrating its core high-performance computing (HPC) data ingestion platform to AWS. The platform requires a hybrid network connection between the on-premises storage systems and multiple VPCs across different AWS accounts in the `us-east-1` Region. The workload demands a minimum network throughput of $4\text{ Gbps}$ for transferring large datasets, and all data in transit must be encrypted. The solution must support automated routing failover and scale seamlessly as new VPCs are provisioned. Which TWO steps should a solutions architect take to build this network architecture? (Select TWO.)

Select all that apply

Deploy an AWS Transit Gateway (TGW) with Equal-Cost Multi-Path (ECMP) routing support enabled, and attach the target VPCs to the TGW.

Establish an AWS Direct Connect connection, configure a Transit Virtual Interface (Transit VIF), and set up multiple AWS Site-to-Site VPN connections over the Transit VIF using Border Gateway Protocol (BGP).

Deploy a Virtual Private Gateway (VGW) in each VPC, establish a single AWS Site-to-Site VPN connection to each VGW, and enable dynamic routing to automatically scale the VPN tunnel throughput to

4\text{ Gbps}

Establish an AWS Direct Connect connection with a Private Virtual Interface (Private VIF) to each VPC, and configure stateful Network Access Control Lists (NACLs) to encrypt all traffic passing over the Direct Connect link.

Configure a full mesh of VPC Peering connections between all VPCs, and implement Amazon Route 53 latency-based routing policies to distribute traffic over the peering connections from the on-premises DNS servers.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway (TGW) with Equal-Cost Multi-Path (ECMP) routing support enabled, and attach the target VPCs to the TGW.; Establish an AWS Direct Connect connection, configure a Transit Virtual Interface (Transit VIF), and set up multiple AWS Site-to-Site VPN connections over the Transit VIF using Border Gateway Protocol (BGP).

Answer

Deploying AWS Transit Gateway with ECMP routing enabled to connect the VPCs, combined with establishing multiple AWS Site-to-Site VPN connections over an AWS Direct Connect Transit VIF.

To achieve secure, encrypted transit at a throughput of

4\text{ Gbps}

, the organization must establish multiple AWS Site-to-Site VPN connections over an AWS Direct Connect link. Since a single VPN tunnel is limited to

1.25\text{ Gbps}

of throughput, multiple tunnels must be combined using AWS Transit Gateway with Equal-Cost Multi-Path (ECMP) enabled. Terminating these VPN connections on the Transit Gateway over a Transit Virtual Interface (Transit VIF) ensures that traffic is encrypted while dynamically distributing the load across the tunnels.

Step-by-Step Solution

Analyze the network bandwidth and encryption requirements.

Identify that the minimum throughput of

4\text{ Gbps}

exceeds the

1.25\text{ Gbps}

limit of a single AWS VPN tunnel, meaning multiple tunnels must be aggregated, and that Direct Connect traffic must be encrypted using IPsec VPN.

Establishing these parameters narrows down the solutions to multi-tunnel VPN over Direct Connect configurations.

Evaluate the scalability and routing mechanism.

Determine that AWS Transit Gateway is needed to enable Equal-Cost Multi-Path (ECMP) routing to load-balance and aggregate the throughput across at least four active VPN tunnels.

Transit Gateway allows central management of connections to multiple VPCs and supports ECMP for scaling VPN throughput.

Select the appropriate hybrid connectivity type.

Implement a Transit Virtual Interface (Transit VIF) on the AWS Direct Connect connection to route private IPsec VPN traffic directly to the AWS Transit Gateway.

A Transit VIF is required to connect AWS Direct Connect to a Transit Gateway, enabling VPN over Direct Connect for encrypted, high-bandwidth transit.

Key Concept

Scaling secure hybrid network throughput using AWS Transit Gateway ECMP and VPN over Direct Connect.

Question 665Question →

A logistics company is designing an ingestion system for real-time telemetry from $50,000$ delivery vehicles. Each vehicle sends a $2\text{ KB}$ JSON payload every $5\text{ seconds}$ containing GPS coordinates and sensor status. The company needs to ingest this data, transform it into Apache Parquet format, partition it by vehicle type and date, and load it into Amazon S3 for historical analysis. The system must scale automatically to handle traffic spikes, and the end-to-end data latency must be under $15\text{ minutes}$ . Which combination of actions should the solutions architect take to meet these requirements with the least operational effort? (Select two.)

Select all that apply

Create an Amazon Kinesis Data Stream in On-Demand capacity mode to ingest the incoming vehicle telemetry.

Create an Amazon Data Firehose delivery stream configured with the Kinesis Data Stream as the source, enabling record format conversion to Apache Parquet using AWS Glue.

Create an Amazon Kinesis Data Stream in Provisioned capacity mode with a fixed shard count of

5

shards to ingest the incoming telemetry.

Create an Amazon SQS standard queue to receive the telemetry data directly from the vehicles, and configure an AWS Glue ETL job to poll the queue continuously.

Create an Amazon SQS FIFO queue with message deduplication to store the records, and use Amazon EventBridge pipes to transform the messages and write them to S3.

Show answer & explanation

Answer: Create an Amazon Kinesis Data Stream in On-Demand capacity mode to ingest the incoming vehicle telemetry.; Create an Amazon Data Firehose delivery stream configured with the Kinesis Data Stream as the source, enabling record format conversion to Apache Parquet using AWS Glue.

Answer

The correct actions are to create an Amazon Kinesis Data Stream in On-Demand capacity mode to ingest the vehicle telemetry and create an Amazon Data Firehose delivery stream with the Kinesis Data Stream as the source, enabling record format conversion to Apache Parquet using AWS Glue.

An Amazon Kinesis Data Stream in On-Demand capacity mode handles the high peak ingestion throughput of

20\text{ MB/s}

and

10,000\text{ records/s}

automatically. Using Amazon Data Firehose to read from the stream and transform the JSON data into Parquet using AWS Glue provides a serverless, low-overhead solution that meets the latency target.

Step-by-Step Solution

Calculate the peak ingestion throughput and record rate from the vehicle fleet telemetry.

Peak throughput is calculated as

\frac{50,000 \text{ vehicles} \times 2 \text{ KB}}{5 \text{ seconds}} = 20 \text{ MB/s}

, and peak message rate is

\frac{50,000 \text{ records}}{5 \text{ seconds}} = 10,000 \text{ records/s}

This establishes the performance limits that any selected AWS ingestion service must support without throttling.

Evaluate Kinesis Data Streams shard capacity modes against the calculated requirements.

A provisioned stream with 5 shards supports only

5 \text{ MB/s}

and

5,000 \text{ records/s}

, which is insufficient. An On-Demand stream automatically scales to handle up to

200 \text{ MB/s}

and

200,000 \text{ records/s}

, comfortably meeting the peak.

Choosing Kinesis Data Stream in On-Demand mode ensures write throughput capacity scales automatically to handle traffic spikes.

Select a serverless, low-overhead transformation and delivery mechanism to load data into S3.

Amazon Data Firehose integrates directly with Kinesis Data Streams as a source, performs inline format conversion to Apache Parquet using AWS Glue schema definitions, and writes the output directly to S3 within the 15-minute latency requirement.

This minimizes operational overhead by avoiding custom EC2 or Lambda code for formatting and buffering.

Key Concept

Serverless high-throughput real-time stream ingestion and transformation using Amazon Kinesis Data Streams and Amazon Data Firehose.

Question 666Question →

A logistics company needs to archive historical delivery route logs. The logs must be stored with high durability across multiple Availability Zones. In the event of an audit, the company must be able to retrieve any archived log file within 10 minutes to satisfy their SLA. Which two storage configurations will meet these requirements? (Select TWO.)

Select all that apply

Amazon S3 Standard-Infrequent Access (S3 Standard-IA)

Amazon S3 Glacier Instant Retrieval

Amazon S3 Glacier Flexible Retrieval using Standard retrievals

Amazon S3 Glacier Deep Archive

Amazon EBS Provisioned IOPS SSD (io2) volumes with Multi-Attach enabled across multiple Availability Zones

Show answer & explanation

Answer: Amazon S3 Standard-Infrequent Access (S3 Standard-IA); Amazon S3 Glacier Instant Retrieval

Answer

The correct configurations are Amazon S3 Standard-Infrequent Access (S3 Standard-IA) and Amazon S3 Glacier Instant Retrieval.

Amazon S3 Standard-Infrequent Access (S3 Standard-IA) and Amazon S3 Glacier Instant Retrieval are the correct choices. Both storage classes replicate data across at least three Availability Zones, ensuring high availability and resilience. Furthermore, both offer millisecond-level access, ensuring that archived logs can be retrieved well within the 10-minute SLA constraint.

Step-by-Step Solution

Analyze the Availability Zone resilience requirement.

The storage solution must replicate data across multiple Availability Zones, which rules out single-AZ options.

This filters out configurations that are bound to a single Availability Zone, such as Amazon EBS volumes.

Evaluate the retrieval time constraints (Recovery Time Objective).

The target retrieval time must be under 10 minutes.

This filters out standard archive classes with long retrieval delays, such as Amazon S3 Glacier Flexible Retrieval with Standard retrieval (3-5 hours) or Amazon S3 Glacier Deep Archive (12 hours).

Select the configurations that support both multi-AZ replication and rapid retrieval.

Amazon S3 Standard-IA and Amazon S3 Glacier Instant Retrieval meet all constraints.

Both storage classes offer active, millisecond-level retrievals while storing data redundantly across three or more Availability Zones.

Key Concept

Selecting high-durability, multi-AZ AWS storage solutions that align with specific low RTO retrieval requirements.

Question 667Question →

An enterprise application uses an Amazon RDS for PostgreSQL database to manage critical transactions. The architecture must guarantee high availability (HA) within the primary Region ( $us-west-2$ ) with a Recovery Time Objective (RTO) of less than $60$ seconds and a Recovery Point Objective (RPO) of $0$ . For disaster recovery (DR) in a secondary Region ( $us-east-1$ ), the architecture must support a Recovery Point Objective (RPO) of less than $15$ minutes. The secondary Region must also support read scaling for local analytics workloads. Which of the following database configurations meets these requirements with the least operational complexity?

Configure the database as a Single-AZ Amazon RDS DB instance in the primary Region with a local read replica in a different Availability Zone. Configure the application to automatically promote the local read replica to primary during an outage, and create a cross-region read replica in the secondary Region.

Configure the database as an Amazon RDS Multi-AZ DB cluster deployment in the primary Region. Create a cross-region read replica in the secondary Region to serve local analytics workloads.

Configure an Amazon RDS Multi-AZ DB instance in the primary Region. Configure AWS Backup to take automated snapshots of the database every

12

hours and copy them to the secondary Region to maintain a pilot light environment.

Configure an Amazon RDS Multi-AZ DB instance in the primary Region and create a cross-region read replica in the secondary Region. Configure an Amazon Route 53 Latency routing policy without health checks to automatically redirect write traffic to the secondary Region replica during a failure.

Show answer & explanation

Answer: Configure the database as an Amazon RDS Multi-AZ DB cluster deployment in the primary Region. Create a cross-region read replica in the secondary Region to serve local analytics workloads.

Answer

Configure the database as an Amazon RDS Multi-AZ DB cluster deployment in the primary Region, and create a cross-region read replica in the secondary Region to serve local analytics workloads.

The correct configuration utilizes an Amazon RDS Multi-AZ DB cluster deployment in the primary Region. Multi-AZ DB clusters provide high availability with a writer DB instance and two readable reader DB instances across three Availability Zones. Failovers in this configuration typically take less than

35

seconds, which satisfies the RTO of less than

60

seconds, and the replication is synchronous, guaranteeing an RPO of

0

. A cross-region read replica in the secondary Region provides asynchronous replication to meet the DR RPO requirement of less than

15

minutes and allows local analytics workloads to perform read operations without impacting the primary writer.

Step-by-Step Solution

Analyze high availability (HA) requirements for the primary database tier.

The requirement for an RPO of

0

means replication within the primary Region must be synchronous. The requirement for an RTO of less than

60

seconds points to an RDS Multi-AZ cluster deployment, which typically fails over in less than

35

seconds, compared to a standard Multi-AZ instance which can take

60

120

seconds.

This rules out single-AZ deployments utilizing asynchronous read replicas for HA.

Evaluate disaster recovery (DR) and read scaling constraints in the secondary Region.

The database must support an RPO of less than

15

minutes in the secondary Region and allow read scaling for analytics.

Creating a cross-region read replica satisfies both constraints because replication is continuous (typically sub-minute lag, well under the

15

-minute RPO limit) and the replica can serve local read queries directly.

Assess failover and routing mechanisms.

Confirm that database write failovers across regions are not handled by passive read replicas directly, and that Route 53 Latency routing without health checks is insufficient.

This guarantees that the design relies on the native automated failover capabilities of the Multi-AZ DB cluster for local outages, and standard read replica promotion procedures for disaster recovery.

Key Concept

High Availability vs. Disaster Recovery in Amazon RDS

Question 668Question →

A smart grid utility company is designing a real-time data ingestion and transformation pipeline to process telemetry from $50,000$ smart grid sensors. Each sensor transmits a $5\text{ KB}$ JSON payload $10$ times per second. The pipeline must guarantee chronological order of records for each individual sensor. The raw JSON payloads must be converted into Apache Parquet format and stored in Amazon S3, partitioned by sensor ID and hour, with a maximum latency of $5$ minutes. Which architecture provides the highest performance and scaling capability with the least operational overhead?

Ingest data into Amazon Kinesis Data Streams provisioned with

2,500

shards, using the sensor ID as the partition key. Configure an Amazon Data Firehose stream with the Kinesis stream as the source, enable dynamic partitioning based on the sensor ID and timestamp, use AWS Glue Schema Registry for JSON-to-Parquet conversion, and write to Amazon S3.

Ingest data into Amazon Kinesis Data Streams configured in On-Demand mode, using the sensor ID as the partition key. Configure an Amazon Data Firehose stream with the Kinesis stream as the source. Use an AWS Lambda function invoked by Firehose to transform the format to Parquet, and write to Amazon S3.

Ingest data into Amazon SQS Standard queues to decouple the sensors. Configure an AWS Glue ETL job to run every

5

minutes to read from the SQS queues, convert the JSON payloads to Parquet format, partition the data by sensor ID and hour, and write the output to Amazon S3.

Ingest data directly into Amazon Data Firehose using the DirectPUT API. Configure Firehose to partition the incoming data dynamically by sensor ID and hour, convert the JSON payloads to Parquet format using the AWS Glue Schema Registry, and write the output to Amazon S3.

Show answer & explanation

Answer: Ingest data into Amazon Kinesis Data Streams provisioned with $2,500$ shards, using the sensor ID as the partition key. Configure an Amazon Data Firehose stream with the Kinesis stream as the source, enable dynamic partitioning based on the sensor ID and timestamp, use AWS Glue Schema Registry for JSON-to-Parquet conversion, and write to Amazon S3.

Answer

Ingest data into Amazon Kinesis Data Streams provisioned with

2,500

The correct architecture uses Amazon Kinesis Data Streams in provisioned mode with at least

2,500

shards. This satisfies the

2.5\text{ GB/s}

throughput limit (

1\text{ MB/s}

per shard write capacity). Using the sensor ID as the partition key ensures that records for each sensor are sent to the same shard, preserving chronological order. Amazon Data Firehose integrates directly with Kinesis Data Streams, converts JSON payloads to Parquet format using the AWS Glue Schema Registry, and utilizes dynamic partitioning to organize the files in Amazon S3 by sensor ID and hour, meeting all requirements with minimal operational overhead.

Step-by-Step Solution

Calculate the total ingestion metrics.

Total records/sec =

50,000 \times 10 = 500,000

records/sec. Total throughput =

500,000 \times 5\text{ KB} = 2,500,000\text{ KB/s} \approx 2.44\text{ GB/s}

(

2,500\text{ MB/s}

Sizing the ingestion layer requires calculating both the throughput (MB/s) and record rate (records/s).

Select and size the ingestion service.

Amazon Kinesis Data Streams in provisioned mode with at least

2,500

shards is selected. SQS FIFO is ruled out due to throughput limits (

30,000

records/sec max). Kinesis On-Demand is ruled out due to its default capacity limit (

200\text{ MB/s}

Each Kinesis shard supports a maximum write capacity of

1\text{ MB/s}

1,000

records/sec.

2,500\text{ MB/s} / 1\text{ MB/s per shard} = 2,500

shards. Sizing is bound by throughput rather than record count.

Determine ordering and delivery requirements.

Using the sensor ID as the partition key ensures all records from a given sensor route to the same shard, preserving chronological order. Amazon Data Firehose is used to consume from the Kinesis stream.

Firehose DirectPUT does not guarantee event ordering. Processing order can only be guaranteed by partition keys in Kinesis.

Configure the transformation and storage destination details.

Enable dynamic partitioning in Firehose using jq queries to extract the sensor ID and timestamp. Enable JSON-to-Parquet conversion using the AWS Glue Schema Registry, writing results directly to Amazon S3.

Using native Firehose transformations and dynamic partitioning minimizes operational overhead and satisfies the 5-minute latency limit through buffering.

Key Concept

High-throughput data ingestion scaling limits (Kinesis shard calculations), ordering requirements, and serverless format conversion.

Question 669Question →

A financial services company hosts a high-frequency trading dashboard on Amazon EC2 instances located in private subnets of a VPC. The application performs millions of read queries per second against an Amazon DynamoDB table containing real-time stock market ticker symbols. The dashboard requires sub-millisecond response times for read operations. During peak market hours, read throughput spikes dramatically, causing DynamoDB throttling and increased latency. The solutions architect must design a high-performing and cost-effective caching solution to solve this performance bottleneck. Which architecture will meet these requirements with the lowest latency and optimal cost-efficiency?

Deploy an Amazon CloudFront distribution in front of an Application Load Balancer that routes requests to the EC2 instances. To ensure the dashboard always displays real-time stock ticker data, configure the CloudFront cache behavior with a Minimum TTL, Maximum TTL, and Default TTL of 0 seconds.

Implement an application-level caching mechanism that writes queried ticker data as temporary JSON files to an Amazon S3 bucket. Configure the S3 bucket to use the Amazon S3 Standard-Infrequent Access (S3 Standard-IA) storage class, and use an S3 Lifecycle rule to expire objects after 24 hours.

Provision an Amazon DynamoDB Accelerator (DAX) cluster in the VPC subnets where the EC2 instances reside. Update the application configuration to use the DAX client SDK to query the DAX cluster endpoint instead of the database table directly.

Configure the application on the EC2 instances to write query responses to an Amazon S3 bucket. Access the cached data via S3 GET requests routed through a NAT Gateway in the public subnet to bypass DynamoDB read capacity limits.

Show answer & explanation

Answer: Provision an Amazon DynamoDB Accelerator (DAX) cluster in the VPC subnets where the EC2 instances reside. Update the application configuration to use the DAX client SDK to query the DAX cluster endpoint instead of the database table directly.

Answer

Amazon DynamoDB Accelerator (DAX) is an in-memory, fully managed write-through cache designed specifically for Amazon DynamoDB. It reduces read response times to microseconds (sub-millisecond) and offloads read capacity requirements from the database table. Because it runs inside the VPC and integrates transparently via the DAX SDK, it is the most performant and cost-effective solution for read-heavy stock ticker workloads.

Step-by-Step Solution

Analyze performance and database constraints

Workload requires sub-millisecond (microsecond) latency under millions of read queries per second against Amazon DynamoDB, while minimizing costs.

This establishes the requirement for an in-memory caching layer that sits directly in front of DynamoDB to prevent throttling and latency spikes.

Evaluate Amazon DynamoDB Accelerator (DAX) for performance and integration

DAX delivers microsecond latency, integrates seamlessly with the DynamoDB API, requires no application rewrite of query logic, and offloads read capacity requirements directly.

DAX is the native caching layer for DynamoDB and provides the lowest latency path with minimal management overhead.

Identify architectural and financial flaws in alternative options

Using CloudFront with TTL=0 eliminates caching benefits; using S3 Standard-IA for short-lived assets incurs a 30-day minimum storage charge penalty; using a NAT Gateway for high-volume S3 traffic incurs excessive data transfer processing fees.

These alternatives violate either performance (latency) or cost-efficiency constraints, failing to provide a high-performing architecture.

Key Concept

Selecting the optimal caching layer to accelerate database queries and minimize operational costs under high throughput

Alternative Method

Alternatively, if the application was built on a relational database like Amazon RDS, Amazon ElastiCache (Redis OSS or Memcached) could be used to cache query results at the application layer, though it requires custom cache invalidation logic compared to the seamless integration of DAX with DynamoDB.

Estimated Time:3m 0s

Question 670Question →

A software development company hosts a collaborative code repository application on Amazon EC2 instances deployed across two Availability Zones. The application requires a shared file system that is POSIX-compliant. The file system must dynamically scale to support large code repositories, provide consistent low latencies for active files, and replicate data across multiple Availability Zones to ensure high availability. Which two actions should a solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon Elastic File System (Amazon EFS) file system using the Regional (Standard) storage class.

Mount the Amazon EFS file system on the EC2 instances using the EFS mount helper and mount targets created in the subnets of each Availability Zone.

Provision an Amazon EBS volume with Multi-Attach enabled, and attach it to the EC2 instances across both Availability Zones.

Configure an Amazon RDS Multi-AZ DB cluster to store the repository files and use read replicas for failover.

Create an Amazon EFS file system using the One Zone storage class and configure AWS Backup to perform hourly replication to the other Availability Zone.

Show answer & explanation

Answer: Create an Amazon Elastic File System (Amazon EFS) file system using the Regional (Standard) storage class.; Mount the Amazon EFS file system on the EC2 instances using the EFS mount helper and mount targets created in the subnets of each Availability Zone.

Answer

Create an Amazon Elastic File System (Amazon EFS) file system using the Regional (Standard) storage class, and mount the file system on the EC2 instances using the EFS mount helper and mount targets created in the subnets of each Availability Zone.

The correct configuration combines Amazon EFS Regional storage class with mount targets in each Availability Zone. The Regional storage class automatically replicates data across multiple Availability Zones, ensuring high resilience and availability. Mount targets in each AZ subnet allow EC2 instances in different AZs to mount the file system concurrently over the network using standard NFS/POSIX protocols.

Step-by-Step Solution

Identify the storage requirements of the application.

The application requires a POSIX-compliant shared file system that dynamically scales and is accessible concurrently across multiple Availability Zones with high availability.

This rules out block storage solutions like EBS, which are typically restricted to a single instance or single AZ, and points towards Amazon EFS.

Select the appropriate Amazon EFS storage class.

Choose the EFS Regional (Standard) storage class.

Regional storage classes replicate data across multiple Availability Zones to protect against AZ failure, whereas One Zone storage classes restrict data to a single AZ.

Configure client access to the file system across AZs.

Create EFS mount targets in the subnets of each Availability Zone and mount them on the EC2 instances.

This allows instances in both Availability Zones to connect to the shared EFS file system concurrently.

Key Concept

Amazon Elastic File System (EFS) provides highly available, durable, and POSIX-compliant shared file storage across multiple Availability Zones.

Question 671Question →

A logistics corporation is migrating its containerized supply-chain optimization suite to AWS. The suite will run on Amazon ECS using AWS Fargate and consists of three primary workloads:

1. A core dispatch coordination engine that runs $24/7$ , requiring a constant baseline of $16\text{ vCPUs}$ and $64\text{ GB}$ of RAM.
2. A route-recalculation batch process that runs for $8$ hours daily ( $00:00$ to $08:00$ UTC). This process is highly parallelizable, state-resilient, and can resume from checkpoints if interrupted.
3. A continuous, non-interruptible inventory sync process that monitors external warehouse API streams, requiring a steady $8\text{ vCPUs}$ and $32\text{ GB}$ of RAM.

The database tier utilizes a production Amazon Aurora PostgreSQL cluster that runs continuously with a predictable database load. The route-recalculation process also downloads terabytes of historical logs from Amazon S3 and writes results to Aurora.

Which architecture and purchasing strategy provides the most cost-optimized compute and data transfer solution while meeting all workload SLAs?

Implement ECS Fargate with a Compute Savings Plan sized to cover the combined baseline of the dispatch coordination engine and the inventory sync process. Execute the route-recalculation batch tasks using the ECS Fargate Spot capacity provider, establish an Amazon S3 Gateway VPC Endpoint to bypass NAT Gateway data transfer charges, and purchase Aurora Reserved DB Instances for the database cluster.

Purchase a Compute Savings Plan with a commitment level sized to cover the dispatch coordination engine, the inventory sync process, and the Amazon Aurora PostgreSQL database instance hours. Deploy the route-recalculation batch tasks on ECS Fargate Spot, and route all S3 traffic through a NAT Gateway for secure internal data transfer.

Migrate the 24/7 dispatch coordination engine and continuous inventory sync process to AWS Lambda functions to eliminate idle compute charges. Run the route-recalculation batch tasks on ECS Fargate Spot, and purchase an EC2 Instance Savings Plan to cover the Lambda execution costs.

Implement ECS Fargate with a Compute Savings Plan to cover the dispatch coordination engine and the inventory sync process. Execute the route-recalculation batch tasks using the ECS Fargate Spot capacity provider. Route all S3 logging traffic through a NAT Gateway, and purchase Aurora Reserved DB Instances.

Show answer & explanation

Answer: Implement ECS Fargate with a Compute Savings Plan sized to cover the combined baseline of the dispatch coordination engine and the inventory sync process. Execute the route-recalculation batch tasks using the ECS Fargate Spot capacity provider, establish an Amazon S3 Gateway VPC Endpoint to bypass NAT Gateway data transfer charges, and purchase Aurora Reserved DB Instances for the database cluster.

Answer

The correct option combines the most cost-effective AWS compute purchasing strategies with network data transfer optimization. The predictable, 24/7 ECS Fargate tasks are covered by a Compute Savings Plan. The daily, interruptible batch workloads are executed using ECS Fargate Spot to leverage maximum discounts. Amazon Aurora PostgreSQL database instances are covered by Aurora Reserved DB Instances because Compute Savings Plans do not apply to database services. Lastly, an Amazon S3 Gateway VPC Endpoint is configured to eliminate costly NAT Gateway data transfer charges for historical logs transferred to and from S3.

Step-by-Step Solution

Analyze the baseline 24/7 compute requirements for the core dispatch engine and inventory sync processes.

Identify a predictable, continuous baseline compute footprint of

24\text{ vCPUs}

(

16 + 8

) and

96\text{ GB}

of RAM (

64 + 32

Establishing the steady-state baseline is necessary to determine the commitment level for a Savings Plan.

Select the appropriate AWS compute purchasing models for the continuous and batch workloads.

Choose a Compute Savings Plan for the baseline

24/7

ECS Fargate tasks to receive discounts of up to

66\%

. Choose the ECS Fargate Spot capacity provider for the daily, 8-hour batch route-recalculation process since it is parallelizable, state-resilient, and can tolerate interruptions for up to a

70\%

discount.

Applying the correct purchasing strategy matches workload characteristics (non-interruptible vs interruptible) to maximize savings.

Select the purchasing model for the Amazon Aurora database tier.

Choose Amazon Aurora Reserved DB Instances to reduce the database costs.

Compute Savings Plans only cover EC2, Fargate, and Lambda; they do not apply to Amazon Aurora or RDS databases.

Identify the most cost-effective routing for transferring terabytes of historical logs between the ECS tasks and Amazon S3.

Configure a Gateway VPC Endpoint for Amazon S3 in the VPC routing tables.

S3 Gateway Endpoints are free and prevent high NAT Gateway data processing charges for traffic destined to S3.

Key Concept

Selecting cost-effective compute purchasing models (Compute Savings Plans, Spot, Reserved Instances) and optimizing VPC network data transfer costs for Amazon S3.

Question 672Question →

A retail company is launching a new online inventory tracking application. The application will use an Amazon RDS for MySQL database. The database must be highly available and support automatic failover to a standby instance in another Availability Zone within the same Region in the event of an outage. Which database configuration should the solutions architect choose to meet these requirements?

Create an Amazon RDS read replica in a different Availability Zone and configure it as the automatic failover target.

Configure Route 53 latency routing to automatically redirect database write traffic to an Amazon RDS read replica in another Availability Zone.

Configure the Amazon RDS DB instance as a Multi-AZ deployment.

Configure a pilot light disaster recovery strategy by keeping a stopped DB instance in another Availability Zone to achieve zero-second failover.

Show answer & explanation

Answer: Configure the Amazon RDS DB instance as a Multi-AZ deployment.

Answer

Configure the Amazon RDS DB instance as a Multi-AZ deployment.

Configuring the Amazon RDS DB instance as a Multi-AZ deployment is correct because it automatically provisions and maintains a synchronous standby replica in a different Availability Zone. If the primary instance fails, AWS automatically switches to the standby replica, providing high availability and automatic failover with minimal disruption and no manual intervention.

Step-by-Step Solution

Analyze the requirements for high availability and automatic failover within the same AWS Region with minimal administrative effort.

Identify that the solution must provide synchronous replication and automated failover capabilities without requiring manual promotion or custom failover scripts.

This establishes the baseline criteria for evaluating AWS database configurations.

Evaluate Amazon RDS Multi-AZ deployments against the requirements.

Confirm that Multi-AZ deployments provide automatic failover to a synchronous standby instance in a different Availability Zone during an outage.

This configuration directly satisfies the high availability and automatic failover requirements with zero administrative overhead.

Assess alternative options like read replicas and Route 53 routing.

Determine that read replicas require manual intervention to promote them to primary, and Route 53 routing policies cannot perform database-level failovers.

This eliminates incorrect configurations that fail to provide automatic failover.

Key Concept

Amazon RDS Multi-AZ deployments provide high availability and automatic failover by synchronously replicating data to a standby instance in a different Availability Zone.

Question 673Question →

A startup is deploying a web application across a fleet of Amazon EC2 Linux instances that scale dynamically. The application requires a shared directory to store and retrieve user-uploaded profile pictures. This storage solution must support standard file system operations, scale capacity automatically as the data grows, and allow concurrent read/write access from all running instances. Which storage service should a solutions architect recommend to meet these requirements?

Amazon Elastic File System (Amazon EFS)

Amazon Elastic Block Store (Amazon EBS) gp3 volume

Amazon Elastic Block Store (Amazon EBS) io2 volume

Amazon S3 Glacier Flexible Retrieval

Show answer & explanation

Answer: Amazon Elastic File System (Amazon EFS)

Answer

Amazon Elastic File System (Amazon EFS)

Amazon Elastic File System (Amazon EFS) is the correct choice because it is a fully managed file system designed to be shared concurrently by multiple EC2 instances using the NFS protocol, and it automatically scales storage capacity up or down as files are written or deleted.

Step-by-Step Solution

Analyze the application requirements.

The application requires shared, concurrent read/write access to a directory, standard file system operations (POSIX compliance), and automatic capacity scaling for a dynamic fleet of Linux EC2 instances.

Identifying these key parameters narrows down the choices between block, file, and object storage.

Evaluate the storage services against the requirements.

Amazon EFS fits because it is a managed file system that supports concurrent NFS access and auto-scaling. EBS volumes are block-level and generally attached to a single instance (or restricted by Multi-Attach limitations). S3 Glacier is an archive service with high latency.

Matching AWS storage service characteristics to the workload constraints ensures the selection of the correct service.

Key Concept

Shared file storage for EC2 instances using Amazon EFS

Question 674Question →

A financial technology company is setting up a hybrid network to replicate database transactions from its on-premises mainframes to a VPC in the $us-east-1$ Region. The replication throughput peaks at $2.5\text{ Gbps}$ , and all data must be encrypted in transit. The company wants to utilize their existing high-bandwidth internet connections rather than provisioning dedicated private lines. Which TWO configurations should a solutions architect implement to meet these requirements? (Choose two.)

Select all that apply

Create an AWS Transit Gateway and enable Equal-Cost Multi-Path (ECMP) routing support.

Establish multiple AWS Site-to-Site VPN connections terminating on the Transit Gateway, utilizing dynamic BGP routing.

Establish a single AWS Site-to-Site VPN connection to a Virtual Private Gateway (VGW) and enable multi-tunnel scaling.

Configure stateless Network ACLs on the VPC subnets to automatically track and permit the return traffic of the replication streams.

Implement Amazon Route 53 latency-based routing to dynamically failover and balance the replication traffic across different VPN endpoints.

Show answer & explanation

Answer: Create an AWS Transit Gateway and enable Equal-Cost Multi-Path (ECMP) routing support.; Establish multiple AWS Site-to-Site VPN connections terminating on the Transit Gateway, utilizing dynamic BGP routing.

Answer

The correct configurations are to create an AWS Transit Gateway with Equal-Cost Multi-Path (ECMP) routing support enabled, and to establish multiple AWS Site-to-Site VPN connections terminating on the Transit Gateway using dynamic BGP routing.

To achieve a secure, encrypted connection over the internet that exceeds the

1.25\text{ Gbps}

limit of a single VPN tunnel, you must deploy AWS Transit Gateway with Equal-Cost Multi-Path (ECMP) routing enabled. By establishing multiple Site-to-Site VPN connections to the Transit Gateway using dynamic BGP routing, AWS can balance the replication traffic across multiple active tunnels, scaling the aggregate throughput to meet the

2.5\text{ Gbps}

peak requirement.

Step-by-Step Solution

Analyze the throughput and encryption requirements.

The replication requires

2.5\text{ Gbps}

throughput with in-transit encryption over the internet.

This establishes the scale constraint, as a single standard AWS VPN tunnel provides only

1.25\text{ Gbps}

of bandwidth.

Determine the service required to aggregate multiple VPN tunnels.

Identify AWS Transit Gateway with ECMP enabled as the solution.

ECMP allows traffic to be balanced across multiple VPN tunnels, effectively scaling the bandwidth beyond the single-tunnel limit.

Select the appropriate routing and connection setup.

Configure multiple Site-to-Site VPN connections using dynamic BGP routing to the Transit Gateway.

Dynamic routing enables ECMP to distribute the traffic across the active paths, achieving the aggregate bandwidth needed for the peak workload.

Key Concept

Scaling VPN throughput using Transit Gateway and ECMP

Question 675Question →

An advertising technology company is designing a high-performing ingestion and analytics platform to process user interaction events from mobile devices globally. The platform receives a peak traffic rate of $120,000$ events per second, with each JSON event payload averaging $1.2\text{ KB}$ in size. The system must meet the following requirements:

* Deliver all raw events to Amazon S3 in Apache Parquet format for historical analytics, with a maximum acceptable delivery latency of 5 minutes.
* Index enriched events into Amazon OpenSearch Service for real-time dashboard analytics with sub-second latency.
* Scale dynamically or be pre-provisioned to handle sudden traffic spikes of up to $1.5$ times the peak traffic rate without throttling or data loss.

Which combination of steps should the solutions architect take to meet these requirements with the highest performance and reliability? (Select two.)

Select all that apply

Configure an Amazon Kinesis Data Stream in Provisioned mode with 220 shards to ingest the incoming event stream.

Configure Amazon Data Firehose to consume from the Kinesis Data Stream, buffer and convert the records to Apache Parquet format using an AWS Glue schema, and deliver them to Amazon S3; in parallel, configure an AWS Lambda function to consume from the same stream and write to Amazon OpenSearch Service.

Configure an Amazon Kinesis Data Stream in Provisioned mode with 120 shards to handle the peak write throughput of 144 MB/s.

Ingest the events into an Amazon SQS Standard queue to decouple the ingestion layer, and configure an AWS Lambda function to poll the queue and write events to Amazon OpenSearch Service in strict chronological order.

Direct the mobile devices to write events directly to Amazon Data Firehose, using its built-in data transformation with AWS Lambda to convert the data to Parquet before writing to both Amazon S3 and Amazon OpenSearch Service.

Show answer & explanation

Answer: Configure an Amazon Kinesis Data Stream in Provisioned mode with 220 shards to ingest the incoming event stream.; Configure Amazon Data Firehose to consume from the Kinesis Data Stream, buffer and convert the records to Apache Parquet format using an AWS Glue schema, and deliver them to Amazon S3; in parallel, configure an AWS Lambda function to consume from the same stream and write to Amazon OpenSearch Service.

Answer

The correct combination is to provision an Amazon Kinesis Data Stream with 220 shards to ingest the incoming event stream, and use Amazon Data Firehose in parallel with AWS Lambda as consumers of the stream to deliver data to Amazon S3 and Amazon OpenSearch Service respectively.

Provisioning 220 shards on the Amazon Kinesis Data Stream accommodates the

216\text{ MB/s}

throughput and

180,000

events/sec spike requirements. Connecting Amazon Data Firehose for S3 delivery and AWS Lambda for OpenSearch delivery in parallel allows the system to support different processing patterns: Firehose handles structured batch ingestion and conversion to Parquet, whereas Lambda achieves the sub-second response times required for OpenSearch dashboards.

Step-by-Step Solution

Calculate the peak and spike record rates and write throughput requirements.

Peak rate is

120,000

records/sec at

144\text{ MB/s}

(

120,000 \times 1.2\text{ KB}

). The spike rate (1.5x) is

180,000

records/sec at

216\text{ MB/s}

(

180,000 \times 1.2\text{ KB}

Sizing the ingestion layer requires calculating both the records per second and the MB/s payload size at the maximum expected spike rate.

Determine the required number of Kinesis Data Streams shards.

Each shard supports

1,000

records/sec or

1\text{ MB/s}

write throughput. To support

180,000

records/sec, we need at least

180

shards. To support

216\text{ MB/s}

throughput, we need at least

216

shards. We select the option with 220 shards.

Provisioning must meet the highest requirement from both records/sec and MB/s dimensions to prevent ingestion bottlenecks.

Choose the high-performing ingestion consumer architecture for multi-destination delivery.

Configure Amazon Data Firehose as a consumer to convert records to Parquet via AWS Glue and deliver to S3 within 5 minutes. Set up AWS Lambda to consume from the same stream and push directly to Amazon OpenSearch Service.

Firehose handles micro-batching and schema conversion to Parquet efficiently for S3, while AWS Lambda processes stream events immediately to achieve sub-second latency for OpenSearch.

Key Concept

Calculating Kinesis Data Streams shard capacity based on both records per second and payload throughput limits, and implementing parallel consumer patterns for diverging latency requirements.

Estimated Time:3m 0s

Question 676Question →

A global retail company is deploying a product catalog application. Mobile client devices query a REST API hosted on Amazon API Gateway, which retrieves catalog data from a backend Amazon DynamoDB table. Users frequently query the same popular product categories, resulting in repeated read operations on DynamoDB that threaten to exceed the read capacity during flash sales. Additionally, static product images are stored in an Amazon S3 bucket and suffer from high retrieval latencies in remote regions. Which combination of architectural modifications will provide the lowest latency for users and optimize database performance under peak loads? (Select TWO.)

Select all that apply

Enable Amazon API Gateway caching for the catalog search API stages to cache responses and reduce the read load on the backend Amazon DynamoDB table.

Deploy an Amazon CloudFront distribution with the Amazon S3 bucket configured as the origin to cache and serve static product images from edge locations closer to users.

Configure the CloudFront distribution's cache behavior for static images with a Minimum TTL, Maximum TTL, and Default TTL of 0 seconds to ensure clients always retrieve the latest image versions from the S3 bucket.

Provision a DynamoDB Accelerator (DAX) cluster in a private subnet, and configure the API Gateway integration to route all query traffic to the DAX cluster through a NAT Gateway.

Switch the DynamoDB table to Provisioned Capacity Mode and set the Read Capacity Units (RCUs) to a high static limit to handle the unpredictable search traffic spikes.

Show answer & explanation

Answer: Enable Amazon API Gateway caching for the catalog search API stages to cache responses and reduce the read load on the backend Amazon DynamoDB table.; Deploy an Amazon CloudFront distribution with the Amazon S3 bucket configured as the origin to cache and serve static product images from edge locations closer to users.

Answer

Enable Amazon API Gateway caching for the catalog search API stages, and deploy an Amazon CloudFront distribution with the Amazon S3 bucket configured as the origin.

To optimize the application for performance and cost under peak load, a multi-tiered caching approach is required. Enabling Amazon API Gateway caching at the API stage level reduces read requests to Amazon DynamoDB by returning cached responses for identical queries. Simultaneously, deploying an Amazon CloudFront distribution with the Amazon S3 bucket as the origin caches static product images at edge locations globally, which minimizes retrieval latency for remote users and protects the S3 bucket from request overload.

Step-by-Step Solution

Analyze the workload characteristics for dynamic catalog queries.

Identify that many searches target the same popular product categories, suggesting that caching at the API layer will drastically reduce database read operations.

This offloads read traffic from Amazon DynamoDB and reduces API response times.

Address static asset delivery latency.

Determine that static product images stored in S3 should be cached closer to global users.

Deploying Amazon CloudFront provides global caching at edge locations to minimize latency.

Evaluate the proposed caching modifications for dynamic and static content.

Confirm that combining API Gateway caching and S3-backed CloudFront distribution satisfies both performance and database offloading requirements.

This combination addresses both dynamic API queries and static image delivery.

Key Concept

Multi-tier caching configurations to optimize read latency and origin database load.

Estimated Time:3m 0s

Question 677Question →

A company needs to collect streaming application logs, convert the data from JSON format to Apache Parquet format, and deliver the final files to Amazon S3. The company requires a serverless ingestion solution that minimizes operational and maintenance overhead. Which AWS service should the solutions architect recommend to meet these requirements?

Amazon Data Firehose

Amazon Kinesis Data Streams

Amazon SQS Standard Queue

AWS Glue ETL Jobs

Show answer & explanation

Answer: Amazon Data Firehose

Answer

Amazon Data Firehose

The correct answer is Amazon Data Firehose. It is a serverless, zero-administration service designed to ingest streaming data and deliver it to destinations like Amazon S3. It natively supports data transformation, allowing the automatic conversion of JSON records to Apache Parquet format using an AWS Glue schema before writing the files to the target S3 bucket, minimizing operational and management overhead.

Step-by-Step Solution

Analyze the requirements for data ingestion, format transformation, and destination storage.

The requirements demand a service that ingests streaming JSON log data, converts it to Apache Parquet, and writes it directly to Amazon S3.

This establishes the necessary feature set for the target service.

Evaluate the operational overhead constraints of the proposed architecture.

A serverless solution with minimal management is required, meaning services requiring manual shard scaling or custom consumer code must be avoided.

Operational simplicity is a key differentiator in the AWS Certified Solutions Architect exam.

Select the service that natively supports the pipeline with the least overhead.

Amazon Data Firehose natively supports serverless data ingestion, built-in format conversion using AWS Glue schema, and direct integration with Amazon S3.

This fulfills all requirements with minimal administrative effort.

Key Concept

Fully managed, serverless stream delivery and format conversion with Amazon Data Firehose

Estimated Time:45s

Question 678Question →

A financial services company is migrating a legacy SQL-based clustered database to Amazon EC2. The database cluster requires a shared block storage volume that can be concurrently mounted by up to $8$ Nitro-based EC2 instances in a single Availability Zone. The storage must support clustered file system protocols, require SCSI-3 persistent reservations for node fencing, and deliver consistent sub-millisecond latency. Which storage solution will meet these requirements with the highest performance?

Provision an Amazon EBS io2 volume, enable EBS Multi-Attach, and mount the volume across the EC2 database instances.

Provision an Amazon EBS gp3 volume, enable EBS Multi-Attach, and mount the volume across the EC2 database instances.

Create an Amazon EFS file system configured with Provisioned Throughput and Max I/O performance mode, and mount it on the EC2 instances.

Create an Amazon FSx for Lustre file system using SSD storage, and mount it concurrently using the Lustre client on all EC2 instances.

Show answer & explanation

Answer: Provision an Amazon EBS io2 volume, enable EBS Multi-Attach, and mount the volume across the EC2 database instances.

Answer

Provision an Amazon EBS io2 volume, enable EBS Multi-Attach, and mount the volume across the EC2 database instances.

The correct option is correct because Amazon EBS Multi-Attach enables attaching a single Provisioned IOPS SSD (io1 or io2) volume to up to

16

Nitro-based EC2 instances in the same Availability Zone. Furthermore, io2 volumes natively support SCSI-3 persistent reservations, which are a prerequisite for clustered database deployments requiring node fencing, while offering consistent sub-millisecond latency.

Step-by-Step Solution

Analyze the workload requirements for block vs. file storage.

The clustered database requires a shared block storage volume supporting SCSI-3 persistent reservations for node fencing, ruling out file-level solutions like Amazon EFS and Amazon FSx for Lustre.

Clustered databases require low-level block storage protocols to manage disk access and locking directly.

Identify the EBS volume types that support concurrent attachments (Multi-Attach).

Only Provisioned IOPS SSD volumes (io1 and io2) support EBS Multi-Attach.

General Purpose SSD volumes (gp3) do not have the architectural support for Multi-Attach.

Verify compliance with latency and protocol constraints.

Amazon EBS io2 volumes deliver sub-millisecond latencies, support SCSI-3 persistent reservations, and can be attached to up to

16

Nitro-based EC2 instances within a single Availability Zone.

This matches all criteria: block storage, Multi-Attach on Nitro, SCSI-3 PR support, and high performance.

Key Concept

Amazon EBS Multi-Attach with SCSI-3 Persistent Reservations on io2 Volumes

Question 679Question →

An organization runs a content management system (CMS) on a cluster of Amazon EC2 instances distributed across three Availability Zones. The CMS requires a shared storage solution that supports POSIX-compliant file system operations, allows concurrent read-and-write access from all instances, and automatically scales throughput as storage needs grow. Which two AWS storage configurations should a solutions architect select to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon Elastic File System (Amazon EFS) file system.

Configure EFS mount targets in the subnets of each Availability Zone where the EC2 instances are running.

Provision an Amazon EBS gp3 volume and enable the Multi-Attach feature to share it across the EC2 instances.

Deploy an Amazon EBS io2 Block Express volume and attach it to all EC2 instances across the three Availability Zones.

Create an Amazon S3 bucket and use AWS Storage Gateway Volume Gateway in cached mode to mount the storage locally on the instances.

Show answer & explanation

Answer: Create an Amazon Elastic File System (Amazon EFS) file system.; Configure EFS mount targets in the subnets of each Availability Zone where the EC2 instances are running.

Answer

Create an Amazon Elastic File System (Amazon EFS) file system and configure EFS mount targets in the subnets of each Availability Zone where the EC2 instances are running.

The correct architecture uses Amazon EFS, which provides a serverless network file system that supports simultaneous connections from EC2 instances in multiple Availability Zones. By placing EFS mount targets in the subnets of each Availability Zone where the instances reside, those instances can concurrently mount the file system over the network using standard NFS protocols.

Step-by-Step Solution

Identify the storage access requirements.

The workload requires concurrent read-and-write access to a shared file system (POSIX-compliant) from instances spanning three Availability Zones.

Since Amazon EBS volumes are restricted to a single Availability Zone, a shared file system solution like Amazon EFS is needed.

Select the appropriate storage service.

Choose Amazon EFS, which is designed for shared, scalable, POSIX-compliant network file system (NFS) access.

Amazon EFS natively supports multi-AZ mounting and dynamically scales throughput and capacity.

Configure network connectivity for the file system.

Create EFS mount targets in the subnets of each Availability Zone containing the EC2 instances.

Instances mount the EFS file system using the local mount target IP address in their respective Availability Zones.

Key Concept

Amazon EFS provides concurrent, POSIX-compliant shared file storage across multiple Availability Zones via Mount Targets.

Estimated Time:50s

Question 680Question →

A healthcare software provider is deploying a patient management portal on AWS. The relational database backend must remain highly available even if an entire Availability Zone (AZ) suffers an outage. The database configuration must support a Recovery Point Objective ( $\text{RPO}$ ) of $0$ (zero data loss) and a Recovery Time Objective ( $\text{RTO}$ ) of less than $35$ seconds. Furthermore, the portal experiences frequent read-heavy spikes, requiring the ability to serve read queries directly from standby database nodes within the cluster to optimize performance. Which database architecture should a solutions architect recommend to meet these requirements?

Deploy two independent Single-AZ Amazon RDS DB instances in different Availability Zones, and configure Amazon Route 53 latency routing to distribute traffic between them.

Deploy an Amazon RDS Multi-AZ DB cluster with one primary writer instance and two readable standby instances across three Availability Zones.

Deploy a Single-AZ Amazon RDS DB instance and create two Read Replicas in different Availability Zones, configuring the application to promote a Read Replica to primary during a failure.

Configure a Pilot Light disaster recovery strategy by maintaining a scaled-down Amazon RDS instance in a secondary Availability Zone and restoring data from daily backups during an outage.

Show answer & explanation

Answer: Deploy an Amazon RDS Multi-AZ DB cluster with one primary writer instance and two readable standby instances across three Availability Zones.

Answer

Deploying an Amazon RDS Multi-AZ DB cluster with one primary writer instance and two readable standby instances across three Availability Zones is the correct configuration.

Deploying an Amazon RDS Multi-AZ DB cluster provides synchronous replication across three Availability Zones (ensuring RPO = 0) and automated failover that typically completes in under 35 seconds (meeting the RTO requirement). Crucially, unlike standard Multi-AZ DB instance deployments, the standby instances in a Multi-AZ DB cluster are readable, allowing the application to offload read traffic directly to them.

Step-by-Step Solution

Evaluate the Recovery Point Objective (RPO) requirement.

To achieve an RPO of 0 (zero data loss), the database must use synchronous replication across Availability Zones.

Asynchronous replication mechanisms, such as standard RDS Read Replicas, can lead to data loss during failover.

Evaluate the Recovery Time Objective (RTO) and read-scaling requirements.

The database must support automatic failover in under 35 seconds and allow read queries to be served from standby nodes.

Standard Multi-AZ DB instance deployments do not support read queries on the standby instance. Multi-AZ DB clusters provide both automatic failover (typically under 35 seconds) and readable standby instances.

Select the configuration that satisfies all conditions.

An Amazon RDS Multi-AZ DB cluster meets all RPO, RTO, and read-scaling requirements.

It deploys one writer and two readable standby DB instances across three AZs with synchronous replication and automated failover.

Key Concept

Amazon RDS Multi-AZ DB clusters provide synchronous replication, fast automated failover, and active readable standby instances for scaling read traffic.

Estimated Time:1m 30s

PreviousPage 34 / 74Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Alternative Method

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution