All practice questions

1462 questions

All types1,462 Multiple choice739 Multiple select723

A company hosts a specialized financial reporting API on Amazon EC2 instances managed by an Auto Scaling group. The API runs on a custom port 8000 and is positioned behind an Application Load Balancer (ALB). The EC2 instances run initialization scripts during startup that typically take 5 minutes to complete before the application can respond to requests. The solutions architect must secure the environment so that the EC2 instances accept traffic only from the ALB, and ensure that newly launched instances are not marked unhealthy and terminated prematurely during their initialization phase.

Which two actions should the solutions architect take to meet these requirements? (Select two.)

Select all that apply

Configure the security group associated with the EC2 instances to allow inbound traffic on port 8000 only from the security group of the ALB.

Set the health check grace period on the Auto Scaling group to 360 seconds.

Modify the network ACL of the private subnet to allow inbound traffic on port 8000 and deny all other ports.

Set the target group health check port to port 80 to verify instance reachability before the application starts on port 8000.

Configure an Amazon Route 53 latency routing policy pointing directly to the EC2 instances to distribute the initialization load.

Show answer & explanation

Answer: Configure the security group associated with the EC2 instances to allow inbound traffic on port 8000 only from the security group of the ALB.; Set the health check grace period on the Auto Scaling group to 360 seconds.

Answer

Configure the security group associated with the EC2 instances to allow inbound traffic on port 8000 only from the security group of the ALB, and set the health check grace period on the Auto Scaling group to 360 seconds.

To secure the instances, the solutions architect must allow inbound traffic on port 8000 in the EC2 security group only from the security group of the ALB. To prevent premature termination of newly launched instances due to the 5-minute initialization period, the health check grace period of the Auto Scaling group must be configured to a duration longer than 300 seconds (e.g., 360 seconds).

Step-by-Step Solution

Add a rule to the security group of the EC2 instances to allow TCP traffic on port 8000, setting the source as the security group ID of the Application Load Balancer.

Network access to the backend instances on the application port is locked down to traffic originating from the load balancer.

This implements the security requirement at the instance layer using stateful security groups.

Configure the health check grace period parameter on the Auto Scaling group to 360 seconds.

The Auto Scaling group waits for 360 seconds (6 minutes) before performing health checks on newly launched instances.

This accommodates the 5-minute (300-second) boot-up delay from initialization scripts, preventing premature instance termination.

Key Concept

Securing load-balanced target groups using security groups and configuring health check grace periods to allow for instance initialization.

Question 1062Question →

A healthcare technology company hosts its patient check-in portal at the apex domain patientcheck.com. The primary environment runs on Amazon EC2 instances behind an Application Load Balancer (ALB) in the us-east-1 Region. The company wants to implement an active-passive disaster recovery strategy. If the primary environment in us-east-1 experiences an outage, Route 53 must automatically redirect all incoming client traffic to a standby static maintenance website hosted in an Amazon S3 bucket in the us-west-2 Region. Which combination of Route 53 configurations will meet these requirements?

Configure a primary Failover CNAME record for patientcheck.com pointing to the Application Load Balancer DNS name, and configure a secondary Failover CNAME record pointing to the Amazon S3 bucket website endpoint.

Configure a primary Latency Alias record for patientcheck.com pointing to the Application Load Balancer with Evaluate Target Health set to Yes, and configure a secondary Latency Alias record pointing to the Amazon S3 bucket website endpoint.

Configure a primary Failover Alias record for patientcheck.com pointing to the Application Load Balancer with Evaluate Target Health set to Yes, and configure a secondary Failover Alias record pointing to the Amazon S3 bucket website endpoint.

Configure a primary Failover Alias record for patientcheck.com pointing to the Application Load Balancer with Evaluate Target Health set to No, and create a Route 53 HTTP health check to monitor the Amazon S3 bucket website endpoint.

Show answer & explanation

Answer: Configure a primary Failover Alias record for patientcheck.com pointing to the Application Load Balancer with Evaluate Target Health set to Yes, and configure a secondary Failover Alias record pointing to the Amazon S3 bucket website endpoint.

Answer

The correct configuration uses a primary Failover Alias record pointing to the Application Load Balancer with Evaluate Target Health set to Yes, and a secondary Failover Alias record pointing to the Amazon S3 bucket website endpoint. Route 53 Alias records allow the zone apex to point directly to AWS resources without violating DNS standards. Enabling Evaluate Target Health ensures Route 53 monitors the health of the Application Load Balancer using the health of its targets, automatically failing over to the secondary S3 bucket when the load balancer becomes unhealthy.

Step-by-Step Solution

Identify the DNS limitations for the zone apex domain (patientcheck.com).

Determine that CNAME records cannot be created for the zone apex, requiring the use of Route 53 Alias records instead.

Standard DNS specifications do not allow CNAME records at the zone apex, but Route 53 Alias records can map the zone apex directly to AWS resources.

Select the appropriate routing policy for the active-passive disaster recovery strategy.

Choose the Failover routing policy with primary and secondary record types.

Failover routing directs traffic to a primary resource when it is healthy, and to a secondary resource when the primary resource is unhealthy.

Enable health monitoring on the primary resource.

Set Evaluate Target Health to Yes on the primary Failover Alias record pointing to the Application Load Balancer.

Evaluate Target Health allows Route 53 to use the health checks configured on the Application Load Balancer's target groups to determine if the primary endpoint is healthy.

Key Concept

Active-passive DNS failover using Route 53 Failover Alias records at the zone apex.

Question 1063Question →

A logistics company provides a web-based tracking dashboard containing static map tiles and a real-time tracking API. The static map tiles are stored in an Amazon S3 bucket in the eu-central-1 Region, and the API is hosted on Amazon EC2 instances behind an Application Load Balancer (ALB) in the same Region. The company wants to reduce latency for global users and ensure the dashboard remains highly resilient to storage outages with minimal operational overhead.

Which combination of actions should a solutions architect take to meet these requirements? (Choose two.)

Select all that apply

Configure an Amazon CloudFront distribution with an origin group that has the primary S3 bucket as the primary origin and a replicated S3 bucket in another Region as the failover origin.

Configure a cache behavior within the CloudFront distribution for the API path that forwards all headers and query strings to the Application Load Balancer and sets TTLs to zero.

Configure AWS Route 53 latency routing to resolve the dashboard domain to either the primary S3 bucket or the Application Load Balancer based on user location.

Deploy an AWS WAF Web ACL directly on the primary Amazon S3 bucket to inspect traffic and automatically redirect requests to the secondary S3 bucket when the primary bucket is unavailable.

Enable Cross-Region Replication on the S3 bucket and set the default cache behavior's Time to Live (TTL) to zero in CloudFront to ensure static map tiles are always verified at the origin.

Show answer & explanation

Answer: Configure an Amazon CloudFront distribution with an origin group that has the primary S3 bucket as the primary origin and a replicated S3 bucket in another Region as the failover origin.; Configure a cache behavior within the CloudFront distribution for the API path that forwards all headers and query strings to the Application Load Balancer and sets TTLs to zero.

Answer

Configure an Amazon CloudFront distribution with an origin group that has the primary S3 bucket as the primary origin and a replicated S3 bucket in another Region as the failover origin, and configure a cache behavior within the CloudFront distribution for the API path that forwards all headers and query strings to the Application Load Balancer and sets TTLs to zero.

To achieve low latency and high resiliency for static assets (map tiles) and dynamic API requests, the solutions architect should use Amazon CloudFront. CloudFront caches static assets at edge locations close to users worldwide. By setting up a CloudFront origin group with the primary S3 bucket as the primary origin and a secondary replicated S3 bucket as the failover origin, CloudFront will automatically fail over if the primary S3 origin is unavailable. For the dynamic tracking API, a dedicated cache behavior should be created to forward all query strings and headers directly to the Application Load Balancer without caching, leveraging the AWS global network for optimized latency.

Step-by-Step Solution

Set up a replicated Amazon S3 bucket in a secondary Region to store map tiles and configure a CloudFront distribution with an origin group containing both the primary and failover S3 buckets.

CloudFront handles requests for static map tiles, caching them at edge locations and automatically failing over to the secondary bucket if the primary bucket is unavailable.

To meet the reliability and performance constraints for static assets with minimal operational overhead.

Add a cache behavior for the API path (e.g., /api/*) that points to the Application Load Balancer as the origin.

Dynamic API requests are routed through CloudFront to the ALB while bypassing caching to ensure real-time tracking updates are delivered.

To optimize global routing for dynamic API queries and preserve the unified domain name.

Key Concept

Using Amazon CloudFront with origin groups for high availability of static assets and cache behaviors to route dynamic traffic to Application Load Balancers.

Question 1064Question →

A cloud-based education platform stores video lesson project files and their historical edit versions in an Amazon S3 bucket with versioning enabled. The current versions of the project files average $8\text{ MB}$ in size and are accessed frequently during the first $35$ days of editing. After $35$ days, they are rarely accessed but must be retained for $2\text{ years}$ ( $730\text{ days}$ ) for compliance, requiring millisecond retrieval. The noncurrent (historical) versions average $2\text{ MB}$ in size and are rarely accessed immediately after becoming noncurrent. These historical versions must be retained for $120$ days for recovery purposes and must be retrievable within $5$ hours.

Which combination of S3 Lifecycle actions will meet these requirements in the most cost-effective manner? (Select TWO.)

Select all that apply

Transition current versions to Amazon S3 Glacier Instant Retrieval after

35

days.

Transition noncurrent versions to Amazon S3 Glacier Flexible Retrieval after

0

days.

Transition current versions to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) after

15

days.

Transition noncurrent versions to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) after

0

days and permanently delete them after

25

days.

Transition noncurrent versions to Amazon S3 Glacier Deep Archive after

0

days and permanently delete them after

120

days.

Show answer & explanation

Answer: Transition current versions to Amazon S3 Glacier Instant Retrieval after $35$ days.; Transition noncurrent versions to Amazon S3 Glacier Flexible Retrieval after $0$ days.

Answer

Configure S3 Lifecycle rules to transition current versions to Amazon S3 Glacier Instant Retrieval after

35

days, and transition noncurrent versions to Amazon S3 Glacier Flexible Retrieval after

0

days.

Transitioning the current versions of the project files to Amazon S3 Glacier Instant Retrieval after

35

days is the most cost-effective option because it matches the end of the frequent access period, provides the required millisecond retrieval, and satisfies the

90

-day minimum storage duration rule (retained for

2\text{ years}

). Transitioning the noncurrent versions to Amazon S3 Glacier Flexible Retrieval after

0

days immediately minimizes storage costs for rarely accessed data, meets the

5

-hour retrieval window via standard retrieval (takes

3

5

hours), and satisfies the

90

-day minimum storage duration rule (retained for

120

days).

Step-by-Step Solution

Analyze the storage requirements and access patterns for current versions.

The current versions average

8\text{ MB}

(exceeding the

128\text{ KB}

minimum size limit), are frequently accessed for the first

35

days, and require millisecond retrieval after that for a total of

2\text{ years}

This determines that current versions must remain in S3 Standard for

35

days to avoid retrieval fees, and should then transition to S3 Glacier Instant Retrieval. This class provides millisecond retrieval and the retention period (

2\text{ years}

) easily exceeds the

90

-day minimum storage duration.

Analyze the storage requirements and access patterns for noncurrent versions.

Noncurrent versions average

2\text{ MB}

(exceeding the

128\text{ KB}

minimum size limit), are rarely accessed immediately, must be kept for

120

days, and can tolerate a retrieval time of up to

5

hours.

This indicates that noncurrent versions can be transitioned to a cheaper archive class immediately (

0

days). S3 Glacier Flexible Retrieval (standard retrieval takes

3

5

hours) meets the

5

-hour requirement, and the

120

-day retention period satisfies the

90

-day minimum storage duration.

Evaluate the distractors against S3 minimum storage duration limits and retrieval constraints.

Transitioning current versions after

15

days incurs high retrieval fees. Transitioning noncurrent versions to S3 Standard-IA and deleting after

25

days violates the

30

-day minimum storage duration. Transitioning to Glacier Deep Archive and deleting after

120

days violates the

180

-day minimum storage duration and fails the retrieval SLA.

This confirms that options involving premature transitions, early deletion penalties, or slow retrieval options are suboptimal.

Key Concept

Selecting the optimal S3 storage class and transition timing based on object size, retention periods, minimum storage durations, and retrieval time constraints.

Question 1065Question →

A solutions architect is designing a real-time advertising analytics platform to ingest and store ad impression events. The platform receives millions of write operations per minute. The system must support querying data by `campaign_id` sorted by `timestamp` to display real-time campaign performance. There are fewer than $100$ active campaigns at any given time, but the traffic is distributed unevenly across them, with some popular campaigns receiving the majority of the impressions. Which database design strategy should the solutions architect implement to ensure high write throughput and avoid throttling in Amazon DynamoDB?

Use a partition key of campaign_id and a sort key of timestamp, and deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache write requests.

Create a partition key by appending a random integer suffix to the campaign_id, and use timestamp as the sort key.

Use campaign_id as the partition key and timestamp as the sort key directly.

Use timestamp as the partition key and campaign_id as the sort key.

Show answer & explanation

Answer: Create a partition key by appending a random integer suffix to the campaign_id, and use timestamp as the sort key.

Answer

Create a partition key by appending a random integer suffix to the campaign_id, and use timestamp as the sort key.

The correct option is to append a random integer suffix to the campaign_id. In Amazon DynamoDB, a single partition can support up to

1000

Write Capacity Units (WCUs). If write traffic is concentrated on a small number of keys, it leads to hot partitions and throttling. Appending a random suffix (write sharding) distributes the writes for a single campaign across multiple partitions, maintaining high write performance.

Step-by-Step Solution

Analyze the access pattern and data distribution requirements.

The application needs high write throughput for millions of events per minute, with fewer than

100

active campaigns, meaning query traffic is highly concentrated on a small set of campaign IDs.

Identifying the skew in campaign traffic highlights the risk of partition hot-spotting if campaign_id is used as the partition key directly.

Evaluate partitioning and sharding strategies to distribute write traffic.

Adding a random integer suffix to the partition key (e.g., campaign_id_1 to campaign_id_N) splits the data for a single campaign across multiple physical partitions.

Distributing the writes across multiple partitions avoids exceeding the throughput limit of a single partition, which is

1000

Write Capacity Units (WCUs) in DynamoDB.

Determine the role of caching in resolving write bottlenecks.

DAX does not solve write bottlenecks because all write operations are write-through to the database.

Caching mechanisms like DAX only optimize read latency and do not reduce the write load on the underlying database.

Key Concept

Write sharding (using partition key suffixes) to distribute high-throughput write traffic evenly across DynamoDB partitions.

Estimated Time:1m 30s

Question 1066Question →

A company is optimizing the costs of its database tier on AWS. The current architecture consists of:

* An Amazon RDS for PostgreSQL database that requires $200\text{ GB}$ of storage. The database handles OLTP workloads with a constant baseline of $3,000\text{ IOPS}$ , but experiences daily performance spikes up to $9,000\text{ IOPS}$ .
* An Amazon DynamoDB table used to store historical user activity logs. The log generation is highly unpredictable, experiencing sudden write bursts of up to $2,000\text{ writes/sec}$ followed by hours of complete inactivity.

Which combination of database configurations will meet these requirements most cost-effectively? (Select TWO.)

Select all that apply

Configure the RDS for PostgreSQL DB instance to use gp3 storage with

9,000

provisioned IOPS.

Configure the DynamoDB table to use On-Demand capacity mode.

Configure the DynamoDB table to use Provisioned capacity mode with Auto Scaling enabled and a target utilization of

70\%

Configure the DynamoDB table to use Provisioned capacity mode with a fixed baseline of

2,000

Write Capacity Units (WCUs) to handle peak write bursts.

Configure the RDS for PostgreSQL DB instance as a Single-AZ instance and deploy a Read Replica in another Availability Zone to serve as the automatic failover target.

Show answer & explanation

Answer: Configure the RDS for PostgreSQL DB instance to use gp3 storage with $9,000$ provisioned IOPS.; Configure the DynamoDB table to use On-Demand capacity mode.

Answer

The correct database configurations are to configure the RDS for PostgreSQL DB instance to use gp3 storage with 9,000 provisioned IOPS, and to configure the DynamoDB table to use On-Demand capacity mode.

Configuring the RDS for PostgreSQL DB instance to use gp3 storage with

9,000

provisioned IOPS is correct because gp3 allows independent provisioning of IOPS and storage volume size. This avoids the cost of scaling a gp2 volume to

3,000\text{ GB}

just to get

9,000\text{ IOPS}

, and is more cost-effective than io2 storage. Configuring the DynamoDB table to use On-Demand capacity mode is correct because the workload is highly unpredictable with long periods of complete inactivity, which eliminates idle capacity costs.

Step-by-Step Solution

Analyze the performance and storage requirements for the RDS for PostgreSQL database.

The database needs

200\text{ GB}

of storage and must handle up to

9,000\text{ IOPS}

during peak hours, with a baseline of

3,000\text{ IOPS}

Identifying the baseline and peak IOPS determines the storage type required.

Evaluate storage options for RDS PostgreSQL to find the most cost-effective tier.

gp3 storage allows provisioning

9,000\text{ IOPS}

independently of the storage capacity. gp2 would require scaling the volume to

3\text{ TB}

to get

9,000\text{ IOPS}

, which is highly wasteful, and io2 is much more expensive per GB and per IOPS.

gp3 decouples storage size from IOPS performance, minimizing costs for low storage/high IOPS workloads.

Analyze the access patterns and capacity requirements for the DynamoDB table.

The workload has highly unpredictable write bursts up to

2,000\text{ writes/sec}

followed by long periods of inactivity.

Understanding the variability of traffic determines the optimal DynamoDB capacity mode.

Compare DynamoDB On-Demand and Provisioned capacity modes.

On-Demand mode is ideal because the workload has unpredictable spikes and is completely idle for hours, meaning the company pays nothing during idle periods. Provisioned capacity with Auto Scaling is slower to respond to unpredictable spikes and incurs baseline costs during idle times.

On-Demand capacity mode optimizes costs by charging only for actual read/write requests without baseline idle charges.

Key Concept

Cost-Optimized Database Design and Capacity Planning

Question 1067Question →

A SaaS company hosts its collaborative project management application at the apex domain projectcollab.com. The application's primary infrastructure runs in the us-west-2 Region, where an Application Load Balancer (ALB) routes traffic to a fleet of Amazon EC2 instances. The company maintains a warm standby disaster recovery environment in the eu-west-1 Region, which also uses an ALB. The company wants to implement an active-passive disaster recovery strategy where Amazon Route 53 automatically diverts all traffic to the warm standby environment in eu-west-1 only if the primary environment in us-west-2 experiences an outage.

Which combination of Route 53 configurations will meet these requirements? (Choose two.)

Select all that apply

Create a primary Failover Alias record for projectcollab.com that points to the Application Load Balancer in us-west-2 and configure Evaluate Target Health to Yes.

Create a secondary Failover Alias record for projectcollab.com that points to the Application Load Balancer in eu-west-1 and configure Evaluate Target Health to Yes.

Create a primary CNAME record for projectcollab.com that points to the us-west-2 Application Load Balancer and configure a Route 53 HTTP health check.

Create a Latency routing record for projectcollab.com that points to the us-west-2 Application Load Balancer to automatically failover based on client latency changes.

Create a Failover routing policy record pointing to the standby database read replica in eu-west-1 to automatically promote it to primary during the failover event.

Show answer & explanation

Answer: Create a primary Failover Alias record for projectcollab.com that points to the Application Load Balancer in us-west-2 and configure Evaluate Target Health to Yes.; Create a secondary Failover Alias record for projectcollab.com that points to the Application Load Balancer in eu-west-1 and configure Evaluate Target Health to Yes.

Answer

Create a primary Failover Alias record for the apex domain pointing to the us-west-2 ALB, and a secondary Failover Alias record pointing to the eu-west-1 ALB, both with Evaluate Target Health set to Yes.

To configure active-passive failover for an apex domain, you must use Route 53 Alias records because standard CNAME records are not allowed at the zone apex. The primary record must be configured as a Failover policy with the 'Primary' type, pointing to the primary ALB, and with 'Evaluate Target Health' set to 'Yes' so Route 53 can monitor the health of the primary ALB. The standby record must be configured as a Failover policy with the 'Secondary' type, pointing to the standby ALB, with 'Evaluate Target Health' also set to 'Yes' to ensure the secondary region's ALB health is verified before routing traffic to it.

Step-by-Step Solution

Evaluate record requirements for the zone apex.

Determine that CNAME records cannot be used at the zone apex (projectcollab.com) due to DNS RFC limitations. Identify that Route 53 Alias records must be used to point to the Application Load Balancers.

Alias records allow mapping the zone apex to AWS resources like Application Load Balancers without violating DNS standards.

Configure the primary routing endpoint.

Configure a Failover routing policy record pointing to the primary ALB in us-west-2, set its failover type to Primary, and enable Evaluate Target Health.

This allows Route 53 to track the health of the primary ALB and stop routing traffic to it if the backend instances or ALB become unhealthy.

Configure the standby routing endpoint.

Configure a Failover routing policy record pointing to the standby ALB in eu-west-1, set its failover type to Secondary, and enable Evaluate Target Health.

This registers the standby environment as the target for traffic when the primary record is determined to be unhealthy.

Key Concept

Implementing Route 53 active-passive failover at the zone apex requires creating Primary and Secondary Failover Alias records pointing to the ALBs with health checks or Evaluate Target Health enabled.

Question 1068Question →

A company hosts a web application on Amazon EC2 instances inside an Auto Scaling group behind an Application Load Balancer (ALB). The application on one of the EC2 instances becomes unresponsive, causing the ALB target group health check to mark that instance as unhealthy. However, the Auto Scaling group does not terminate or replace the unhealthy instance. Which action will ensure that the Auto Scaling group automatically replaces the unresponsive instance?

Modify the subnet Network Access Control List (NACL) to allow inbound ephemeral port traffic.

Update the Application Load Balancer target group health check configuration to query a different port than the application port.

Change the health check type of the Auto Scaling group from EC2 to ELB.

Configure an Amazon Route 53 latency routing policy to redirect client traffic away from the unresponsive instance.

Show answer & explanation

Answer: Change the health check type of the Auto Scaling group from EC2 to ELB.

Answer

Change the health check type of the Auto Scaling group from EC2 to ELB.

Changing the health check type of the Auto Scaling group from EC2 to ELB enables the group to utilize the load balancer's application-level health checks. When the Application Load Balancer target group marks the unresponsive instance as unhealthy, the Auto Scaling group detects this status, terminates the failed instance, and launches a new, healthy instance to maintain the desired capacity.

Step-by-Step Solution

Diagnose why the Auto Scaling group fails to act on application-level failures.

Identify that the Auto Scaling group's default health check type is 'EC2', which only checks hardware and hypervisor status, leaving it unaware of application-level health check failures reported by the load balancer.

EC2 status checks do not monitor the status of the web application or service running on the instances.

Select the configuration that integrates Auto Scaling lifecycle events with Elastic Load Balancing health status.

Determine that changing the Auto Scaling group health check type to 'ELB' allows the group to consume target group health status.

When the health check type is set to 'ELB', the Auto Scaling group marks an instance as unhealthy and replaces it if either the EC2 status checks or the ELB target group health checks fail.

Key Concept

Auto Scaling Group Health Check Integration with Elastic Load Balancing

Question 1069Question →

A company is developing a web application that runs on Amazon EC2 instances and connects to an Amazon RDS for PostgreSQL database. The database credentials must be encrypted at rest and rotated every 30 days. The solutions architect needs to design a secure solution to manage these credentials with minimal administrative overhead. Which two actions should the solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Store the database credentials as a secret in AWS Secrets Manager.

Enable automatic rotation for the secret and configure it to use a pre-configured AWS Lambda function designed for Amazon RDS.

Store the database credentials in AWS Systems Manager Parameter Store as a plain String parameter.

Store the database credentials in AWS Systems Manager Parameter Store as a SecureString parameter and enable AWS KMS key rotation to rotate the credential values.

Store the database credentials directly in AWS KMS and configure a KMS key policy to automatically rotate the credentials annually.

Show answer & explanation

Answer: Store the database credentials as a secret in AWS Secrets Manager.; Enable automatic rotation for the secret and configure it to use a pre-configured AWS Lambda function designed for Amazon RDS.

Answer

To securely manage database credentials, the solutions architect should store the credentials in AWS Secrets Manager and enable automatic rotation using a pre-configured AWS Lambda function tailored for Amazon RDS.

AWS Secrets Manager secures database credentials at rest using KMS encryption. By combining it with a pre-configured AWS Lambda function, Secrets Manager can safely update the database credentials on a schedule (such as every 30 days) and update the secret store automatically, satisfying all requirements with minimal administrative effort.

Step-by-Step Solution

Select a secure storage service for the credentials that supports automatic rotation.

AWS Secrets Manager is chosen because it encrypts secrets at rest and natively supports automatic rotation for Amazon RDS databases.

Systems Manager Parameter Store does not offer native, out-of-the-box automatic rotation for RDS databases without custom Lambda functions, which increases administrative overhead.

Configure the rotation mechanism for the database credentials.

Enable automatic rotation on the secret, electing to use the RDS rotation template which deploys a pre-configured AWS Lambda function.

The Lambda function executes the rotation lifecycle (updating credentials in RDS and the secret value in Secrets Manager) without modifying application code.

Key Concept

AWS Secrets Manager vs Systems Manager Parameter Store rotation and encryption capabilities.

Question 1070Question →

A gaming company hosts a multiplayer online battle arena (MOBA) game server backend on Amazon EC2 instances managed by an Auto Scaling group (ASG) in private subnets. The game server application communicates using UDP port 7777. To route incoming traffic with ultra-low latency, a solutions architect deploys a Network Load Balancer (NLB) in public subnets. The target group is configured to register the EC2 instances by Instance ID. The solutions architect has configured the security group of the EC2 instances to allow inbound UDP traffic on port 7777 from the client IP ranges. However, the NLB is marking all EC2 instances as unhealthy, and clients are unable to connect to the game servers. Which two actions should the solutions architect take to resolve the health check issues and allow client traffic? (Select two.)

Select all that apply

Configure the target group health check to use the TCP or HTTP protocol on a dedicated port, such as port 8080, and run a health status service on that port on the EC2 instances.

Add a rule to the EC2 instances' security group to allow inbound TCP traffic on the designated health check port from the private IP addresses of the NLB.

Modify the target group health check settings to use the UDP protocol on port 7777.

Add a rule to the EC2 instances' security group allowing inbound UDP traffic on the health check port from the external client IP ranges.

Configure an Amazon Route 53 latency routing policy to direct client traffic to the EC2 instances' private IP addresses, bypassing the NLB.

Show answer & explanation

Answer: Configure the target group health check to use the TCP or HTTP protocol on a dedicated port, such as port 8080, and run a health status service on that port on the EC2 instances.; Add a rule to the EC2 instances' security group to allow inbound TCP traffic on the designated health check port from the private IP addresses of the NLB.

Answer

To resolve the health check issues and allow client traffic, the solutions architect must configure the target group health check to use the TCP or HTTP protocol on a dedicated port, run a health status service on that port on the EC2 instances, and add a rule to the EC2 instances' security group to allow inbound TCP traffic on that designated health check port from the private IP addresses of the NLB.

To resolve the health check issues and allow client traffic, the solutions architect must configure a TCP- or HTTP-based health check on a dedicated port on the EC2 instances, and update the EC2 instances' security group to allow inbound TCP traffic on that health check port from the NLB's private IP addresses. Because Network Load Balancers (NLB) do not support UDP health checks, a separate TCP/HTTP listening service is required on the instances. Additionally, health checks originate directly from the NLB nodes' private IP addresses, requiring the security group to permit this traffic.

Step-by-Step Solution

Analyze health check protocol limitations for Network Load Balancer (NLB) UDP target groups.

Identify that UDP-based health checks are unsupported; the target group health check protocol must be TCP, HTTP, or HTTPS.

Since UDP is stateless, it cannot verify target availability through standard handshakes, necessitating a TCP/HTTP listener for checks.

Determine the service configuration required on the EC2 instances.

Establish a separate TCP or HTTP service on a dedicated port (e.g., port 8080) on the EC2 instances to report health status.

The main game application uses UDP port 7777, so a separate port running a TCP/HTTP listener must respond to health checks.

Configure the security groups of the EC2 targets to allow health check traffic.

Add a rule to the EC2 instances' security group permitting inbound TCP traffic on the health check port from the NLB's private IP addresses.

Unlike client traffic (where client IP is preserved when registering by Instance ID), NLB health checks originate directly from the NLB's internal private IP addresses.

Key Concept

Network Load Balancer health checks for UDP target groups and target security group configuration.

Question 1071Question →

A global weather application serves forecast data that is updated once every 15 minutes. The backend architecture consists of Amazon Route 53, Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. The application experiences a high volume of read requests. The development team wants to optimize read performance, reduce the compute load on AWS Lambda, and keep integration changes minimal. Which of the following solutions should a solutions architect recommend?

Enable caching on the API Gateway stage with a Time-to-Live (TTL) of 900 seconds.

Deploy Amazon CloudFront in front of the API Gateway, and configure a cache behavior with a Minimum, Maximum, and Default TTL of 0 seconds.

Configure the Amazon DynamoDB table in Provisioned Capacity mode and scale up the Read Capacity Units (RCUs) to handle the peak request rate.

Configure Amazon Route 53 Latency routing to distribute requests across multiple regional API Gateway endpoints.

Show answer & explanation

Answer: Enable caching on the API Gateway stage with a Time-to-Live (TTL) of 900 seconds.

Answer

Enable caching on the API Gateway stage with a Time-to-Live (TTL) of 900 seconds.

Enabling caching on the API Gateway stage with a Time-to-Live (TTL) of 900 seconds allows API Gateway to respond to client requests using cached data. Because the weather forecast data changes only every 15 minutes, a 900-second cache duration aligns perfectly with the update cycle. This solution prevents duplicate requests from triggering AWS Lambda, thereby reducing compute load and database queries while lowering overall latency.

Step-by-Step Solution

Identify the caching layer that can intercept requests before they invoke the compute layer (AWS Lambda).

API Gateway caching is selected because it is positioned in front of AWS Lambda.

To reduce AWS Lambda compute load, the caching layer must serve responses before invoking the Lambda function.

Determine the optimal Time-to-Live (TTL) based on the data update frequency.

Set the TTL to 900 seconds (15 minutes).

Since the weather forecast data only updates every 15 minutes, caching the data for 900 seconds ensures users get up-to-date forecasts while maximizing cache hits.

Key Concept

API Gateway Caching

Estimated Time:1m 30s

Question 1072Question →

A financial services company hosts a compliance reporting application on Amazon EC2 instances. The application requires access to a static third-party API token. The security team mandates that the token must be encrypted at rest using a customer managed key that undergoes automatic annual rotation. However, to maintain data integrity, historical records encrypted with older versions of the key must remain decryptable without being re-encrypted. Which solution meets these requirements with the lowest operational overhead and cost?

Store the API token in AWS Systems Manager Parameter Store as a SecureString parameter. Encrypt the parameter using an AWS KMS customer managed key with automatic key rotation enabled.

Store the API token in AWS Systems Manager Parameter Store as a String parameter type, and configure the default parameter encryption option using a custom KMS key that rotates annually.

Store the API token in AWS Secrets Manager. Configure an AWS KMS customer managed key, and write a custom AWS Lambda function to decrypt and re-encrypt all historical logs and parameters whenever the KMS key is rotated.

Store the API token in a configuration file on the EC2 instances. Encrypt the configuration file using AWS KMS, and embed the AWS account's root user credentials in the application code to decrypt the key.

Show answer & explanation

Answer: Store the API token in AWS Systems Manager Parameter Store as a SecureString parameter. Encrypt the parameter using an AWS KMS customer managed key with automatic key rotation enabled.

Answer

Store the API token in AWS Systems Manager Parameter Store as a SecureString parameter, encrypting it with a customer managed KMS key that has automatic rotation enabled.

Storing the token as a SecureString in Systems Manager Parameter Store provides secure encryption at rest without the cost overhead of AWS Secrets Manager. Utilizing a customer managed KMS key with automatic rotation enabled satisfies the annual key rotation requirement, and because KMS natively manages historical key versions to decrypt old data, no manual re-encryption of historical records is needed.

Step-by-Step Solution

Determine the cost-effective secrets storage service.

AWS Systems Manager Parameter Store is chosen because standard parameters are free, and the API token is static and does not require automatic rotation (which is a primary feature of the costlier AWS Secrets Manager).

Choosing the service that minimizes cost and operational overhead while meeting technical requirements.

Select the correct parameter type for encryption.

A SecureString parameter type is selected, referencing a customer managed AWS KMS key.

String parameters are plaintext, whereas SecureString parameters encrypt data at rest using AWS KMS.

Configure KMS key rotation mechanics.

Enable automatic annual rotation on the customer managed KMS key.

AWS KMS automatically retains historical key material to decrypt previously encrypted values, allowing decryption of old records without requiring manual re-encryption.

Key Concept

Secrets vs Parameter Management and KMS Key Rotation Mechanics

Question 1073Question →

A company hosts a high-traffic e-commerce application on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The ALB target group health check is configured to query an application endpoint `/health` on port 443, which verifies the application's connection to a backend Amazon RDS database. During a scheduled database maintenance window, the database becomes temporarily unavailable, causing the `/health` endpoint to return HTTP 500 errors. Consequently, the ALB target group marks all EC2 instances as unhealthy. Because the ASG is configured to use ELB health checks, it begins terminating all instances in the fleet and launching new ones. This results in a continuous loop of instance provisioning and termination, generating high costs and delaying recovery when the database comes back online. Which action should a Solutions Architect take to resolve this issue and prevent the unnecessary termination of EC2 instances during database outages?

Modify the Network Access Control List (NACL) of the subnet containing the EC2 instances to stateless deny rules for outbound traffic on ephemeral ports to temporarily block the health check requests.

Configure the Auto Scaling group to use EC2 health checks instead of ELB health checks, allowing the Application Load Balancer to stop routing traffic to the instances while preventing the Auto Scaling group from terminating them.

Change the Application Load Balancer target group health check configuration to query port 80 instead of port 443, assuming the instances will return a default healthy status on port 80.

Configure an Amazon Route 53 latency-based routing policy to automatically reroute the health check queries to a secondary Auto Scaling group in another AWS Region during the database outage.

Show answer & explanation

Answer: Configure the Auto Scaling group to use EC2 health checks instead of ELB health checks, allowing the Application Load Balancer to stop routing traffic to the instances while preventing the Auto Scaling group from terminating them.

Answer

Configuring the Auto Scaling group to use EC2 health checks instead of ELB health checks ensures that the Auto Scaling group only terminates instances if they fail EC2 status checks (hardware or hypervisor issues). The Application Load Balancer will still mark the instances as unhealthy and stop routing traffic to them when the database is unavailable, but the instances will not be terminated. Once the database becomes available again, the load balancer health checks will pass, and traffic will resume seamlessly.

Step-by-Step Solution

Analyze the cause of the instance termination loop.

The Auto Scaling group is set to use ELB health checks, meaning any target group health check failure triggers instance termination and replacement.

To identify why the database outage results in instance termination rather than just traffic redirection.

Compare Auto Scaling group health check types (EC2 vs. ELB).

With EC2 health checks, the Auto Scaling group only replaces instances that fail hardware or system status checks. With ELB health checks, it also replaces instances that fail load balancer target group checks.

To determine how to decouple application-level dependencies (like the database) from instance lifecycle management.

Select the optimal configuration to handle temporary database maintenance.

By switching to EC2 health checks, the instances remain running during database downtime. The Application Load Balancer still marks them unhealthy and stops sending traffic, but the fleet is preserved, avoiding a high-cost provisioning loop.

To ensure high availability and cost-efficiency when the database recovers.

Key Concept

Decoupling Auto Scaling group health checks from Application Load Balancer health checks when downstream dependencies can cause transient failures.

Estimated Time:2m 0s

Question 1074Question →

An architecture team is designing a global IoT telemetry solution. The system collects continuous status reports from millions of devices using a custom TCP-based protocol. The backend ingestion servers run on Amazon EC2 instances behind Application Load Balancers (ALBs) deployed in the us-east-1 and eu-west-1 regions. The solution must minimize packet latency, route device traffic to the nearest healthy region, and automatically failover within seconds during a regional outage. Which AWS service configuration meets these resilience and performance requirements?

Provision AWS Global Accelerator and associate the Application Load Balancers (ALBs) in both regions as endpoints. Configure the accelerator to route custom TCP traffic over the AWS global network to the nearest healthy ALB, providing automatic failover.

Create an Amazon CloudFront distribution with the Application Load Balancers (ALBs) configured in an origin group. Set the default Cache-Control headers and Time-To-Live (TTL) to zero to route the custom TCP telemetry traffic without caching.

Use Amazon Route 53 with a latency-based routing policy to route client traffic directly to the Application Load Balancers (ALBs). Rely on the client’s DNS cache expiration to handle regional failover when an ALB becomes unhealthy.

Deploy AWS WAF at the edge to inspect incoming custom TCP traffic and configure AWS Shield Standard on the Application Load Balancers (ALBs) to manage cross-region failover and traffic redirection.

Show answer & explanation

Answer: Provision AWS Global Accelerator and associate the Application Load Balancers (ALBs) in both regions as endpoints. Configure the accelerator to route custom TCP traffic over the AWS global network to the nearest healthy ALB, providing automatic failover.

Answer

AWS Global Accelerator is designed to optimize performance and availability for TCP and UDP traffic. It uses Anycast IP addresses to ingest traffic at the edge location closest to the user and routes it over the AWS global network to the nearest healthy regional endpoint. It performs continuous health checks and automatically redirects traffic to healthy endpoints in other regions within seconds if a regional failure occurs.

Step-by-Step Solution

Analyze the protocol requirement.

The application uses a custom TCP-based protocol rather than standard HTTP/HTTPS.

This determines which edge services are compatible, as some services are limited to specific application layer protocols.

Evaluate Amazon CloudFront's protocol compatibility.

CloudFront is disqualified because it only supports HTTP, HTTPS, and WebSockets.

CloudFront cannot ingest or route raw custom TCP traffic.

Evaluate Route 53 latency routing for the failover time constraint.

Route 53 latency routing is disqualified because it cannot guarantee failover within seconds due to client DNS caching.

DNS-based failover is dependent on TTL expiration and client compliance, which often exceeds the desired outage recovery window.

Select AWS Global Accelerator as the optimal solution.

AWS Global Accelerator meets the requirements by supporting custom TCP traffic, using Anycast IP routing over the AWS global backbone, and automatically failing over to healthy endpoints in seconds.

This provides both the lowest latency routing and the resilient sub-minute failover required by the scenario.

Key Concept

AWS Global Accelerator vs. Amazon CloudFront for non-HTTP TCP traffic failover and optimization

Estimated Time:2m 0s

Question 1075Question →

A logistics company uploads daily vehicle tracking video feeds with an average file size of $200\text{ MB}$ to an Amazon S3 Standard bucket. The videos are analyzed frequently by a machine learning model during the first $20\text{ days}$ following upload. For the next $5\text{ days}$ , the videos are occasionally reviewed by quality assurance teams. After $25\text{ days}$ total, the videos are no longer needed and must be permanently deleted. Which lifecycle configuration is the MOST cost-effective for managing these objects?

Keep the videos in Amazon S3 Standard for the entire

25\text{ days}

, then use a lifecycle rule to permanently delete them.

Configure a lifecycle rule to transition the videos to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) after

20\text{ days}

, and permanently delete them after

25\text{ days}

Configure a lifecycle rule to transition the videos to Amazon S3 One Zone-Infrequent Access (S3 One Zone-IA) after

20\text{ days}

, and permanently delete them after

25\text{ days}

Configure a lifecycle rule to transition the videos to Amazon S3 Glacier Instant Retrieval after

20\text{ days}

, and permanently delete them after

25\text{ days}

Show answer & explanation

Answer: Keep the videos in Amazon S3 Standard for the entire $25\text{ days}$ , then use a lifecycle rule to permanently delete them.

Answer

Keep the videos in Amazon S3 Standard for the entire 25 days, then use a lifecycle rule to permanently delete them.

Keeping the videos in Amazon S3 Standard for the entire 25 days is the most cost-effective configuration. Because the objects are deleted at day 25, transitioning them to Amazon S3 Standard-IA, One Zone-IA, or Glacier Instant Retrieval on day 20 means they would reside in those tiers for only 5 days. Since S3 Standard-IA and S3 One Zone-IA have a 30-day minimum storage duration, and S3 Glacier Instant Retrieval has a 90-day minimum storage duration, the company would be billed for the unused days up to the minimum limit. These penalties, combined with transition request fees, exceed the cost of simply keeping the data in S3 Standard for the full 25 days.

Step-by-Step Solution

Analyze the lifecycle duration and requirements of the video files.

The files are stored in S3 Standard for 20 days, then accessed occasionally for 5 days, and must be permanently deleted at day 25.

This establishes the timeline of 25 days total storage duration before permanent deletion.

Evaluate the suitability and minimum billing constraints of S3 storage tiers.

S3 Standard has no minimum storage duration. S3 Standard-IA and S3 One Zone-IA have a 30-day minimum storage duration. S3 Glacier Instant Retrieval has a 90-day minimum storage duration.

Transitioning objects to S3 Standard-IA or One Zone-IA on day 20 and deleting them on day 25 means they are only stored in the destination tier for 5 days, which is less than the 30-day minimum.

Calculate and compare the cost of keeping the data in S3 Standard versus transitioning.

Transitioning to S3 Standard-IA or S3 One Zone-IA on day 20 for 5 days of storage results in paying for 30 days of storage plus transition fees. Keeping the data in S3 Standard for the full 25 days avoids these minimum duration penalties and transition fees, resulting in the lowest total cost.

Choosing the option that avoids minimum storage duration penalties guarantees the most cost-effective outcome.

Key Concept

Amazon S3 lifecycle transitions to storage classes with minimum storage durations (such as S3 Standard-IA, S3 One Zone-IA, and S3 Glacier) incur minimum billing duration penalties if the objects are deleted or transitioned again before the minimum period has elapsed.

Question 1076Question →

A solutions architect is deploying a web application on Amazon EC2 instances managed by an Auto Scaling group. The application runs on port 8080 and is registered with an Application Load Balancer (ALB) target group. The load balancer marks all EC2 instances as unhealthy, even though the application is running successfully on the instances. The security groups are already correctly configured to allow traffic on port 8080. Which two configurations should the solutions architect verify to resolve this health check issue? (Select two.)

Select all that apply

Ensure that the target group health check port is explicitly configured to use port 8080 or the traffic port instead of defaulting to port 80.

Ensure that the stateless network access control list (network ACL) associated with the subnets allows outbound traffic on the ephemeral port range to permit health check responses.

Add an outbound rule to the security group of the EC2 instances to allow return traffic to the ALB security group on port 8080.

Change the health check port to port 80 in the target group settings because Application Load Balancers do not support custom ports for health checks.

Configure an Amazon Route 53 latency routing policy with a health check pointing directly to the EC2 instances to bypass the ALB target group.

Show answer & explanation

Answer: Ensure that the target group health check port is explicitly configured to use port 8080 or the traffic port instead of defaulting to port 80.; Ensure that the stateless network access control list (network ACL) associated with the subnets allows outbound traffic on the ephemeral port range to permit health check responses.

Answer

Verify that the target group health check port is explicitly configured to use port 8080 or the traffic port, and check that the stateless network ACLs allow outbound traffic on the ephemeral port range.

The correct configurations involve correcting the target group health check port and ensuring that stateless network ACLs allow the return traffic. By default, target group health checks may query port 80, but since the application runs on port 8080, the health check port must be set to port 8080 or configured as the 'traffic-port'. Additionally, since network ACLs are stateless, they require explicit outbound rules for the ephemeral port range to allow return traffic from the EC2 instances back to the load balancer.

Step-by-Step Solution

Analyze the load balancer health check configuration and compare it to the port where the application is listening.

The application is running on port 8080, but default health checks might query port 80. The target group must be updated to query port 8080 or the traffic port.

Health checks fail if they query a port where no service is listening.

Examine the subnet-level network access control lists (network ACLs) for traffic restrictions.

Since network ACLs are stateless, verify that outbound rules permit traffic to the ephemeral ports (1024-65535) back to the load balancer.

Even if inbound traffic is allowed, stateless network ACLs will block the return health check responses if ephemeral outbound ports are not open.

Key Concept

Auto Scaling and Elastic Load Balancing health checks rely on matching port configurations and stateful/stateless firewall rules (security groups and network ACLs) to function correctly.

Question 1077Question →

A software developer is configuring a deployment pipeline on AWS and needs to store database connection details. The database hostname is public information, but the database password must be encrypted at rest to comply with company security policies. The password is static and does not need automatic rotation. Which configuration should the developer use to meet these requirements securely and with the lowest cost?

Store the database hostname as a String parameter and the database password as a SecureString parameter in AWS Systems Manager Parameter Store.

Store both the database hostname and the database password as String parameters in AWS Systems Manager Parameter Store.

Store the database password as a SecureString parameter in AWS Systems Manager Parameter Store, and enable AWS KMS automatic key rotation to rotate the database password value annually.

Store the database password in the AWS account root user credentials to ensure maximum security and access control.

Show answer & explanation

Answer: Store the database hostname as a String parameter and the database password as a SecureString parameter in AWS Systems Manager Parameter Store.

Answer

Store the database hostname as a String parameter and the database password as a SecureString parameter in AWS Systems Manager Parameter Store.

The correct option proposes storing the hostname as a String parameter and the password as a SecureString parameter in AWS Systems Manager Parameter Store. This configuration is secure because the password is encrypted at rest using AWS KMS, and it is cost-effective because standard parameters in Systems Manager Parameter Store are free of charge, unlike AWS Secrets Manager which incurs a monthly hosting fee.

Step-by-Step Solution

Identify the security requirements for the database credentials and hostnames.

The database password must be encrypted at rest, whereas the database hostname is public and does not require encryption.

This helps determine which configuration values must be protected and which can be stored in plaintext.

Analyze the operational requirements and cost constraints.

The password is static, does not require automatic rotation, and the solution must minimize operational costs.

Since automatic rotation is not needed, Systems Manager Parameter Store is a more cost-effective choice than AWS Secrets Manager.

Select the appropriate parameter types for Parameter Store.

Use a String parameter for the hostname and a SecureString parameter for the database password.

This satisfies the security requirement for the password while keeping storage costs free by using standard parameters.

Key Concept

Distinguishing between sensitive and non-sensitive configuration data and using appropriate Parameter Store parameter types (String vs. SecureString) to optimize cost and security.

Question 1078Question →

A company is deploying a retail application on Amazon EC2 instances. The application requires access to database credentials for an Amazon RDS for MySQL database, which must be rotated automatically every 30 days to comply with security standards. Additionally, the application requires access to a static API key for an external payment gateway provider. This API key must be encrypted at rest but does not require rotation. The company wants to minimize ongoing management costs for storing these credentials. Which combination of actions should a solutions architect recommend to meet these requirements? (Select TWO.)

Select all that apply

Store the database credentials in AWS Secrets Manager, and configure automatic rotation using a built-in rotation template with an AWS Lambda function.

Store the payment gateway API key as a SecureString parameter in AWS Systems Manager Parameter Store.

Store the payment gateway API key as a String parameter in AWS Systems Manager Parameter Store to avoid KMS encryption charges.

Store the database credentials in AWS Secrets Manager, and enable automatic key rotation on the associated AWS KMS Customer Managed Key to rotate the database password.

Store both the database credentials and the payment gateway API key as String parameters in AWS Systems Manager Parameter Store to eliminate storage costs.

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager, and configure automatic rotation using a built-in rotation template with an AWS Lambda function.; Store the payment gateway API key as a SecureString parameter in AWS Systems Manager Parameter Store.

Answer

Store the database credentials in AWS Secrets Manager and configure automatic rotation using an AWS Lambda function, and store the payment gateway API key as a SecureString parameter in AWS Systems Manager Parameter Store.

The database credentials require automatic rotation, which is natively supported by AWS Secrets Manager using Lambda functions. The payment gateway API key is static, so it does not need rotation, and storing it as a SecureString parameter in AWS Systems Manager Parameter Store encrypts the data at rest using AWS KMS while avoiding the monthly per-secret cost of AWS Secrets Manager.

Step-by-Step Solution

Identify the rotation and encryption requirements for each sensitive data item.

The database credentials require regular 30-day rotation, while the payment gateway API key is static but must be encrypted.

This determines which AWS service features are necessary (e.g., automatic rotation capabilities vs. static secure storage).

Select the appropriate storage service for the database credentials.

Choose AWS Secrets Manager with a Lambda rotation function.

AWS Secrets Manager provides built-in integration with Lambda to automatically rotate database credentials without manual intervention.

Select the cost-optimized secure storage service for the static API key.

Choose AWS Systems Manager Parameter Store with the SecureString parameter type.

Parameter Store SecureString provides KMS-encrypted storage with no additional storage fees for standard parameters, making it highly cost-effective for static secrets that do not require rotation.

Key Concept

Selecting between AWS Secrets Manager and Systems Manager Parameter Store based on credential rotation and cost-optimization requirements.

Estimated Time:2m 0s

Question 1079Question →

A company hosts a data ingestion service on Amazon EC2 instances in a private subnet. The service writes $20\text{ TB}$ of data monthly to Amazon DynamoDB and sends $50\text{ GB}$ of message payloads monthly to Amazon Simple Queue Service (Amazon SQS). Currently, all outbound traffic from the private subnet is routed through a NAT Gateway. A solutions architect must design a routing solution to minimize the data transfer and processing costs associated with these services. Which architecture meets these requirements most cost-effectively?

Create Gateway VPC endpoints for both Amazon DynamoDB and Amazon SQS. Configure the route table for the private subnet to route all traffic to both services through the gateway endpoints.

Create a Gateway VPC endpoint for Amazon DynamoDB and an Interface VPC endpoint (AWS PrivateLink) for Amazon SQS. Configure the route table for the private subnet to route DynamoDB traffic through the gateway endpoint.

Create Interface VPC endpoints (AWS PrivateLink) for both Amazon DynamoDB and Amazon SQS. Configure the route table for the private subnet to route all traffic to both services through the interface endpoints.

Keep routing all traffic through the NAT Gateway, but purchase a Compute Savings Plan to offset the NAT Gateway data processing charges.

Show answer & explanation

Answer: Create a Gateway VPC endpoint for Amazon DynamoDB and an Interface VPC endpoint (AWS PrivateLink) for Amazon SQS. Configure the route table for the private subnet to route DynamoDB traffic through the gateway endpoint.

Answer

Creating a Gateway VPC endpoint for Amazon DynamoDB and an Interface VPC endpoint (AWS PrivateLink) for Amazon SQS, and routing DynamoDB traffic through the gateway endpoint.

The architecture utilizing a Gateway VPC endpoint for Amazon DynamoDB and an Interface VPC endpoint for Amazon SQS is the most cost-effective. Gateway VPC endpoints are free of charge, making them ideal for high-volume data transfers (

20\text{ TB}

/month). Amazon SQS does not support Gateway VPC endpoints, so an Interface VPC endpoint (AWS PrivateLink) must be used. Although Interface VPC endpoints incur hourly and per-gigabyte processing fees, using one for the low-volume SQS traffic (

50\text{ GB}

/month) avoids the higher NAT Gateway processing fee (

0.045\text{ USD/GB}

) and keeps the traffic private.

Step-by-Step Solution

Analyze service compatibility with VPC Endpoint types.

Amazon DynamoDB supports both Gateway and Interface VPC endpoints. Amazon SQS only supports Interface VPC endpoints (AWS PrivateLink).

Gateway endpoints are only available for Amazon S3 and Amazon DynamoDB, while other services require Interface endpoints.

Calculate and compare cost implications for high-volume DynamoDB traffic.

A Gateway endpoint for DynamoDB costs

0\text{ USD}

in data processing. An Interface endpoint for DynamoDB would charge

0.01\text{ USD/GB}

(totaling

200\text{ USD}

/month for

20\text{ TB}

). A NAT Gateway charges

0.045\text{ USD/GB}

(totaling

900\text{ USD}

/month).

Choosing Gateway VPC endpoints for supported high-volume services eliminates data processing fees.

Determine the optimal routing for low-volume SQS traffic.

Deploy an Interface VPC endpoint for SQS. For

50\text{ GB}

of data, the data processing fee is negligible (

0.50\text{ USD}

/month), which is more cost-effective than routing through a NAT Gateway or setting up alternative architectures.

Using Interface endpoints for low-volume traffic keeps the traffic private with minimal costs.

Key Concept

VPC Endpoint cost optimization and compatibility

Question 1080Question →

An online auction portal experiences performance bottlenecks during peak bidding windows. The database tier must support sudden, unpredictable write spikes of up to $12,500$ writes per second, while providing microsecond read latency for retrieving the current highest bid status. The access patterns are simple key-value lookups.

Which combination of database configurations should be implemented to meet these performance and scaling requirements? (Select TWO.)

Select all that apply

Provision an Amazon DynamoDB table and deploy Amazon DynamoDB Accelerator (DAX) to cache read requests.

Configure the DynamoDB table with on-demand capacity mode to scale writes automatically in response to sudden traffic spikes.

Use a monotonically increasing partition key, such as the timestamp of the bid, to ensure sequential write distribution across DynamoDB partitions.

Configure an Amazon RDS Multi-AZ database cluster, and route write traffic to an RDS Read Replica if the primary DB instance becomes overloaded.

Configure the DynamoDB table with a low Provisioned Capacity Mode limit to control costs, and rely on application-level retry logic to absorb write spikes.

Show answer & explanation

Answer: Provision an Amazon DynamoDB table and deploy Amazon DynamoDB Accelerator (DAX) to cache read requests.; Configure the DynamoDB table with on-demand capacity mode to scale writes automatically in response to sudden traffic spikes.

Answer

Deploying Amazon DynamoDB with on-demand capacity mode and using Amazon DynamoDB Accelerator (DAX) to cache read requests is the correct solution.

The correct solution involves configuring the database using Amazon DynamoDB with on-demand capacity mode and utilizing Amazon DynamoDB Accelerator (DAX). On-demand capacity mode handles sudden, unpredictable spikes up to

12,500

writes per second without requiring capacity planning or manual scaling. Amazon DynamoDB Accelerator (DAX) is an in-memory cache specifically built for DynamoDB that reduces read latencies to microseconds, satisfying the performance requirements for retrieving current bid statuses.

Step-by-Step Solution

Analyze the access pattern and latency requirements.

The requirements indicate key-value lookups, microsecond read latency, and millisecond-level write latency. This strongly points to Amazon DynamoDB as the core database service and Amazon DynamoDB Accelerator (DAX) to achieve microsecond read latency.

DynamoDB natively supports high-throughput key-value queries, and DAX provides in-memory caching to reduce read latency from milliseconds to microseconds.

Identify the scaling requirement for unpredictable write spikes.

On-demand capacity mode is selected to automatically scale throughput in response to sudden, unpredictable workloads.

Unlike provisioned capacity mode, which requires manual adjustment or auto-scaling policies that may lag behind rapid spikes, on-demand mode instantly accommodates workload changes.

Evaluate and eliminate incorrect configuration options.

Monotonically increasing keys, RDS Read Replicas for failover, and low provisioned capacity limits are discarded.

Monotonically increasing keys create hot partitions. RDS Read Replicas cannot serve write traffic or serve as Multi-AZ automatic failover targets. Low provisioned capacity limits cause unacceptable throttling.

Key Concept

High-performing database architectures utilizing Amazon DynamoDB, on-demand capacity scaling, and DAX caching.

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