All practice questions

1462 questions

All types1,462 Multiple choice739 Multiple select723

An e-commerce company stores transaction files in an Amazon S3 bucket using two prefixes: `invoices/` and `checkout_logs/`.

* Invoices (`invoices/`): PDF invoices with an average size of $2.5\text{ MB}$ . They are frequently accessed during the first $30$ days, occasionally accessed between days $30$ and $90$ , and must be retained for $7$ years for tax compliance.
* Checkout Logs (`checkout_logs/`): Text files with an average size of $15\text{ KB}$ . They are used for troubleshooting failed checkouts, frequently accessed during the first $10$ days, and are no longer needed after $25$ days.

Which combination of lifecycle rules meets these requirements most cost-effectively?

For the `invoices/` prefix, transition objects to S3 Standard-IA after

30

days, and transition them to S3 Glacier Deep Archive after

90

days. For the `checkout_logs/` prefix, expire objects after

25

days.

For the `invoices/` prefix, transition objects to S3 Standard-IA after

30

days, and transition them to S3 Glacier Deep Archive after

90

days. For the `checkout_logs/` prefix, transition objects to S3 Standard-IA after

10

days, and expire them after

25

days.

For the `invoices/` prefix, transition objects to S3 Glacier Deep Archive after

30

days. For the `checkout_logs/` prefix, transition objects to S3 Standard-IA after

10

days, and expire them after

25

days.

For the `invoices/` prefix, transition objects to S3 Standard-IA after

30

days, and transition them to S3 Glacier Deep Archive after

90

days. For the `checkout_logs/` prefix, transition objects to S3 Standard-IA after

10

days, and transition them to S3 Glacier Deep Archive after

25

days.

Show answer & explanation

Answer: For the `invoices/` prefix, transition objects to S3 Standard-IA after $30$ days, and transition them to S3 Glacier Deep Archive after $90$ days. For the `checkout_logs/` prefix, expire objects after $25$ days.

Answer

Configure a lifecycle policy that transitions Customer Invoice PDFs (`invoices/`) to S3 Standard-IA after

30

days and to S3 Glacier Deep Archive after

90

days, while expiring Temporary Checkout Session Logs (`checkout_logs/`) after

25

days without transitioning them.

The correct option is to transition the larger invoices (

2.5\text{ MB}

) to S3 Standard-IA after

30

days and to S3 Glacier Deep Archive after

90

days, while simply expiring the checkout logs (

15\text{ KB}

) after

25

days. This is cost-effective because the invoices exceed the

128\text{ KB}

minimum size requirement for infrequent and archive tiers and are kept long-term. Meanwhile, the checkout logs are too small and are deleted before the

30

-day minimum storage duration of S3 Standard-IA, meaning transition would result in minimum storage and capacity charge penalties.

Step-by-Step Solution

Analyze the access pattern and size of the invoice PDFs.

The PDFs are

2.5\text{ MB}

(greater than the

128\text{ KB}

S3 Standard-IA minimum capacity limit) and are only occasionally accessed after

30

days and rarely after

90

days. They must be kept for

7

years.

This justifies transitioning them to S3 Standard-IA after

30

days and to S3 Glacier Deep Archive after

90

days to minimize storage costs over the

7

-year retention period.

Analyze the access pattern, size, and lifespan of the checkout logs.

The logs are

15\text{ KB}

(well below the

128\text{ KB}

S3 Standard-IA minimum capacity limit) and must be deleted after

25

days.

Transitioning these logs to S3 Standard-IA or any archive tier is inefficient because they do not meet the minimum object size (

128\text{ KB}

) and will trigger a minimum storage duration penalty (

30

days for S3 Standard-IA) since they are deleted before that period.

Select the lifecycle policy that optimizes costs for both data sets.

Invoice PDFs are transitioned through Standard-IA to Glacier Deep Archive, while checkout logs are kept in S3 Standard and deleted at

25

days.

This avoids unnecessary storage penalties and capacity surcharges for the small, short-lived logs, while maximizing cost savings for the large, long-lived invoice files.

Key Concept

S3 Lifecycle policies must account for object size minimums (such as

128\text{ KB}

for S3 Standard-IA) and minimum storage durations (such as

30

days for S3 Standard-IA and

180

days for S3 Glacier Deep Archive) to avoid cost penalties.

Question 962Question →

A media company is deploying a distributed video rendering application on Amazon EC2 instances. The rendering nodes use Message Passing Interface (MPI) to coordinate tightly coupled computations and require the lowest possible latency and maximum throughput for node-to-node communications. The rendering tasks are distributed by a job manager through a Network Load Balancer (NLB) listening on port $443$ , while the rendering software on each instance listens on port $8085$ .

Which combination of configurations must a solutions architect implement to achieve optimal performance and ensure the instances are correctly registered as healthy by the NLB? (Select $2$ options.)

Select all that apply

Deploy the compute instances inside a cluster placement group to achieve low-latency node-to-node networking.

Specify port

8085

as the health check port in the target group configuration for the NLB.

Organize the compute instances within a spread placement group to distribute the rendering workload across separate physical racks.

Set up the target group health checks to default to the traffic port so that the NLB verifies instance health on port

443

Deploy the compute instances across a partition placement group to isolate the render nodes into distinct logical groups.

Show answer & explanation

Answer: Deploy the compute instances inside a cluster placement group to achieve low-latency node-to-node networking.; Specify port $8085$ as the health check port in the target group configuration for the NLB.

Answer

Deploy the compute instances inside a cluster placement group and specify port

8085

as the health check port in the target group configuration for the NLB.

The correct options implement a cluster placement group for low-latency node-to-node MPI communication and configure the NLB health checks on port

8085

where the rendering software is actively listening. Together, these ensure both high performance and correct target health registration.

Step-by-Step Solution

Analyze inter-node communication requirements.

The workload uses MPI, which is tightly coupled and requires the lowest possible inter-node latency.

This requirement points directly to a cluster placement group.

Select the correct placement group configuration.

A cluster placement group is chosen because it logically groups instances within a single Availability Zone, enabling high-performance networking.

Spread and partition placement groups introduce physical separation, which increases network latency.

Analyze the load balancer health check configuration.

The target group must query the port where the rendering application is actually listening (

8085

If the health check is left to default to the traffic port (

443

), the NLB will fail to connect to the render engine and falsely report the instances as unhealthy.

Key Concept

Selecting high-performance EC2 placement groups and aligning load balancer health check ports with backend services.

Question 963Question →

A logistics company is designing a new package tracking system on AWS. The application consists of a microservices-based API layer hosted on AWS Fargate that handles consistent, steady-state transaction volume $24/7$ , and a relational database layer running on Amazon RDS for PostgreSQL that operates continuously to store tracking history. Additionally, an hourly background job aggregates tracking metrics, running continuously for $50$ minutes of every hour. The company wants to minimize compute costs for this architecture while maintaining high availability and performance. Which TWO purchasing strategies or configurations should a solutions architect recommend? (Select two.)

Select all that apply

Purchase a Compute Savings Plan to cover the AWS Fargate API layer.

Purchase Amazon RDS Reserved Instances to cover the PostgreSQL database.

Increase the Compute Savings Plan commitment size to cover both the Fargate API layer and the Amazon RDS database instances.

Migrate the

50

-minute hourly background job to AWS Lambda functions to eliminate idle compute costs.

Migrate the tracking history database to Amazon DynamoDB configured with Provisioned Capacity Mode to handle highly unpredictable, spiky query volumes.

Show answer & explanation

Answer: Purchase a Compute Savings Plan to cover the AWS Fargate API layer.; Purchase Amazon RDS Reserved Instances to cover the PostgreSQL database.

Answer

Purchase a Compute Savings Plan to cover the AWS Fargate API layer, and purchase Amazon RDS Reserved Instances to cover the PostgreSQL database.

Purchasing a Compute Savings Plan is the most cost-effective option for the Fargate API layer because it offers discounts up to

66\%

on EC2, Fargate, and Lambda for a

1

- or

3

-year commitment. Since Compute Savings Plans do not cover Amazon RDS, purchasing RDS Reserved Instances is the correct and separate method to optimize costs for the database layer.

Step-by-Step Solution

Analyze the steady-state API layer hosted on AWS Fargate.

Determine that Compute Savings Plans apply directly to AWS Fargate, providing flexible discounts for steady-state container workloads.

Fargate is a supported compute type under Compute Savings Plans.

Analyze the database layer hosted on Amazon RDS.

Identify that Amazon RDS Reserved Instances are the appropriate vehicle for discounting continuous database workloads, since Compute Savings Plans do not apply to RDS.

Compute Savings Plans are restricted to EC2, Fargate, and Lambda.

Evaluate the

50

-minute hourly background job.

Keep the job on Fargate or EC2 rather than migrating to AWS Lambda.

AWS Lambda's maximum execution duration of

15

minutes prevents it from running a

50

-minute job, and continuous execution on Lambda is cost-prohibitive.

Key Concept

Selecting cost-optimized compute options by matching workloads to appropriate purchasing plans (Compute Savings Plans for Fargate, RDS Reserved Instances for databases) and avoiding platform limitations (Lambda timeout limits).

Question 964Question →

A logistics company is designing an automated package routing application on AWS. The application receives manifest data from regional hubs, which must be processed sequentially based on arrival time to maintain an accurate package tracking ledger. The ingestion of these manifests is highly sporadic: the system experiences zero traffic for several consecutive hours, but experiences sudden spikes of up to 100 manifests within a few minutes. Each manifest takes between 12 to 14 minutes of CPU-intensive calculations to process, occasionally extending to 18 minutes for exceptionally large hubs. The solutions architect must design a highly available, serverless, and cost-optimized architecture that scales automatically and decouples manifest ingestion from processing. Which two options should the solutions architect select to satisfy these requirements?

Select all that apply

Deploy the processing application on Amazon Elastic Container Service (Amazon ECS) using AWS Fargate, and configure target tracking scaling based on the SQS queue depth.

Use an Amazon Simple Queue Service (Amazon SQS) FIFO queue to buffer incoming manifest data and maintain strict message ordering.

Deploy the processing application on AWS Lambda, configuring the functions to be triggered directly by the upload events.

Use an Amazon Simple Queue Service (Amazon SQS) Standard queue to decouple the components, and implement consumer-side logic to re-order the processed manifests.

Show answer & explanation

Answer: Deploy the processing application on Amazon Elastic Container Service (Amazon ECS) using AWS Fargate, and configure target tracking scaling based on the SQS queue depth.; Use an Amazon Simple Queue Service (Amazon SQS) FIFO queue to buffer incoming manifest data and maintain strict message ordering.

Answer

To design a cost-effective, ordered, and auto-scaling serverless architecture, the solutions architect should use an Amazon SQS FIFO queue to preserve manifest sequence, and deploy the processing workload on Amazon ECS with AWS Fargate, scaling the task count based on the SQS queue depth.

Using an Amazon SQS FIFO queue ensures that manifest data is processed in the exact order of arrival, preserving the integrity of the ledger. Deploying the workload on Amazon ECS with AWS Fargate provides a serverless compute platform that can run tasks indefinitely without the 15-minute timeout constraint of AWS Lambda. By using target tracking scaling based on the SQS queue depth, the application automatically provisions containers to handle traffic spikes and terminates all tasks when no messages remain, minimizing idle costs.

Step-by-Step Solution

Determine the appropriate messaging queue type to meet the ordering and decoupling requirements.

Select Amazon SQS FIFO queues.

The ledger requires messages to be processed sequentially based on arrival time. Amazon SQS FIFO queues guarantee first-in, first-out delivery and exactly-once processing.

Evaluate the compute options based on the execution duration, compute requirements, and cost-efficiency.

Select Amazon ECS with AWS Fargate instead of AWS Lambda.

The processing tasks run for 12 to 18 minutes. AWS Lambda has a hard timeout limit of 15 minutes, making it unsuitable. AWS Fargate has no such timeout, scales container instances dynamically, and is more cost-efficient for long-running compute-intensive tasks.

Configure the scaling mechanism for the compute layer to minimize idle costs.

Implement target tracking scaling based on queue depth.

By scaling the ECS Fargate tasks based on the number of visible messages in the SQS queue, the system can scale down to zero when the queue is empty, eliminating idle compute costs, and scale up rapidly to handle traffic spikes.

Key Concept

Serverless container orchestration and ordered message queue decoupling for long-running batch processing workloads.

Estimated Time:3m 0s

Question 965Question →

A smart manufacturing company collects and stores operational data in a single Amazon S3 bucket. The data consists of two categories:

* IoT Sensor Telemetry: Average file size is $8\text{ KB}$ . These files are generated continuously and analyzed in real-time. They are rarely accessed after $10\text{ days}$ but must be retained for a total of $25\text{ days}$ for compliance audits, after which they can be deleted.
* Machinery Firmware Images: Average file size is $20\text{ MB}$ . These files are accessed frequently during the first $30\text{ days}$ after release and rarely thereafter. They must be retained for $365\text{ days}$ for rollback purposes, after which they can be deleted.

Which lifecycle configuration is the most cost-effective to meet these requirements?

For telemetry data, create a lifecycle rule to expire objects after

25\text{ days}

. For firmware images, create a lifecycle rule to transition objects to S3 Standard-Infrequent Access (S3 Standard-IA) after

30\text{ days}

and expire them after

365\text{ days}

For telemetry data, create a lifecycle rule to transition objects to S3 Standard-IA after

10\text{ days}

and expire them after

25\text{ days}

. For firmware images, create a lifecycle rule to transition objects to S3 Standard-IA after

30\text{ days}

and expire them after

365\text{ days}

For telemetry data, create a lifecycle rule to expire objects after

25\text{ days}

. For firmware images, create a lifecycle rule to transition objects to S3 Standard-IA after

10\text{ days}

and expire them after

365\text{ days}

For telemetry data, create a lifecycle rule to transition objects to S3 Standard-IA after

20\text{ days}

and expire them after

25\text{ days}

. For firmware images, create a lifecycle rule to transition objects to S3 Standard-IA after

30\text{ days}

and expire them after

365\text{ days}

Show answer & explanation

Answer: For telemetry data, create a lifecycle rule to expire objects after $25\text{ days}$ . For firmware images, create a lifecycle rule to transition objects to S3 Standard-Infrequent Access (S3 Standard-IA) after $30\text{ days}$ and expire them after $365\text{ days}$ .

Answer

For telemetry data, configure a lifecycle rule to expire objects after

25\text{ days}

without transitioning them. For firmware images, configure a lifecycle rule to transition them to S3 Standard-IA after

30\text{ days}

and expire them after

365\text{ days}

The correct configuration leaves telemetry files in S3 Standard for the duration of their lifecycle (

25\text{ days}

) and expires them directly. This avoids both the

128\text{ KB}

minimum billing size penalty (since their actual size is

8\text{ KB}

) and the

30\text{-day}

minimum storage duration penalty of S3 Standard-IA. The firmware images are large (

20\text{ MB}

) and reside in S3 Standard-IA for

335\text{ days}

after the initial

30\text{ days}

of frequent access, maximizing storage savings with zero penalties.

Step-by-Step Solution

Analyze the telemetry data properties and constraints.

The telemetry files are very small (

8\text{ KB}

) and are kept for only

25\text{ days}

before deletion.

We must evaluate if transitioning them to S3 Standard-IA is cost-effective. Since the files are less than the

128\text{ KB}

minimum storage size limit of S3 Standard-IA and are kept in that tier for only

15\text{ days}

(violating the

30\text{-day}

minimum storage duration), they should remain in S3 Standard.

Analyze the firmware images properties and constraints.

The firmware files are large (

20\text{ MB}

) and are kept for

365\text{ days}

. They are frequently accessed only during the first

30\text{ days}

of release.

Transitioning them to S3 Standard-IA after

30\text{ days}

is highly cost-effective because the file size exceeds

128\text{ KB}

, and the remaining storage duration (

335\text{ days}

) comfortably exceeds the

30\text{-day}

minimum requirement.

Combine the rules into a single lifecycle configuration.

Prefix-based rules: `telemetry/` expires after

25\text{ days}

; `firmware/` transitions to S3 Standard-IA after

30\text{ days}

and expires after

365\text{ days}

Using prefix-based rules allows separate lifecycle paths for different types of data in the same bucket.

Key Concept

S3 Lifecycle Management Cost Constraints

Question 966Question →

A company runs a data processing application on Amazon EC2. Due to occasional application deployment defects, the instances sometimes fail to terminate and run indefinitely, resulting in unexpected cost spikes. The operations team needs a solution to detect these anomalous spend patterns dynamically within 24 hours of occurrence without manually setting fixed threshold limits, as workload demands vary seasonally. Which solution will meet these requirements with the least operational overhead?

Configure AWS Cost Explorer to generate daily reports on usage cost variations, and set up an Amazon Simple Notification Service (Amazon SNS) topic to broadcast these reports.

Implement AWS Cost Anomaly Detection, create a monitor for AWS services, and configure an anomaly subscription with daily or immediate alerting to an Amazon Simple Notification Service (Amazon SNS) topic.

Create a CloudWatch billing alarm for the EstimatedCharges metric that triggers an Amazon Simple Notification Service (Amazon SNS) alert when charges exceed a statically defined monthly threshold.

Set up an AWS Budget to monitor Amazon RDS database costs, and configure a budget action to automatically purchase a Compute Savings Plan to mitigate any unexpected database spend spikes.

Show answer & explanation

Answer: Implement AWS Cost Anomaly Detection, create a monitor for AWS services, and configure an anomaly subscription with daily or immediate alerting to an Amazon Simple Notification Service (Amazon SNS) topic.

Answer

Implementing AWS Cost Anomaly Detection with a service monitor and an Amazon SNS subscription.

AWS Cost Anomaly Detection is a self-learning service that uses machine learning models to continuously monitor cost and usage, detect anomalies, and alert users. It does not require manual threshold definition, adjusts dynamically to seasonal variations, and can send alerts via Amazon SNS, fulfilling the requirements with minimal operational overhead.

Step-by-Step Solution

Analyze the requirement for dynamic, baseline-free anomaly detection.

Determine that static threshold-based alerting (like standard AWS Budgets or CloudWatch billing alarms) is unsuitable due to seasonal workload variations.

Fixed thresholds lead to false alarms during peak seasons or missed anomalies during low seasons.

Select the appropriate AWS cost management tool for proactive ML-driven detection.

Identify AWS Cost Anomaly Detection as the service that utilizes machine learning to continuously baseline and identify unexpected cost spikes.

It automates baseline adjustments and detects deviations without manual intervention.

Configure the notification mechanism for immediate alerts.

Configure an anomaly monitor with an Amazon Simple Notification Service (Amazon SNS) topic subscription.

This delivers proactive alerts to the operations team within 24 hours of anomaly detection.

Key Concept

AWS Cost Anomaly Detection provides proactive, machine learning-driven anomaly detection to identify cost anomalies with minimal latency, unlike retrospective analysis tools or static threshold budgets.

Question 967Question →

A financial technology organization uses AWS Organizations to manage a multi-account structure. The organization has recently deployed a new transaction processing platform across several member accounts. The platform writes transaction logs to an Amazon S3 bucket, which are processed and then permanently deleted after $3$ days. The platform's compute workloads are highly dynamic and exhibit natural cyclical scaling. The organization has the following requirements:

* Detect sudden, atypical spending spikes across all member accounts within $24$ hours without triggering false positives during regular cyclical scaling events.
* Provide a pro forma billing view to a subsidiary account that reflects a custom $15\%$ discount on all Amazon EC2 usage, without altering the actual consolidated invoice generated at the management account level.
* Send an immediate notification to the operations team if the actual monthly consolidated cost exceeds $110\%$ of the budgeted amount.
* Implement a cost-optimized storage strategy for the transaction logs.

Which combination of actions will meet these requirements in the most cost-effective and operationally efficient manner?

Configure AWS Cost Anomaly Detection with a cost monitor for all services. Create a billing group in AWS Billing Conductor for the subsidiary account, associate a custom pricing plan that applies a

15\%

discount flat rate to EC2, and share the pro forma billing data. Create a cost budget in AWS Budgets at the management account level with an alert threshold set at

110\%

of the budgeted amount based on actual costs. Create an S3 Lifecycle policy to transition the transaction logs to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) immediately upon creation.

Configure AWS Cost Anomaly Detection with a cost monitor for all services. Purchase a Compute Savings Plan in the subsidiary member account to apply the custom

15\%

discount on their EC2 instances and Amazon RDS databases, and configure AWS Billing Conductor to pass through these discounts. Create a cost budget in AWS Budgets at the management account level with an alert threshold set at

110\%

of the budgeted amount based on actual costs. Create an S3 Lifecycle policy to delete the transaction logs directly from S3 Standard after

3

days.

Configure AWS Cost Anomaly Detection with a cost monitor for all services. Create a billing group in AWS Billing Conductor for the subsidiary account, associate a custom pricing plan that applies a

15\%

discount flat rate to EC2, and share the pro forma billing data. Create a cost budget in AWS Budgets at the management account level with an alert threshold set at

110\%

of the budgeted amount based on actual costs. Create an S3 Lifecycle policy to delete the transaction logs directly from S3 Standard after

3

days.

Configure AWS Cost Explorer with daily scheduled reports to notify the operations team when consolidated actual costs exceed

110\%

of the budget. Create a billing group in AWS Billing Conductor for the subsidiary account, associate a custom pricing plan that applies a

15\%

discount flat rate to EC2, and share the pro forma billing data. Create a cost budget in AWS Budgets with a threshold set at

110\%

using forecasted costs. Create an S3 Lifecycle policy to delete the transaction logs directly from S3 Standard after

3

days.

Show answer & explanation

Answer: Configure AWS Cost Anomaly Detection with a cost monitor for all services. Create a billing group in AWS Billing Conductor for the subsidiary account, associate a custom pricing plan that applies a $15\%$ discount flat rate to EC2, and share the pro forma billing data. Create a cost budget in AWS Budgets at the management account level with an alert threshold set at $110\%$ of the budgeted amount based on actual costs. Create an S3 Lifecycle policy to delete the transaction logs directly from S3 Standard after $3$ days.

Answer

Configure AWS Cost Anomaly Detection to monitor services using machine learning. Use AWS Billing Conductor to set up a billing group and custom pricing plan with a

15\%

EC2 discount for the subsidiary account. Use AWS Budgets to alert on actual monthly costs exceeding

110\%

of budgeted amounts. Maintain transaction logs in S3 Standard and delete them after

3

days using S3 Lifecycle policies.

The correct solution correctly separates the concerns of cost alerting, custom pro forma billing, and storage optimization. First, AWS Cost Anomaly Detection is configured because its machine learning model baselines cost patterns and dynamically adapts to cyclical compute scaling, minimizing false positives. Second, AWS Billing Conductor is ideal for generating custom billing data (e.g., a

15\%

discount for the subsidiary) without modifying the consolidated payer account invoice. Third, AWS Budgets handles proactive threshold alerts based on actual monthly costs. Finally, S3 Standard is selected for logs with a

3

-day lifespan because S3 Standard-IA imposes a

30

-day minimum storage duration billing penalty.

Step-by-Step Solution

Evaluate S3 lifecycle and storage tiers for short-lived transaction logs.

Determine that S3 Standard is the most cost-effective tier and write an S3 Lifecycle policy to delete logs after

3

days.

Transitioning logs to S3 Standard-IA would trigger a

30

-day minimum storage billing charge penalty since the logs are deleted in only

3

days.

Select the appropriate service to monitor and alert on cost anomalies.

Configure AWS Cost Anomaly Detection with a cost monitor for all services.

Machine learning-based detection adapts to cyclical scaling to prevent false positives, while detecting spikes within

24

hours.

Configure custom billing views for the subsidiary account.

Define a billing group and custom pricing plan in AWS Billing Conductor to apply a

15\%

discount to EC2.

This allows the subsidiary to view pro forma costs with custom pricing without affecting the management account's consolidated invoicing.

Establish alerting for budget overruns.

Create a cost budget in AWS Budgets at the management account level.

AWS Budgets is required to monitor actual spend relative to a budget threshold (

110\%

) and send proactive alerts.

Key Concept

Selecting and configuring the correct AWS cost management tools based on proactive vs. reactive characteristics, ML anomaly detection limits, and pro forma billing requirements.

Estimated Time:3m 0s

Question 968Question →

A logistics company is designing a hybrid network architecture to connect its on-premises warehouse management system to a VPC in the `us-east-1` Region. The connection must support a continuous data sync throughput of $2\text{ Gbps}$ . To secure the database instances inside the VPC, the security team requires stateless traffic filtering at the subnet boundaries, ensuring that return traffic must be explicitly defined. Additionally, the company is deploying a backup application in the `us-west-2` Region and wants to route client requests to the secondary Region if the primary Region becomes unhealthy.

Which two options should the solutions architect select to satisfy these requirements?

Select all that apply

Configure an AWS Transit Gateway with Equal-Cost Multi-Path (ECMP) routing and establish multiple AWS Site-to-Site VPN connections.

Configure Network Access Control Lists (NACLs) at the subnet level to explicitly define rules for both inbound and outbound traffic.

Establish a single AWS Site-to-Site VPN connection directly to the VPC to handle the continuous throughput.

Configure stateful Security Groups at the subnet boundary to track and filter all incoming and outgoing database traffic.

Implement Amazon Route 53 Latency routing policy as the sole mechanism to failover client traffic during a regional outage.

Show answer & explanation

Answer: Configure an AWS Transit Gateway with Equal-Cost Multi-Path (ECMP) routing and establish multiple AWS Site-to-Site VPN connections.; Configure Network Access Control Lists (NACLs) at the subnet level to explicitly define rules for both inbound and outbound traffic.

Answer

Configure an AWS Transit Gateway with Equal-Cost Multi-Path (ECMP) routing and establish multiple AWS Site-to-Site VPN connections, and configure Network Access Control Lists (NACLs) at the subnet level to explicitly define rules for both inbound and outbound traffic.

To support

2\text{ Gbps}

of throughput, multiple VPN tunnels are required because a single tunnel caps out at

1.25\text{ Gbps}

. Enabling ECMP on the Transit Gateway allows traffic to be distributed across these multiple tunnels. Additionally, Network ACLs are the correct mechanism for subnet-level stateless traffic filtering because they require explicit rules for both inbound and outbound traffic.

Step-by-Step Solution

Analyze the bandwidth requirement.

The continuous data sync requires

2\text{ Gbps}

of throughput.

Since a single VPN tunnel is limited to

1.25\text{ Gbps}

, multiple VPN tunnels must be aggregated using AWS Transit Gateway and ECMP to scale past this limit.

Evaluate the security and filtering requirements.

Identify that subnet-boundary stateless traffic filtering requires Network ACLs.

Security Groups are stateful and operate at the instance level. Network ACLs operate at the subnet boundary and are stateless, requiring both inbound and outbound rules to be defined explicitly.

Address the disaster recovery routing requirement.

Discard using latency routing alone as a failover mechanism.

Route 53 Latency routing only directs traffic based on lowest network latency and does not monitor resource health or execute failovers without health check associations.

Key Concept

High-performing hybrid network scalability using AWS Transit Gateway and ECMP, combined with stateless subnet filtering via Network ACLs.

Question 969Question →

A software company is deploying a corporate training platform on AWS. The platform requires a backend service to process employee learning telemetry, which must run continuously $24$ hours a day, $7$ days a week ( $24/7$ ). Additionally, the platform stores user progress and quiz results in a database. This database experiences highly unpredictable, sharp spikes in traffic when training modules are assigned to large teams. The company wants to design a highly cost-optimized solution for both compute and database resources. Which combination of services and purchasing strategies will meet these requirements at the lowest cost?

Run the backend service on AWS Fargate covered by a

1

-year Compute Savings Plan, and use Amazon DynamoDB in on-demand capacity mode for the database.

Run the backend service on AWS Fargate covered by a

1

-year Compute Savings Plan, and use Amazon DynamoDB in provisioned capacity mode for the database.

Run the backend service on AWS Lambda, and use Amazon DynamoDB in on-demand capacity mode for the database.

Run the backend service on AWS Fargate, and use Amazon RDS for PostgreSQL for the database, covering both the Fargate tasks and the RDS instance under a single

1

-year Compute Savings Plan.

Show answer & explanation

Answer: Run the backend service on AWS Fargate covered by a $1$ -year Compute Savings Plan, and use Amazon DynamoDB in on-demand capacity mode for the database.

Answer

Run the backend service on AWS Fargate covered by a

1

-year Compute Savings Plan, and use Amazon DynamoDB in on-demand capacity mode for the database.

Running the backend service on AWS Fargate with a Compute Savings Plan provides significant cost savings for steady-state, continuous compute workloads. Utilizing Amazon DynamoDB in on-demand capacity mode is the most cost-effective database choice because it automatically handles sudden, unpredictable traffic spikes without manual intervention or the need to pay for idle provisioned capacity.

Step-by-Step Solution

Analyze the operational requirements of the backend compute layer.

Identify that a containerized backend running

24/7

is best suited for AWS Fargate, and a

1

-year Compute Savings Plan will offer the maximum discount for this steady-state workload.

Compute Savings Plans cover AWS Fargate and provide significant savings over On-Demand rates for continuous use.

Analyze the traffic pattern of the database layer.

Determine that Amazon DynamoDB with on-demand capacity mode is the best fit.

The database experiences sharp, unpredictable spikes. On-demand capacity mode automatically scales to handle these spikes instantly and avoids the costs of idle, provisioned capacity.

Evaluate the scope of the Compute Savings Plan across the selected services.

Confirm that the Compute Savings Plan applies to AWS Fargate but excludes Amazon RDS database instances.

Compute Savings Plans are restricted to EC2, Fargate, and Lambda, meaning they cannot be used to offset RDS costs.

Key Concept

Matching compute hosting models and purchasing strategies with workload patterns, and understanding the billing scopes of AWS Savings Plans and DynamoDB capacity modes.

Question 970Question →

A solutions architect is designing the database layer for a global gaming application. The application requires a relational database in the primary region (`us-east-1`) that can dynamically scale read capacity and achieve cross-region disaster recovery with a recovery point objective (RPO) of less than $1$ second and a recovery time objective (RTO) of less than $1$ minute in `us-west-2`. Additionally, the application has a leaderboard feature backed by Amazon DynamoDB that must store game session events. The events are ingested continuously, and each event payload contains a player ID, game session ID, and a precise UTC timestamp.

Which TWO strategies should the solutions architect implement to meet these performance and availability requirements? (Select TWO.)

Select all that apply

Deploy Amazon Aurora Global Databases with a primary cluster in `us-east-1` and a secondary cluster in `us-west-2`, utilizing storage-level physical replication.

Design the DynamoDB leaderboard table partition key as a combination of the player ID and game session ID, and use the timestamp as the sort key.

Deploy Amazon RDS for PostgreSQL with Multi-AZ in `us-east-1` and use a cross-region Read Replica in `us-west-2` as the automated, zero-data-loss failover target to meet the RTO and RPO limits.

Design the DynamoDB leaderboard table with a partition key based on the UTC timestamp to allow queries to easily scan and retrieve sorted chronological leaderboard data.

Configure the DynamoDB leaderboard table using Provisioned Capacity Mode with static Read Capacity Units (RCUs) and Write Capacity Units (WCUs) to optimize performance for unpredictable, highly spiky game event uploads.

Show answer & explanation

Answer: Deploy Amazon Aurora Global Databases with a primary cluster in `us-east-1` and a secondary cluster in `us-west-2`, utilizing storage-level physical replication.; Design the DynamoDB leaderboard table partition key as a combination of the player ID and game session ID, and use the timestamp as the sort key.

Answer

Deploy Amazon Aurora Global Databases with storage-level replication, and design the DynamoDB partition key as a combination of player ID and game session ID with timestamp as the sort key.

The correct strategy combines Amazon Aurora Global Databases and an optimal DynamoDB composite key structure. Aurora Global Databases use physical replication at the storage layer to achieve cross-region replica lag of less than

1

second and enable sub-minute recovery via regional promotion. For DynamoDB, combining high-cardinality attributes like player ID and session ID as the partition key ensures that write operations are distributed uniformly across partitions, avoiding write bottlenecks, while placing the timestamp as the sort key allows for efficient chronological queries.

Step-by-Step Solution

Analyze the relational database performance and replication requirements.

Identified the need for cross-region replication with RPO <

1

second and RTO <

1

minute, combined with dynamic read scaling.

Aurora Global Databases provide storage-based, physical replication that delivers sub-second RPO and rapid regional failover, meeting the RTO/RPO targets.

Analyze the DynamoDB write ingestion patterns and data key schema.

Identified that continuously ingested events with sequential timestamps can lead to partition bottlenecks (hot keys).

To prevent write hot spots on a single physical partition, a composite key with high cardinality (player ID + session ID) must be used as the partition key, placing the sequential timestamp as the sort key.

Evaluate and eliminate incorrect database options based on AWS limits and capabilities.

RDS Read Replicas do not support automatic cross-region failover, timestamps as partition keys create write bottlenecks, and static provisioned capacity cannot handle unpredictable spiky traffic.

Eliminating options that introduce performance bottlenecks or fail to meet the RPO/RTO requirements leaves the combination of Aurora Global Databases and proper DynamoDB composite key design as the correct strategies.

Key Concept

High-performing database replication and schema partition key design

Question 971Question →

A research institute hosts genomic sequencing workloads on AWS. The workloads generate two distinct datasets stored in a single Amazon S3 bucket:

* Raw sequencer outputs: Approximately $50,000$ files per month, with an average file size of $150\text{ MB}$ . These files are accessed frequently during the first $25$ days for analysis, after which they are rarely accessed but must be retained for $3$ years for regulatory compliance.
* Alignment index files: Approximately $20\text{ million}$ files per month, with an average file size of $5\text{ KB}$ . These files are accessed occasionally throughout the year to locate specific sequences, but they can be quickly regenerated from the raw outputs if needed, and must be kept for $1$ year.

Which combination of actions will provide the most cost-effective storage strategy for this data? (Select TWO.)

Select all that apply

Configure an S3 Lifecycle policy to transition the raw sequencer outputs to S3 Standard-IA after

30

days, and to S3 Glacier Deep Archive after

90

days.

Retain the alignment index files in S3 Standard and configure an S3 Lifecycle policy to delete them after

1

year.

Configure an S3 Lifecycle policy to transition the alignment index files to S3 Standard-IA after

30

days to lower storage costs.

Configure an S3 Lifecycle policy to transition the alignment index files to S3 Glacier Flexible Retrieval after

90

days.

Configure an S3 Lifecycle policy to transition the raw sequencer outputs to S3 Standard-IA after

10

days, and then to S3 Glacier Deep Archive after

25

days.

Show answer & explanation

Answer: Configure an S3 Lifecycle policy to transition the raw sequencer outputs to S3 Standard-IA after $30$ days, and to S3 Glacier Deep Archive after $90$ days.; Retain the alignment index files in S3 Standard and configure an S3 Lifecycle policy to delete them after $1$ year.

Answer

The correct combination of actions is to transition the raw sequencer outputs to S3 Standard-IA after

30

days and then to S3 Glacier Deep Archive after

90

days, while keeping the alignment index files in S3 Standard and deleting them after

1

year.

Transitioning the large raw sequencer outputs to S3 Standard-IA after

30

days and then to S3 Glacier Deep Archive after

90

days avoids retrieval charges during their

25

-day active access window and respects the

30

-day minimum storage duration for S3 Standard-IA. For the alignment index files, keeping them in S3 Standard and deleting them after

1

year is most cost-effective because their small size (

5\text{ KB}

) makes transitioning them to S3 Standard-IA or S3 Glacier highly expensive due to the

128\text{ KB}

minimum billing size.

Step-by-Step Solution

Analyze the size, access patterns, and retention requirements of the two datasets.

Raw sequencer outputs are large (

150\text{ MB}

), accessed for

25

days, and retained for

3

years. Alignment index files are small (

5\text{ KB}

), accessed occasionally for

1

year, and can be easily regenerated.

Understanding the unique profile of each dataset is necessary to determine which S3 storage classes and lifecycle rules are appropriate.

Evaluate the cost impact of transitioning the alignment index files to infrequent access or archival tiers.

Transitioning the

5\text{ KB}

alignment index files to S3 Standard-IA or S3 Glacier triggers the

128\text{ KB}

minimum billing size, magnifying the billed capacity by

25.6

times and raising costs. Therefore, they should remain in S3 Standard and be deleted after

1

year.

This avoids the minimum object size billing penalty inherent in S3 Standard-IA and S3 Glacier tiers.

Evaluate the cost impact of transition timelines for the raw sequencer outputs.

Transitioning raw sequencer outputs to S3 Standard-IA after

30

days avoids retrieval charges since active access ends at day

25

. Transitioning them to S3 Glacier Deep Archive after

90

days (spending

60

days in S3 Standard-IA) respects the

30

-day minimum storage duration of S3 Standard-IA.

This layout maximizes storage savings while avoiding early transition and active data retrieval penalties.

Key Concept

Selecting the most cost-effective S3 storage tier depends on object size and transition timing due to S3 Standard-IA/Glacier minimum billing sizes (

128\text{ KB}

) and minimum storage durations (

30

days for S3 Standard-IA).

Question 972Question →

A media startup is designing a processing pipeline to transcode high-resolution video uploads. Users upload videos of varying sizes to an Amazon S3 bucket. The transcoding process is compute-intensive, taking between 15 to 30 minutes per video, and the daily upload volume is highly unpredictable with long periods of zero activity. The processing order of the videos is not important. The startup wants a cost-effective, serverless architecture that scales dynamically to meet demand and incurs no compute costs when there are no video uploads. Which two solutions should the solutions architect recommend to meet these requirements in the most cost-effective manner? (Select TWO.)

Select all that apply

Use Amazon Elastic Container Service (Amazon ECS) with the AWS Fargate launch type to run the transcoding tasks.

Use Amazon Simple Queue Service (Amazon SQS) standard queues to hold the transcoding jobs, and scale the container tasks based on queue depth.

Create an AWS Lambda function triggered directly by Amazon S3 event notifications to perform the video transcoding.

Configure an Amazon SQS FIFO queue to manage the transcoding jobs to ensure that videos are processed in the exact order they are uploaded.

Store transcoding job states in Amazon DynamoDB configured with provisioned capacity mode to orchestrate the tasks.

Show answer & explanation

Answer: Use Amazon Elastic Container Service (Amazon ECS) with the AWS Fargate launch type to run the transcoding tasks.; Use Amazon Simple Queue Service (Amazon SQS) standard queues to hold the transcoding jobs, and scale the container tasks based on queue depth.

Answer

The correct solutions are to use Amazon ECS with the AWS Fargate launch type to run the transcoding tasks, and to use Amazon SQS standard queues to hold the transcoding jobs while scaling the container tasks based on the queue depth.

The correct approach combines Amazon SQS standard queues for decoupling and Amazon ECS on AWS Fargate for serverless container execution. Amazon SQS standard queues are cost-effective and scale automatically to absorb spikes in uploads, while allowing the container tasks to scale down to zero when the queue is empty. AWS Fargate is ideal here because the transcoding process takes 15 to 30 minutes, which exceeds the 15-minute maximum runtime limit of AWS Lambda. Fargate runs containers serverlessly, charging only for the resources consumed during the active transcoding duration and incurring zero cost when idle.

Step-by-Step Solution

Analyze the processing duration and compute requirements.

Identify that the transcoding tasks take 15 to 30 minutes, which exceeds the 15-minute execution limit of AWS Lambda.

Determining the execution duration prevents choosing serverless compute options that will timeout and fail.

Determine the most cost-effective serverless compute service that can run tasks longer than 15 minutes.

Select Amazon ECS with the AWS Fargate launch type.

AWS Fargate runs containers serverlessly, allows tasks to run up to 24 hours, and scales to zero when no tasks are running, ensuring no idle compute costs.

Select the queue type and integration to store jobs and trigger scaling.

Select an Amazon SQS standard queue to buffer jobs and use queue depth to scale ECS Fargate tasks.

SQS standard queues are cheaper than FIFO queues, scale virtually infinitely, and are appropriate since strict message ordering is not required.

Key Concept

Designing cost-optimized serverless architectures for long-running, unpredictable workloads by combining SQS standard queues and ECS Fargate scaling.

Question 973Question →

A financial analytics firm is deploying a machine learning training model on a fleet of Amazon EC2 instances located in a single Availability Zone. The application processes millions of training data files and requires consistent single-digit millisecond latency for frequent read and write operations. The storage solution must be accessible via standard object storage APIs. Which combination of actions should a solutions architect take to meet these performance requirements? (Select TWO.)

Select all that apply

Create an Amazon S3 Express One Zone directory bucket in the same Availability Zone as the EC2 instances.

Configure the application to make parallel, multi-threaded requests directly to the S3 directory bucket.

Deploy an Amazon EFS file system configured with Provisioned Throughput mode and mount it on the EC2 instances.

Create an Amazon S3 Standard bucket and enable Amazon S3 Transfer Acceleration to minimize read and write latencies.

Create an Amazon EBS gp3 volume, enable Multi-Attach, and mount it across all EC2 instances in the fleet.

Show answer & explanation

Answer: Create an Amazon S3 Express One Zone directory bucket in the same Availability Zone as the EC2 instances.; Configure the application to make parallel, multi-threaded requests directly to the S3 directory bucket.

Answer

Create an Amazon S3 Express One Zone directory bucket in the same Availability Zone as the EC2 instances, and configure the application to make parallel, multi-threaded requests directly to the directory bucket.

The correct architecture uses Amazon S3 Express One Zone directory buckets because they are specifically engineered for latency-sensitive, high-throughput applications, co-locating the data in the same Availability Zone as the compute resources. Making parallel, multi-threaded requests allows the application to scale and hit the request-rate requirements without being throttled.

Step-by-Step Solution

Analyze the workload requirements: object storage API access, millions of small files, and single-digit millisecond read/write latencies within a single Availability Zone.

Identify that traditional S3 Standard latency and file-based services like EFS or block-based services like EBS are either suboptimal or incompatible.

This establishes the performance and protocol boundaries.

Select the correct S3 storage class designed for single-digit millisecond latency and high request rates within a single Availability Zone.

Choose Amazon S3 Express One Zone, specifically using directory buckets.

S3 Express One Zone is co-located with EC2 instances in the same Availability Zone to minimize network transit time and latency.

Determine the request pattern optimization required to achieve millions of requests per second.

Configure the application to leverage parallel, multi-threaded requests directly to the directory bucket.

S3 directory buckets scale throughput and transactions dynamically with parallel connection scaling.

Key Concept

Amazon S3 Express One Zone is a high-performance, single-AZ storage class designed to deliver single-digit millisecond latency and high request throughput for performance-critical applications, using standard S3 APIs.

Estimated Time:2m 0s

Question 974Question →

A company hosts a microservices application on Amazon ECS using AWS Fargate. The ECS tasks run in private subnets and frequently pull large container images from Amazon Elastic Container Registry (ECR). The company notices a significant increase in their monthly bill due to NAT Gateway data processing charges. Which solution is the most cost-effective way to reduce these charges while maintaining security?

Configure Interface VPC Endpoints for ECR, and configure a Gateway VPC Endpoint for Amazon S3. Update the route table of the private subnets to route S3 traffic through the Gateway Endpoint.

Configure Interface VPC Endpoints for ECR only, and allow the ECS tasks to retrieve the container image layers through the NAT Gateway.

Configure Interface VPC Endpoints for both ECR and Amazon S3, and update the ECS task definitions to use the new endpoints.

Assign public IP addresses to the ECS tasks and route the image download traffic through an Internet Gateway instead of the NAT Gateway.

Show answer & explanation

Answer: Configure Interface VPC Endpoints for ECR, and configure a Gateway VPC Endpoint for Amazon S3. Update the route table of the private subnets to route S3 traffic through the Gateway Endpoint.

Answer

Configure Interface VPC Endpoints for ECR, and configure a Gateway VPC Endpoint for Amazon S3. Update the route table of the private subnets to route S3 traffic through the Gateway Endpoint.

The correct option is to configure Interface VPC Endpoints for ECR and a Gateway VPC Endpoint for Amazon S3. When an ECS Fargate task pulls a container image from Amazon ECR, it authenticates and downloads the image manifest via ECR APIs, and then pulls the actual container layers from Amazon S3. By using ECR Interface Endpoints, the API traffic remains private. By using an S3 Gateway Endpoint, the large image layers are pulled directly from S3 without passing through the NAT Gateway, avoiding the NAT Gateway data processing charge.

Step-by-Step Solution

Analyze the data flow when pulling container images from ECR.

ECR stores the manifest and API metadata on the ECR service, but the actual image layers are stored in Amazon S3.

This helps locate the source of the heavy data transfer that is driving up NAT Gateway processing charges.

Choose the correct endpoint type for ECR API calls.

Establish ECR Interface VPC Endpoints (PrivateLink) for the dkr and api service endpoints.

ECR requires Interface VPC Endpoints for private connectivity within a VPC.

Choose the most cost-effective endpoint type for the S3 image layers.

Create a Gateway VPC Endpoint for Amazon S3 and associate it with the private subnet's route table.

S3 Gateway Endpoints are free and do not charge for data processing, unlike NAT Gateways or Interface Endpoints.

Key Concept

S3 Gateway Endpoints bypass NAT Gateway charges for ECR image downloads because container layers are stored in S3.

Question 975Question →

A media company is redesigning its analytics application to optimize costs and improve scalability. The application receives clickstream data from client devices at highly unpredictable intervals throughout the day, which must be stored in a NoSQL database. Every night, a batch job runs to aggregate and analyze the daily clickstream data, taking between 3 to 4 hours to complete. Additionally, the application runs in private subnets and must frequently transfer hundreds of gigabytes of raw logs to and from an Amazon S3 bucket. Which combination of architectural decisions represents the most cost-effective and scalable solution?

Set the Amazon DynamoDB table capacity mode to on-demand, execute the nightly batch job using Amazon ECS tasks running on AWS Fargate Spot, and configure an Amazon S3 Gateway VPC Endpoint in the private subnets.

Set the Amazon DynamoDB table capacity mode to on-demand, execute the nightly batch job using AWS Lambda functions chained via Amazon SQS, and route the Amazon S3 data transfer through a NAT Gateway.

Set the Amazon DynamoDB table capacity mode to on-demand, execute the nightly batch job using Amazon ECS tasks running on AWS Fargate Spot, and route the Amazon S3 data transfer through a NAT Gateway.

Set the Amazon DynamoDB table capacity mode to provisioned capacity mode with a fixed read/write capacity, execute the nightly batch job using Amazon ECS tasks running on AWS Fargate Spot, and configure an Amazon S3 Gateway VPC Endpoint in the private subnets.

Show answer & explanation

Answer: Set the Amazon DynamoDB table capacity mode to on-demand, execute the nightly batch job using Amazon ECS tasks running on AWS Fargate Spot, and configure an Amazon S3 Gateway VPC Endpoint in the private subnets.

Answer

The most cost-effective and scalable solution is to set the Amazon DynamoDB table capacity mode to on-demand, run the nightly batch job using Amazon ECS tasks on AWS Fargate Spot, and configure an Amazon S3 Gateway VPC Endpoint in the private subnets.

The correct option combines Amazon DynamoDB on-demand mode (to dynamically handle spiky clickstream ingestion), AWS Fargate Spot (to cost-effectively host containerized tasks that run for several hours without paying full Fargate prices), and an Amazon S3 Gateway VPC Endpoint (to eliminate NAT Gateway processing fees for the frequent, large S3 transfers).

Step-by-Step Solution

Analyze NoSQL database scaling and cost requirements.

Since client clickstream traffic is highly unpredictable and spiky, Amazon DynamoDB in on-demand capacity mode is selected to automatically scale throughput and charge only for actual reads and writes, avoiding expensive over-provisioning.

To ensure maximum cost-efficiency for unpredictable workloads.

Evaluate compute options for the 3-4 hour nightly batch job.

AWS Lambda is ruled out due to its 15-minute timeout and high cost for long-running continuous executions. Amazon ECS tasks running on AWS Fargate Spot are selected as they support long runtimes at a heavily discounted rate.

To select a cost-optimized, containerized compute environment suitable for multi-hour processing.

Evaluate private data transfer to Amazon S3.

Instead of routing high volumes of S3 traffic through a NAT Gateway (which incurs per-GB data processing charges), an S3 Gateway VPC Endpoint is configured.

To enable free, private network routing between the VPC and Amazon S3.

Key Concept

Selecting cost-optimized scaling and serverless models based on execution duration, traffic predictability, and network routing costs.

Question 976Question →

A company runs a web application that experiences dynamic seasonal traffic spikes, leading to fluctuations in monthly AWS expenditures. The finance team wants a solution that proactively detects unusual, sudden cost increases caused by application anomalies or unauthorized resource provisioning. The solution must minimize administrative overhead and must not rely on manually defined static thresholds. Which AWS service or feature should a solutions architect recommend to meet these requirements?

AWS Cost Anomaly Detection with an AWS services monitor and an Amazon Simple Notification Service (Amazon SNS) subscription.

AWS Budgets with a daily cost budget configured with a fixed alert threshold of 120% of expected daily costs.

AWS Cost Explorer with a scheduled weekly report sent to the finance team via email.

AWS Trusted Advisor with a weekly email notification configured to report on the Cost Optimization check results.

Show answer & explanation

Answer: AWS Cost Anomaly Detection with an AWS services monitor and an Amazon Simple Notification Service (Amazon SNS) subscription.

Answer

AWS Cost Anomaly Detection with an AWS services monitor and an Amazon Simple Notification Service (Amazon SNS) subscription.

The correct option is the choice containing AWS Cost Anomaly Detection with an AWS services monitor. AWS Cost Anomaly Detection uses machine learning to dynamically model cost baselines based on historical patterns. It automatically adjusts to traffic variations and alerts when spend deviates significantly, satisfying the requirement to avoid static thresholds and minimize administration.

Step-by-Step Solution

Analyze the requirements: detect cost anomalies proactively, minimize administrative overhead, and avoid static thresholds.

Identified that machine learning-based dynamic baseline detection is required.

Static thresholds are unsuitable due to seasonal dynamic traffic fluctuations.

Evaluate AWS Cost Anomaly Detection against other monitoring tools.

AWS Cost Anomaly Detection dynamically establishes baselines and alerts via SNS.

It addresses the dynamic nature of the traffic and provides proactive alerting without manual threshold configuration.

Key Concept

Machine learning-based dynamic cost anomaly alerting vs. static threshold budgeting

Estimated Time:1m 30s

Question 977Question →

A company is designing a serverless backend for a new web application. The application will experience sudden, highly irregular spikes in database reads and writes, with long periods of zero traffic. The architect wants to minimize costs by ensuring that both compute and database resources scale automatically to zero when there is no traffic.

Which combination of AWS services and configurations will achieve this goal most cost-effectively?

AWS Lambda for compute and Amazon DynamoDB configured with on-demand capacity mode.

AWS Lambda for compute and Amazon DynamoDB configured with provisioned capacity mode.

An AWS Lambda function configured to run continuously in a loop for compute and Amazon DynamoDB in on-demand capacity mode.

AWS Lambda for compute and Amazon S3 Standard-Infrequent Access (S3 Standard-IA) to temporarily store transactional tables that are deleted daily.

Show answer & explanation

Answer: AWS Lambda for compute and Amazon DynamoDB configured with on-demand capacity mode.

Answer

AWS Lambda for compute and Amazon DynamoDB configured with on-demand capacity mode.

AWS Lambda and Amazon DynamoDB on-demand capacity mode are fully serverless offerings. Lambda charges only for the exact milliseconds of execution duration, and DynamoDB on-demand charges per request. When there is no incoming traffic, both services scale to zero active capacity and do not incur any compute or request charges, making them the most cost-effective solution for irregular spikes.

Step-by-Step Solution

Analyze the scaling requirements of the compute tier.

AWS Lambda is selected because it runs only in response to requests, scales automatically, and charges nothing when there is no traffic.

To minimize costs for highly irregular traffic, compute resources must scale to zero during idle periods.

Analyze the capacity mode requirements of the database tier.

Amazon DynamoDB with on-demand capacity mode is selected because it charges per request and scales down to zero database request costs when idle.

Provisioned capacity mode charges a constant rate regardless of usage, which is cost-inefficient for unpredictable workloads with long idle periods.

Combine the compute and database services to verify the total cost-efficiency.

The combination of AWS Lambda and DynamoDB on-demand capacity mode ensures both tiers scale to zero cost when traffic is zero.

This achieves the target cost optimization goal with the least operational overhead.

Key Concept

Serverless architectures achieve cost efficiency by scaling both compute and database resources to zero when there is no traffic.

Question 978Question →

A digital media platform hosts its streaming content delivery application on Amazon EC2 instances within a private subnet. The security team needs to implement a solution to monitor the environment for active threats, such as EC2 instances communicating with known command-and-control (C2) servers or performing brute-force attacks. The solution must require minimal operational overhead and provide automatic alerting. Which configuration will meet these requirements?

Deploy AWS WAF at the subnet level to inspect all inbound and outbound traffic for Layer 7 exploits and malicious IP addresses, and trigger alerts using Amazon CloudWatch alarms.

Configure stateless Network ACLs at the subnet level to track stateful outbound connections to command-and-control servers, and use AWS Config to automatically block unauthorized traffic.

Enable Amazon GuardDuty to automatically analyze AWS CloudTrail management events, VPC Flow Logs, and DNS logs, and configure an Amazon EventBridge rule to route high-severity findings to an Amazon SNS topic for alerting.

Enable AWS Shield Standard to monitor all EC2 instance network interfaces for Layer 7 command-and-control communications, and configure security groups to block the traffic.

Show answer & explanation

Answer: Enable Amazon GuardDuty to automatically analyze AWS CloudTrail management events, VPC Flow Logs, and DNS logs, and configure an Amazon EventBridge rule to route high-severity findings to an Amazon SNS topic for alerting.

Answer

The correct solution uses Amazon GuardDuty, which is a managed threat detection service. It continuously analyzes data sources such as VPC Flow Logs, DNS logs, and CloudTrail management events using machine learning, anomaly detection, and integrated threat intelligence to detect malicious behavior (such as command-and-control communications or brute-force attacks) with minimal operational overhead. Integrating GuardDuty with Amazon EventBridge and Amazon SNS allows the security team to receive automatic alerts for high-severity findings.

Step-by-Step Solution

Enable Amazon GuardDuty in the target AWS account.

Amazon GuardDuty immediately begins consuming and analyzing logs including VPC Flow Logs, CloudTrail management events, and DNS query logs without impacting the performance of running EC2 instances.

This establishes the core detection mechanism that leverages built-in threat intelligence and machine learning to identify indicators of compromise, such as command-and-control communications.

Configure an Amazon EventBridge rule filtered for GuardDuty findings.

EventBridge detects when a new threat finding is generated by GuardDuty and matches it against the specified filter pattern (e.g., severity level is high).

This provides a serverless event-routing mechanism to automate response workflows.

Set the target of the EventBridge rule to an Amazon Simple Notification Service (SNS) topic.

The SNS topic triggers notifications (such as emails or SMS) to the security team upon receiving the matched event from EventBridge.

This completes the automated alerting pipeline with minimal custom code or infrastructure maintenance.

Key Concept

Continuous threat detection and automated alerting using managed security services

Question 979Question →

A retail company operates a popular online store on AWS. The application's product catalog is stored in an Amazon RDS for MySQL database. During peak shopping events, the database experiences high read latency and CPU utilization near 100% due to repetitive read queries for identical product details. The product data changes occasionally, and the application must serve the most up-to-date data. The company wants to implement a high-performing caching solution to reduce the database load and minimize response time. Which solution should a solutions architect recommend to meet these requirements?

Deploy an Amazon ElastiCache for Redis cluster. Configure the application to use a cache-aside strategy to load data into the cache on a read miss, and write data to both the database and the cache on updates.

Configure an Amazon CloudFront distribution in front of the application. Create a cache behavior for the API endpoints serving the product catalog and set the Minimum, Default, and Maximum TTLs to 0 to ensure the catalog data is always fresh.

Migrate the product catalog to an Amazon DynamoDB table. Configure the table to use Provisioned Capacity Mode with static, high read capacity units to handle the peak request rate at all times.

Configure an Amazon Route 53 latency routing policy to distribute read query traffic directly to Amazon RDS Read Replicas deployed across multiple AWS Regions.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis cluster. Configure the application to use a cache-aside strategy to load data into the cache on a read miss, and write data to both the database and the cache on updates.

Answer

Deploying Amazon ElastiCache in front of the relational database is the standard best practice for accelerating read-heavy database queries. The cache-aside strategy ensures that frequently queried product details are stored in memory, providing sub-millisecond response times. Writing updates to the cache when the database is updated ensures that inventory changes are immediately reflected, satisfying the requirement to serve the most up-to-date data.

Step-by-Step Solution

Analyze the workload characteristics and requirements.

The workload is read-heavy, experiences high latency during spikes, contains repetitive reads of identical data, and requires real-time data consistency.

This helps identify the appropriate caching layer and data synchronization strategy.

Select the correct caching technology.

Amazon ElastiCache for Redis is selected because it is designed for database query caching and supports complex data types and replication.

CloudFront caches static web assets at the edge, whereas ElastiCache caches database query results closer to the application logic.

Determine the cache synchronization strategy.

Implement cache-aside to load data into ElastiCache only when needed, and update the cache when database records are modified.

This keeps the database load low while ensuring data updates are reflected in real-time.

Key Concept

Database query caching using Amazon ElastiCache to offload read traffic from Amazon RDS and reduce application latency.

Question 980Question →

A company hosts a public REST API for real-time weather telemetry data on Amazon ECS behind an Application Load Balancer (ALB) in the us-east-1 Region. The telemetry data is updated every 5 minutes. To support a global user base, the company needs to minimize latency, protect the ECS backend from traffic spikes, and ensure high availability by automatically routing traffic to a standby ECS deployment in the us-west-2 Region if the primary Region experiences an outage. Which architecture should a solutions architect recommend to meet these requirements with the LEAST operational overhead?

Configure an Amazon CloudFront distribution with an origin group. Set the us-east-1 ALB as the primary origin and the us-west-2 ALB as the failover origin. Configure a cache behavior with a TTL of 5 minutes.

Configure an Amazon CloudFront distribution with a single origin pointing to an Amazon Route 53 latency-based routing DNS record. Create Route 53 latency records with health checks pointing to the ALBs in both regions.

Configure an Amazon CloudFront distribution pointing to the us-east-1 ALB. Associate an AWS WAF web ACL with a custom rule that redirects traffic to the us-west-2 ALB when it detects HTTP 5xx errors from the primary ALB.

Configure an Amazon CloudFront distribution with an origin group containing the us-east-1 ALB as primary and the us-west-2 ALB as failover. Set the cache behavior Minimum TTL, Maximum TTL, and Default TTL to 0.

Show answer & explanation

Answer: Configure an Amazon CloudFront distribution with an origin group. Set the us-east-1 ALB as the primary origin and the us-west-2 ALB as the failover origin. Configure a cache behavior with a TTL of 5 minutes.

Answer

The correct configuration uses an Amazon CloudFront origin group with the primary Application Load Balancer as the primary origin and the standby Application Load Balancer as the failover origin. This native CloudFront feature allows for seamless, low-latency failover at the edge on specific HTTP status codes. Setting a 5-minute TTL optimizes performance for global users and shields the backend ECS containers from traffic spikes by caching the telemetry data.

Step-by-Step Solution

Analyze caching requirements

Since telemetry data updates every 5 minutes, caching it for 5 minutes (300 seconds) at CloudFront edge locations will significantly reduce backend load and improve performance.

This satisfies the constraint of protecting the ECS backend from traffic spikes while serving low-latency data to global users.

Analyze regional resiliency requirements

Identify that CloudFront origin groups allow setting up active-passive failover with primary and standby ALBs across different regions.

This configuration automatically redirects client requests to the secondary origin if the primary origin returns specific HTTP 5xx error codes or connection timeouts, without relying on DNS propagation delays.

Evaluate and eliminate incorrect routing and firewall configurations

Eliminate solutions that rely on DNS-level failover for CloudFront origins (due to DNS caching) or misapply AWS WAF for traffic routing.

These alternatives either fail to provide rapid, reliable failover or use services outside their intended scope.

Key Concept

Amazon CloudFront Origin Groups and Edge Caching

PreviousPage 49 / 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

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

Key Concept