All practice questions

1462 questions

All types1,462 Multiple choice739 Multiple select723

A logistics company is deploying a telemetry receiver API on Amazon EC2 instances. The instances are managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The API is configured to listen on TCP port 50051. The ALB is configured with an HTTPS listener that routes traffic to a target group associated with the ASG. After deploying the application, the solutions architect notices that the ALB target group shows all EC2 instances as unhealthy. The security group associated with the EC2 instances currently allows inbound traffic on port 50051 from the ALB security group, and outbound traffic to all destinations. Which combination of actions should the solutions architect take to resolve this issue and ensure the instances are marked healthy? (Select two.)

Select all that apply

Modify the target group's health check settings to use port 50051 instead of the default port.

Configure the Application Load Balancer's security group to allow outbound TCP traffic on port 50051 to the security group of the EC2 instances.

Override the target group health check port to port 80, since Elastic Load Balancing requires health check traffic to use standard web ports.

Add a rule to the subnet's Network ACL to allow inbound traffic on port 50051, as Security Groups are stateless and require explicit network-level rules to permit return traffic.

Configure an Amazon Route 53 latency routing policy to route client requests directly to the EC2 instances, bypassing the Application Load Balancer when targets are marked unhealthy.

Show answer & explanation

Answer: Modify the target group's health check settings to use port 50051 instead of the default port.; Configure the Application Load Balancer's security group to allow outbound TCP traffic on port 50051 to the security group of the EC2 instances.

Answer

Modify the target group's health check settings to use port 50051, and configure the Application Load Balancer's security group to allow outbound TCP traffic on port 50051 to the security group of the EC2 instances.

The target group must be configured to send health check requests to port 50051 because that is where the telemetry service is listening. Since the default health check port is port 80 (or the traffic port if not overridden, but here it defaults to HTTP/80), the load balancer was sending health checks to a port where no service was listening. Additionally, the Application Load Balancer's security group must be configured to allow outbound traffic to the EC2 instances on port 50051. While the EC2 instances' security group allowed inbound traffic, security groups on the load balancer must also permit the outbound connection to the targets.

Step-by-Step Solution

Analyze the health check configuration of the target group.

Identify that the default target group health check port (or port 80) does not match the application's port of 50051.

Health check requests must be routed to the port where the service is active to determine its health status.

Check the outbound security group rules for the Application Load Balancer.

Identify that the ALB security group does not allow outbound TCP traffic to the EC2 instances on port 50051.

The ALB must be permitted to initiate connections to the EC2 instances on the traffic port to perform health checks and route client traffic.

Verify security group statefulness and Network ACL rules.

Confirm that security groups are stateful, meaning outbound response traffic is allowed automatically without modifying Network ACLs.

Avoids introducing unnecessary and overly permissive Network ACL rules based on statefulness misconceptions.

Key Concept

Auto Scaling and Elastic Load Balancing (ELB) health check configurations, port overrides, and secure security group communication paths.

Estimated Time:2m 0s

Question 1082Question →

A company runs a global mobile application with backend APIs hosted on Amazon EC2 instances behind Application Load Balancers (ALBs) in both the us-west-2 and eu-central-1 regions. Under normal conditions, users should be directed to the closest region to minimize latency. If the application in one region becomes unavailable, traffic must be automatically routed to the other region. The database backend consists of an Amazon Aurora Global Database with the primary cluster in us-west-2 and a read-only secondary cluster in eu-central-1. Which configuration should the solutions architect choose to meet these requirements?

Create Route 53 Latency-based alias records pointing to the ALBs in both regions, and enable Evaluate Target Health on both records.

Create Route 53 Failover records with the us-west-2 ALB as primary and the eu-central-1 ALB as secondary, configuring a latency routing policy on the primary record.

Create Route 53 Latency-based CNAME records pointing to the ALBs, set the Time to Live (TTL) to 0 seconds, and enable Evaluate Target Health on both records.

Create Route 53 Latency-based alias records pointing to the ALBs in both regions, and rely on Route 53 to automatically promote the Amazon Aurora read replica in eu-central-1 to primary if the us-west-2 region fails.

Show answer & explanation

Answer: Create Route 53 Latency-based alias records pointing to the ALBs in both regions, and enable Evaluate Target Health on both records.

Answer

Create Route 53 Latency-based alias records pointing to the ALBs in both regions, and enable Evaluate Target Health on both records.

The correct configuration uses Route 53 Latency-based alias records pointing to the Application Load Balancers in both regions with Evaluate Target Health enabled. This ensures that users are directed to the region with the lowest latency under normal conditions. If one of the regions becomes unavailable, Route 53 detects the unhealthy status of the ALB and automatically routes subsequent DNS requests to the healthy region.

Step-by-Step Solution

Analyze the business requirements for latency and availability.

Under normal operations, traffic must route to the region with lowest latency (us-west-2 or eu-central-1), which requires an active-active configuration using Latency-based routing.

Latency-based routing ensures users are automatically directed to the AWS region that provides the lowest network latency.

Configure health checks for failover capability.

Evaluate Target Health must be enabled on the Route 53 Alias records pointing to the Application Load Balancers.

This allows Route 53 to inherit the health status of the ALBs from the load balancer target groups, preventing traffic from being sent to an unhealthy region.

Select the correct Route 53 record type.

Use Alias records instead of standard CNAME records.

Alias records are required to use the Evaluate Target Health feature and allow routing at the zone apex.

Key Concept

Combining Route 53 Latency Routing with Evaluate Target Health on Alias records allows active-active routing with automatic failover.

Question 1083Question →

A company has a web application running on Amazon EC2 instances inside an Auto Scaling group (ASG). The instances are registered with an Amazon Application Load Balancer (ALB). The application process on several instances crashes, causing the ALB target group health checks to mark those instances as unhealthy. However, the ASG does not terminate and replace the unhealthy instances. Which configuration change will ensure that the Auto Scaling group automatically replaces instances that fail the Application Load Balancer health check?

Update the Auto Scaling group health check type configuration from EC2 to ELB.

Configure an Amazon Route 53 latency routing policy with health checks to route traffic away from the unhealthy instances.

Modify the subnet's stateless Network Access Control List (NACL) outbound rules to allow return traffic on all ephemeral ports.

Change the target group health check settings to query the default HTTP port 80 instead of the custom port where the application runs.

Show answer & explanation

Answer: Update the Auto Scaling group health check type configuration from EC2 to ELB.

Answer

Update the Auto Scaling group health check type configuration from EC2 to ELB.

The correct answer is to update the Auto Scaling group's health check configuration to use ELB. By default, Auto Scaling groups only monitor EC2 status checks. If an application process crashes but the underlying EC2 instance remains running, the EC2 status checks will pass, and the Auto Scaling group will not replace the instance. Changing the health check type to ELB ensures the Auto Scaling group replaces any instance that fails the target group health checks.

Step-by-Step Solution

Analyze the current state of the Auto Scaling group's health check configuration.

The Auto Scaling group is currently configured to use only the default EC2 health check type.

By default, an Auto Scaling group only monitors EC2 status checks (such as hardware failures or operating system status) and does not automatically monitor the application-level health status reported by the Application Load Balancer.

Identify the configuration that integrates load balancer status with Auto Scaling lifecycle management.

The health check type needs to be updated to ELB.

When the ELB health check type is enabled, the Auto Scaling group will consider an instance unhealthy if either the EC2 status checks fail or the Elastic Load Balancing target group health check fails.

Implement the configuration change on the Auto Scaling group.

The Auto Scaling group automatically terminates and replaces instances when they fail the load balancer health check.

This configuration bridges the gap between the application-level checks performed by the load balancer and the lifecycle management of the Auto Scaling group.

Key Concept

Auto Scaling Group Health Check Types

Estimated Time:1m 0s

Question 1084Question →

A multinational financial services firm hosts a critical transactional API across two AWS Regions: us-east-1 (primary) and us-west-2 (disaster recovery). In both regions, the API runs on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB) and is configured to listen on custom TCP port 8443. The firm uses Amazon Route 53 with failover routing policies pointing to the ALBs via Alias records. During a simulated failover drill, the API service on the EC2 instances in us-east-1 is stopped, causing the instances to become unhealthy. However, Route 53 does not route traffic to the us-west-2 ALB, and external clients continue to receive timeout errors from us-east-1. Which configuration changes must the solutions architect implement to resolve this issue and enable automated failover?

Enable Evaluate Target Health on the Route 53 primary Alias record, and configure the ALB target group health check to query the custom application port 8443.

Change the Route 53 routing policy to Latency-based routing for both regions, and configure the ALBs to automatically redirect client traffic to the next closest region when latency spikes.

Modify the ALB target group health check port to port 80, configure a basic web server on the EC2 instances to respond to port 80 health checks, and rely on the default Route 53 health checking behavior.

Update the primary subnet Network ACL to allow inbound traffic from the Route 53 health checker IP addresses on port 8443, and configure the EC2 security group to trust Route 53 public IP ranges.

Show answer & explanation

Answer: Enable Evaluate Target Health on the Route 53 primary Alias record, and configure the ALB target group health check to query the custom application port 8443.

Answer

Enable Evaluate Target Health on the Route 53 primary Alias record, and configure the ALB target group health check to query the custom application port 8443.

The correct option is to enable Evaluate Target Health on the primary Route 53 Alias record and ensure the target group health check monitors port 8443. For an ALB Alias record, Route 53 determines health by evaluating the target group's health metrics. If 'Evaluate Target Health' is set to Yes and the target group correctly monitors the custom API port, the failure of the API service will cause all targets to become unhealthy, which in turn causes Route 53 to failover to the disaster recovery region.

Step-by-Step Solution

Analyze Route 53 Alias health evaluation behavior.

By default, Route 53 Alias records do not evaluate the health of the underlying resources (the ALB's targets) unless the 'Evaluate Target Health' parameter is explicitly set to Yes.

This is necessary because Route 53 needs permission and instructions to inspect the health of the ALB target group.

Examine the target group health check configuration.

The target group must query the port where the actual application is listening (port 8443) rather than a default port (like port 80).

If the health check port is misconfigured, the ALB may continue to report the instances as healthy even when the core API application has crashed or stopped.

Synthesize the requirements for automatic DNS failover.

Combining 'Evaluate Target Health' on the Alias record with a correct health check port configuration allows Route 53 to detect that zero healthy targets exist in the primary region's ALB target group, triggering an automatic failover to the secondary region.

Route 53 marks an ALB as unhealthy only when all targets in all associated target groups are unhealthy.

Key Concept

Route 53 DNS failover relies on the combination of Alias record health evaluation and accurate Application Load Balancer target group health checks.

Estimated Time:3m 0s

Question 1085Question →

An organization is launching an internal analytics dashboard on Amazon EC2 instances managed by an Auto Scaling group. The dashboard application is configured to run on TCP port 8080. The instances are deployed in private subnets behind an Application Load Balancer (ALB). The solutions architect has associated a custom Network ACL (NACL) with the private subnets. Although security groups are configured to allow port 8080 traffic between the ALB and the EC2 instances, the ALB target group reports all instances as unhealthy. Local testing confirms the dashboard service is responding normally on port 8080.

Which combination of steps must the solutions architect take to resolve this issue and allow the health checks to pass? (Select two.)

Select all that apply

Modify the target group's health check configuration to query port 8080 instead of the default port 80.

Add an outbound rule to the private subnet's custom Network ACL to allow TCP traffic to the load balancer subnet on ephemeral ports (1024-65535).

Add an outbound rule to the EC2 instances' security group to allow traffic on ephemeral ports (1024-65535) to the load balancer security group.

Create an Amazon Route 53 latency routing policy to route traffic directly to the private IP addresses of the EC2 instances when the load balancer health checks fail.

Change the target group port configuration to port 80 and use an Application Load Balancer listener rule to translate traffic to port 8080.

Show answer & explanation

Answer: Modify the target group's health check configuration to query port 8080 instead of the default port 80.; Add an outbound rule to the private subnet's custom Network ACL to allow TCP traffic to the load balancer subnet on ephemeral ports (1024-65535).

Answer

To resolve the unhealthy target status, the solutions architect must configure the target group health check port to 8080 and ensure the stateless Network ACL allows outbound ephemeral return traffic from the EC2 subnet to the Application Load Balancer.

The Application Load Balancer target group needs to be configured with the correct health check port (port 8080) to match the port where the dashboard application is running. By default, the health check may query port 80, which fails because the application is bound to port 8080. Additionally, since a custom Network ACL (NACL) is applied to the private subnets, outbound rules must be configured to allow return traffic. Because NACLs are stateless, they do not automatically track connections, and return traffic from the EC2 instances to the ALB must be explicitly allowed on ephemeral ports (1024-65535).

Step-by-Step Solution

Identify the port mismatch between the application and the load balancer health check configuration.

The health check port must be updated from the default (port 80) to port 8080.

The dashboard application is bound to port 8080; querying port 80 will fail as nothing is listening on it.

Analyze the custom Network ACL (NACL) configuration for the private subnets.

Add an outbound rule allowing TCP traffic on ephemeral ports (1024-65535) to the load balancer subnet.

Network ACLs are stateless, meaning return traffic from the EC2 instances to the load balancer must be explicitly permitted.

Key Concept

Auto Scaling and Elastic Load Balancing (ELB) configuration with stateless Network ACLs and custom ports

Question 1086Question →

An enterprise-grade media streaming platform is deploying a new content analytics service. The service consists of containerized microservices running on AWS Fargate in a private subnet. The application requires access to two distinct items: a non-sensitive database configuration string that changes per environment, and a highly sensitive API token used to authenticate with an external content delivery network (CDN) partner. The database configuration must be retrieved with low latency and without incurring additional request fees. The CDN API token must be encrypted at rest, rotated automatically every 30 days via a custom rotation schedule, and must never be exposed as plaintext in the Fargate task definition or console.

Which combination of actions should a solutions architect take to meet these requirements securely and cost-effectively? (Select TWO.)

Select all that apply

Store the database configuration string as a standard String parameter in AWS Systems Manager Parameter Store, and reference its Amazon Resource Name (ARN) in the ECS container definition using the valueFrom parameter to inject it as an environment variable.

Store the CDN API token in AWS Secrets Manager, configure a rotation schedule that runs a custom AWS Lambda function every 30 days, and grant the ECS task execution role permission to decrypt the secret using a Customer Managed Key.

Store the CDN API token as a standard String parameter in AWS Systems Manager Parameter Store to avoid additional storage costs, and configure an Amazon EventBridge scheduled rule to update the parameter value via a Lambda function every 30 days.

Store the CDN API token in AWS Secrets Manager, encrypt it using the AWS managed key aws/secretsmanager, and enable automatic key rotation on the KMS key to rotate the CDN API token value every 30 days.

Store the database configuration string in AWS Secrets Manager, and store the CDN API token in AWS Systems Manager Parameter Store as a SecureString parameter using the native Parameter Store automatic rotation policy.

Show answer & explanation

Answer: Store the database configuration string as a standard String parameter in AWS Systems Manager Parameter Store, and reference its Amazon Resource Name (ARN) in the ECS container definition using the valueFrom parameter to inject it as an environment variable.; Store the CDN API token in AWS Secrets Manager, configure a rotation schedule that runs a custom AWS Lambda function every 30 days, and grant the ECS task execution role permission to decrypt the secret using a Customer Managed Key.

Answer

To securely and cost-effectively manage these parameters, the solutions architect should store the non-sensitive database configuration string as a standard String parameter in Systems Manager Parameter Store and reference it in the task definition, while storing the sensitive CDN API token in Secrets Manager with automatic Lambda-based rotation and KMS decryption permissions granted to the task execution role.

The correct solution uses AWS Systems Manager Parameter Store Standard parameters for non-sensitive data (database configuration) because standard parameters are free and have no request costs. For sensitive credentials that require automatic rotation (CDN API token), the solution uses AWS Secrets Manager. Secrets Manager integrates directly with AWS Lambda for custom rotation functions. The containerized Fargate task securely accesses both via environment variables injected at runtime, using the task execution role with appropriate decrypt permissions.

Step-by-Step Solution

Analyze credential security and rotation requirements.

Identify that the CDN API token is highly sensitive and requires automatic rotation every 30 days, which aligns with AWS Secrets Manager capabilities.

Secrets Manager provides native lifecycle management and Lambda integration for custom rotation schedules.

Analyze configuration cost and latency requirements.

Identify that the database configuration string is non-sensitive and must be retrieved without request fees.

Systems Manager Parameter Store Standard parameters are free and ideal for non-sensitive configuration data.

Configure integration with AWS Fargate tasks.

Reference the Parameter Store parameter and Secrets Manager secret in the ECS container definition using the task execution role.

This prevents hardcoding credentials or configurations inside the container image or task definitions.

Key Concept

Distinguishing between AWS Secrets Manager for automated secret lifecycle management and AWS Systems Manager Parameter Store for cost-effective configuration management, while understanding the limits of KMS key rotation versus secret rotation.

Question 1087Question →

An enterprise application uses a proprietary TCP-based protocol to process transactions. The application runs on Amazon EC2 instances within private subnets, managed by an Auto Scaling group (ASG) behind a Network Load Balancer (NLB). The application daemon listens on TCP port 7001 for transaction traffic, while a separate monitoring service on the same instances listens on TCP port 7005 to report health status. Currently, the NLB target group is configured to use the TCP protocol, with the health check port set to 'traffic-port'. The target group health checks are failing, causing the NLB to mark all instances as unhealthy and prevent transaction routing. The Security Group assigned to the EC2 instances permits inbound TCP traffic on ports 7001 and 7005 from the VPC CIDR. The subnets use a custom Network Access Control List (NACL) that permits inbound TCP traffic on ports 7001 and 7005 from the VPC CIDR, but contains no outbound rules other than the default deny rule. Which combination of actions should a Solutions Architect take to resolve the health check failure and allow transactions to flow? (Select two.)

Select all that apply

Update the target group configuration to specify port 7005 as the health check port instead of using the traffic port.

Add an outbound rule to the subnet's Network ACL allowing TCP traffic to the ephemeral port range (1024–65535) to handle return traffic.

Add an outbound rule to the EC2 instances' security group allowing TCP traffic to the ephemeral port range (1024–65535) to the VPC CIDR.

Change the target group protocol to HTTP and set the health check path to /health on port 7005.

Configure a Route 53 latency routing policy to route traffic directly to the private IP addresses of the EC2 instances in the Auto Scaling group.

Show answer & explanation

Answer: Update the target group configuration to specify port 7005 as the health check port instead of using the traffic port.; Add an outbound rule to the subnet's Network ACL allowing TCP traffic to the ephemeral port range (1024–65535) to handle return traffic.

Answer

Update the target group configuration to specify port 7005 as the health check port instead of using the traffic port, and add an outbound rule to the subnet's Network ACL allowing TCP traffic to the ephemeral port range (1024–65535) to handle return traffic.

The target group must be configured to probe port 7005, which is where the health status service is running, rather than the default traffic port (port 7001). Additionally, because Network ACLs are stateless, any inbound request (such as a health check or transaction request) requires an explicit outbound rule to allow the response traffic to return to the client's or load balancer's ephemeral ports (1024–65535). Configuring these two changes resolves the communication block and allows the load balancer to accurately verify instance health and route client traffic.

Step-by-Step Solution

Analyze the health check port mismatch.

Identify that the daemon listens for transactions on port 7001 but health checks are on port 7005. Since the target group is configured to use 'traffic-port' (port 7001), the NLB is probing the wrong port, causing health check failures.

Health check probes must be sent to the port where the monitoring service is actively listening.

Analyze the Network ACL configurations.

Identify that the custom NACL has no outbound rules other than the default deny rule. Because NACLs are stateless, they do not automatically allow return traffic for established inbound connections.

To allow the EC2 instances to respond to health checks and clients, an outbound NACL rule is required to permit traffic to the ephemeral ports (1024-65535) used by the source initiators.

Evaluate the stateful nature of Security Groups.

Determine that the Security Group assigned to the EC2 instances does not need outbound rule modifications for return traffic because Security Groups are stateful and automatically allow return traffic.

Modifying security group outbound rules for ephemeral port return traffic is unnecessary and does not resolve stateless NACL blocks.

Key Concept

Auto Scaling and Elastic Load Balancing (ELB)

Estimated Time:2m 30s

Question 1088Question →

A digital publishing company hosts a web application where users download magazine issues and static images. The files are stored in an Amazon S3 bucket. To reduce download latency and S3 data transfer costs, the company deployed an Amazon CloudFront distribution in front of the S3 bucket. However, during a peak traffic event, the backend database and S3 bucket experienced high loads, and reports showed a CloudFront cache hit ratio of 0% for the static assets.

Which configuration issue explains why the static assets are not being cached at the edge locations?

The cache policy associated with the CloudFront cache behavior for static assets has its Minimum TTL, Maximum TTL, and Default TTL values set to 0 seconds.

The S3 bucket hosting the static assets is configured to transition objects to S3 Standard-Infrequent Access (S3 Standard-IA) immediately upon creation, which restricts caching.

Amazon Route 53 is configured with a latency routing policy that redirects user requests directly to the regional S3 bucket endpoints, bypassing the CloudFront caching layer.

The application database is configured to store static asset download logs in Amazon DynamoDB using partition keys structured as monotonically increasing timestamps.

Show answer & explanation

Answer: The cache policy associated with the CloudFront cache behavior for static assets has its Minimum TTL, Maximum TTL, and Default TTL values set to 0 seconds.

Answer

The cache policy associated with the CloudFront cache behavior for static assets has its Minimum TTL, Maximum TTL, and Default TTL values set to 0 seconds.

Specifying a TTL of 0 seconds on a CloudFront cache behavior tells CloudFront not to cache the objects retrieved from the origin. This results in a cache hit ratio of 0% and sends all requests directly to the origin S3 bucket, causing increased latency and higher data transfer costs.

Step-by-Step Solution

Analyze the symptom of a 0% cache hit ratio on CloudFront.

A 0% cache hit ratio indicates that CloudFront is forwarding every single incoming request for the static assets directly to the Amazon S3 origin instead of retrieving them from edge caches.

This identifies that the issue lies in the caching configuration (TTL) of the CloudFront distribution itself.

Evaluate how TTL settings control CloudFront caching behavior.

Setting the Minimum TTL, Maximum TTL, and Default TTL to 0 seconds in the CloudFront cache policy ensures that objects are never cached at edge locations.

This configuration forces CloudFront to fetch static content from S3 on every request, completely bypassing edge cache storage.

Rule out incorrect architectural changes.

S3 storage classes, Route 53 routing policies, and DynamoDB partition key structures do not control CloudFront's edge caching behavior.

While these factors affect cost, routing, and database performance respectively, they are unrelated to the CloudFront distribution's cache hit ratio.

Key Concept

CloudFront cache policy TTL settings

Estimated Time:1m 30s

Question 1089Question →

A logistics company runs a fleet tracking application that records real-time telemetry data from delivery vehicles in an Amazon DynamoDB table. The write workload is highly variable. During standard weekday operations, the table experiences a steady, predictable baseline of $300\text{ writes/second}$ . However, during a daily $30\text{-minute}$ synchronization window that occurs at random times depending on fleet arrivals, regional depots upload batch telemetry data, causing write traffic to spike instantly to $6,000\text{ writes/second}$ . The application requires immediate data visibility and cannot tolerate any write throttling or data loss. Which capacity planning strategy is the most cost-effective and meets the performance requirements?

Configure the DynamoDB table with provisioned capacity mode, enabling Auto Scaling with a minimum write capacity of

300

and a maximum of

6,000

Configure the DynamoDB table to use on-demand capacity mode.

Configure the DynamoDB table with provisioned capacity mode statically set to

6,000

write capacity units, and purchase a Compute Savings Plan to reduce the cost of the provisioned write capacity.

Migrate the telemetry database to Amazon RDS for PostgreSQL, deploying a single primary DB instance with a read replica in a different Availability Zone, and direct the application to write to the read replica if the primary instance experiences performance issues.

Show answer & explanation

Answer: Configure the DynamoDB table to use on-demand capacity mode.

Answer

Configure the DynamoDB table to use on-demand capacity mode.

Configuring the DynamoDB table to use on-demand capacity mode is the most cost-effective and reliable solution. On-demand mode handles sudden, unpredictable spikes in write traffic instantly without throttling, and only charges for the actual reads and writes consumed. This avoids the cost of statically provisioning for the peak (

6,000\text{ writes/second}

) while meeting the strict requirement of no data loss or throttling.

Step-by-Step Solution

Analyze the workload characteristics and performance requirements.

Identify that the baseline is

300\text{ writes/second}

, the peak is

6,000\text{ writes/second}

(occurring instantly and at random times), and write throttling or data loss cannot be tolerated.

Understanding the workload constraints is necessary to select the correct capacity mode.

Evaluate the suitability of DynamoDB Auto Scaling for this workload.

Determine that Auto Scaling is not suitable because it cannot scale instantly from

300

6,000\text{ writes/second}

, leading to throttling.

Auto Scaling relies on trailing CloudWatch metrics and has a reaction delay of several minutes.

Evaluate the cost-efficiency of static provisioning vs. on-demand capacity mode.

Statically provisioning

6,000\text{ WCUs}

is highly expensive and wasteful. On-demand capacity mode scales instantly and charges only for consumed capacity, which is cheaper and safer.

On-demand mode eliminates both the risk of throttling during random spikes and the high cost of overprovisioning.

Key Concept

DynamoDB On-Demand vs. Provisioned Capacity Auto Scaling for unpredictable workloads

Question 1090Question →

A company is moving an on-premises application to Amazon EC2. The application needs to retrieve a sensitive API credential for an external payment service and a non-sensitive API endpoint URL for a weather forecasting service. A solutions architect needs to design a configuration storage strategy that is secure, cost-effective, and minimizes administrative overhead.

Which combination of steps should the solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Store the payment service API credential as a SecureString parameter in AWS Systems Manager Parameter Store.

Store the weather forecasting service API endpoint URL as a String parameter in AWS Systems Manager Parameter Store.

Store the payment service API credential as a String parameter in AWS Systems Manager Parameter Store.

Store the weather forecasting service API endpoint URL as a SecureString parameter and configure AWS KMS to automatically rotate the parameter value every 24 hours.

Store the payment service API credential as a String parameter in AWS Systems Manager Parameter Store and enable KMS automatic key rotation to automatically update the credential value.

Show answer & explanation

Answer: Store the payment service API credential as a SecureString parameter in AWS Systems Manager Parameter Store.; Store the weather forecasting service API endpoint URL as a String parameter in AWS Systems Manager Parameter Store.

Answer

Store the payment service API credential as a SecureString parameter in AWS Systems Manager Parameter Store, and store the weather forecasting service API endpoint URL as a String parameter in AWS Systems Manager Parameter Store.

Storing the sensitive payment service API credential as a SecureString parameter in Systems Manager Parameter Store provides automatic encryption at rest using AWS KMS. Storing the non-sensitive weather forecasting service API endpoint URL as a standard String parameter in Parameter Store is the most secure and cost-effective approach, avoiding unnecessary KMS costs while utilizing a centralized parameter management solution.

Step-by-Step Solution

Identify the sensitivity of the configuration data.

The payment service API credential is sensitive and requires encryption, while the weather forecasting service API endpoint is non-sensitive.

This determines which storage parameters require encryption and which can be stored in plaintext.

Select the appropriate parameter type in AWS Systems Manager Parameter Store.

Use a SecureString parameter for the sensitive credential to encrypt it at rest using AWS KMS, and use a standard String parameter for the non-sensitive URL endpoint to save on overhead and encryption resource costs.

This implements the principle of least privilege and optimizes cost and management overhead.

Key Concept

AWS Systems Manager Parameter Store supports String parameters for plaintext configurations and SecureString parameters for sensitive configuration data encrypted by AWS KMS.

Question 1091Question →

A financial analytics firm processes transaction registry logs that are uploaded daily to an Amazon S3 Standard bucket. The log files average $45\text{ MB}$ in size. The logs are accessed frequently by analytics applications during the first $10$ days after upload. Between day $10$ and day $45$ , the logs are rarely accessed but must be immediately available for regulatory audits. After $45$ days, the logs are only needed for historical compliance and can be retrieved within $12$ hours. The logs must be permanently deleted after $365$ days.

Which of the following actions should a solutions architect combine in an S3 Lifecycle policy to meet these requirements in the most cost-effective manner? (Select TWO.)

Select all that apply

Transition the objects to S3 Standard-Infrequent Access (S3 Standard-IA)

10

days after the upload date.

Transition the objects to Amazon S3 Glacier Deep Archive

45

days after the upload date.

Transition the objects to S3 Standard-Infrequent Access (S3 Standard-IA)

30

days after the upload date, and then to Amazon S3 Glacier Deep Archive

45

days after the upload date.

Transition the objects to S3 Standard-Infrequent Access (S3 Standard-IA)

5

days after the upload date.

Transition the objects to Amazon S3 Glacier Flexible Retrieval

10

days after the upload date, and then to Amazon S3 Glacier Deep Archive

45

days after the upload date.

Show answer & explanation

Answer: Transition the objects to S3 Standard-Infrequent Access (S3 Standard-IA) $10$ days after the upload date.; Transition the objects to Amazon S3 Glacier Deep Archive $45$ days after the upload date.

Answer

Configure S3 Lifecycle transitions to move objects to S3 Standard-Infrequent Access (S3 Standard-IA) after

10

days, and then to Amazon S3 Glacier Deep Archive after

45

days.

The correct strategy transitions the objects to S3 Standard-Infrequent Access (S3 Standard-IA) after

10

days when frequent access ends. The files remain in S3 Standard-IA for

35

days (from day

10

to day

45

), satisfying the

30

-day minimum storage duration of S3 Standard-IA. After day

45

, transitioning the files to Amazon S3 Glacier Deep Archive minimizes storage costs while meeting the

12

-hour retrieval requirement.

Step-by-Step Solution

Analyze the active and infrequent access windows of the data pattern.

Frequent access lasts for

10

days (requires S3 Standard), followed by infrequent access with immediate availability until day

45

(requires a tier with immediate retrieval like S3 Standard-IA).

Ensures that data is kept in the correct performance tier based on active usage timelines.

Calculate the duration spent in the S3 Standard-IA tier to check for minimum duration constraints.

The duration from day

10

to day

45

35

days. This is greater than the

30

-day minimum storage duration constraint of S3 Standard-IA.

Allows us to safely transition to S3 Standard-IA without incurring early deletion or transition penalties.

Select the appropriate archiving tier for compliance storage after day

45

After

45

days, the data requires retrieval within

12

hours. Amazon S3 Glacier Deep Archive offers standard retrieval within

12

hours at the lowest storage cost.

Meets the audit recovery time objective of

12

hours while optimizing long-term storage costs.

Key Concept

Amazon S3 Lifecycle rules and storage tier minimum storage duration rules

Question 1092Question →

A solutions architect is designing a batch data processing workload running on Amazon ECS using the AWS Fargate launch type. The application requires access to a database connection string containing sensitive credentials that must be rotated every 30 days, and a non-sensitive configuration endpoint URL that remains static. The solutions architect needs to design a secure, cost-effective storage and retrieval strategy with minimal operational overhead.

Which combination of services should the solutions architect recommend to meet these requirements?

Store the database connection string and the configuration endpoint URL as standard String parameters in AWS Systems Manager Parameter Store.

Store the database connection string in AWS Secrets Manager and configure automatic rotation. Store the configuration endpoint URL as a String parameter in Systems Manager Parameter Store.

Store the database connection string as a SecureString parameter in AWS Systems Manager Parameter Store, and enable automatic key rotation on the associated AWS KMS customer managed key.

Store the database connection string directly as a plaintext environment variable in the Amazon ECS task definition, and store the configuration endpoint URL in Systems Manager Parameter Store.

Show answer & explanation

Answer: Store the database connection string in AWS Secrets Manager and configure automatic rotation. Store the configuration endpoint URL as a String parameter in Systems Manager Parameter Store.

Answer

The most secure and cost-effective approach is to store the database connection string in AWS Secrets Manager with automatic rotation enabled, and store the non-sensitive configuration endpoint URL as a String parameter in AWS Systems Manager Parameter Store.

AWS Secrets Manager is designed for storing sensitive data such as database credentials and supports built-in automatic rotation using AWS Lambda. For non-sensitive application configurations, AWS Systems Manager Parameter Store is a cost-effective and low-overhead solution when using standard String parameters. Combining both services optimizes cost while meeting security and operational requirements.

Step-by-Step Solution

Analyze security and rotation requirements for the sensitive database credentials.

The database connection string is highly sensitive and requires automatic rotation every 30 days. AWS Secrets Manager is the optimal choice as it natively integrates database credential rotation using AWS Lambda.

Secrets Manager provides built-in lifecycle management and rotation features, whereas Systems Manager Parameter Store does not natively orchestrate database-side rotation out of the box.

Evaluate storage and cost requirements for the non-sensitive configuration URL.

The configuration endpoint URL is non-sensitive and static. AWS Systems Manager Parameter Store using standard String parameters is free of charge and requires minimal overhead.

Using Secrets Manager for non-sensitive, static configs adds unnecessary monthly costs ($0.40 per secret) and API call overhead, which violates cost-optimization principles.

Combine the storage choices into a unified architecture.

Integrate AWS Secrets Manager (for connection strings) and Systems Manager Parameter Store (for static URLs) with the ECS task definition.

This hybrid approach leverages the strength of each service, securing sensitive resources while minimizing AWS expenditure.

Key Concept

Selecting between AWS Secrets Manager and Systems Manager Parameter Store based on data sensitivity, rotation needs, and cost efficiency.

Question 1093Question →

A retail company wants to continuously monitor its AWS accounts and workloads for malicious activity, including potential cryptocurrency mining and unauthorized API usage. The solution must require minimal operational overhead and provide automated threat intelligence. Which AWS service should a solutions architect recommend to meet these requirements?

AWS Shield

Network Access Control Lists (Network ACLs)

Amazon GuardDuty

AWS WAF

Show answer & explanation

Answer: Amazon GuardDuty

Answer

Amazon GuardDuty is the correct AWS service to recommend because it provides intelligent threat detection and continuous monitoring for malicious activities like cryptocurrency mining and unauthorized API usage.

Amazon GuardDuty continuously monitors AWS accounts and workloads using data sources like VPC Flow Logs, CloudTrail management events, and DNS logs. It uses machine learning, anomaly detection, and threat intelligence to identify malicious activities like cryptocurrency mining or unauthorized access, satisfying the requirements with minimal operational overhead.

Step-by-Step Solution

Analyze the requirement for continuous, automated, account-wide monitoring for threats like cryptocurrency mining and unauthorized API activity.

Determine that the required service must perform threat detection and behavioral analysis, rather than simple network traffic filtering.

Understanding the monitoring scope helps eliminate basic firewalls and network security controls.

Evaluate AWS security services to find one designed for continuous intelligence monitoring and automated detection.

Identify Amazon GuardDuty as the dedicated managed service that uses machine learning and threat intelligence feeds to monitor AWS logs for anomalous and malicious behavior.

Matching the specific business need to the specialized AWS security service ensures compliance with the AWS Well-Architected framework.

Key Concept

Continuous security monitoring and threat detection using Amazon GuardDuty

Question 1094Question →

A solutions architect is designing the database backend for a new multiplayer online game. The matchmaking system requires sub-millisecond read latency for fetching player state and matching profiles, and it must support a write throughput of $15{}000$ writes per second during peak hours. Player profiles are updated frequently with new match statistics. The database must also support automatic failover across Multiple Availability Zones (Multi-AZ) with minimal downtime. Which database architecture should the solutions architect recommend to meet these requirements?

Configure an Amazon DynamoDB table with DynamoDB Accelerator (DAX) for caching, utilizing a composite primary key consisting of a hashed player ID as the partition key and a game session ID as the sort key.

Configure an Amazon DynamoDB table with DynamoDB Accelerator (DAX) using a partition key based on the player registration timestamp formatted as YYYY-MM-DD-HH.

Configure an Amazon RDS for PostgreSQL database with a read replica in a second Availability Zone to serve as the primary automatic failover target, paired with Amazon ElastiCache for Redis.

Configure an Amazon DynamoDB table with DynamoDB Accelerator (DAX) using Provisioned Capacity Mode set to a fixed

15{}000

Write Capacity Units (WCUs).

Show answer & explanation

Answer: Configure an Amazon DynamoDB table with DynamoDB Accelerator (DAX) for caching, utilizing a composite primary key consisting of a hashed player ID as the partition key and a game session ID as the sort key.

Answer

The configuration utilizing Amazon DynamoDB with DynamoDB Accelerator (DAX) and a composite key based on a hashed player ID is correct. DynamoDB natively replicates data across multiple Availability Zones, and DAX delivers sub-millisecond read latency for player profile lookups. A hashed partition key provides high cardinality, distributing the write load of

15{}000

writes per second evenly across partitions.

Step-by-Step Solution

Analyze the read latency and write throughput requirements.

Reads require sub-millisecond latency (pointing to caching like DAX or ElastiCache), and writes require high throughput (

15{}000

writes per second).

To narrow down the database service and caching layers that can handle the target metrics.

Evaluate partition key design for the high write volume.

A partition key must distribute write traffic evenly across physical DynamoDB partitions to avoid hot keys.

Monotonically increasing keys like timestamps create write hotspots, whereas hashed identifiers ensure horizontal scalability.

Assess high availability and automatic failover requirements.

DynamoDB inherently provides Multi-AZ replication and automatic failover, whereas RDS requires a Multi-AZ deployment rather than relying on read replicas for disaster recovery.

To ensure the architecture is resilient and meets SAA best practices for high availability.

Key Concept

Selecting and configuring high-performance database architectures with appropriate caching and partition key strategies to avoid bottlenecks.

Estimated Time:2m 0s

Question 1095Question →

A company is designing a disaster recovery (DR) architecture for a web application using an active-passive strategy. The primary environment runs on Amazon EC2 instances behind an Application Load Balancer (ALB) in the us-east-1 Region. The secondary environment consists of a static maintenance page hosted on an Amazon S3 bucket configured for website hosting in the us-west-2 Region. The company wants to use Amazon Route 53 to automatically redirect user traffic to the maintenance page if the primary environment becomes unavailable. Which two configurations must the solutions architect implement to achieve this goal? (Select TWO.)

Select all that apply

Configure a primary Failover alias record pointing to the Application Load Balancer in us-east-1, and set Evaluate Target Health to Yes.

Configure a secondary Failover alias record pointing to the Amazon S3 bucket website endpoint in us-west-2.

Configure a primary Failover CNAME record pointing to the Application Load Balancer DNS name, and set Evaluate Target Health to Yes.

Configure a primary Latency alias record pointing to the Application Load Balancer, and set a custom TTL of 60 seconds to speed up DNS failover.

Configure a Route 53 health check that monitors the database tier and automatically promotes the Amazon RDS Read Replica in us-west-2 during a failover.

Show answer & explanation

Answer: Configure a primary Failover alias record pointing to the Application Load Balancer in us-east-1, and set Evaluate Target Health to Yes.; Configure a secondary Failover alias record pointing to the Amazon S3 bucket website endpoint in us-west-2.

Answer

Configure a primary Failover alias record pointing to the Application Load Balancer in us-east-1 with Evaluate Target Health set to Yes, and configure a secondary Failover alias record pointing to the Amazon S3 bucket website endpoint in us-west-2.

To implement active-passive failover using Amazon Route 53, the Solutions Architect must create a primary Failover alias record pointing to the Application Load Balancer (ALB) and enable 'Evaluate Target Health'. When Evaluate Target Health is set to Yes, Route 53 inherits the health status of the ALB and its backend targets. The architect must also configure a secondary Failover alias record pointing to the Amazon S3 static website endpoint. Under normal conditions, Route 53 routes all queries to the primary ALB. If the ALB becomes unhealthy, Route 53 automatically switches routing to the secondary S3 website endpoint.

Step-by-Step Solution

Configure the primary routing endpoint.

A primary Failover alias record is created pointing to the primary ALB.

Alias records allow Route 53 to natively route traffic to AWS resources like an ALB without extra query charges. Setting 'Evaluate Target Health' to Yes tells Route 53 to monitor the health of the ALB and its targets.

Configure the secondary routing endpoint.

A secondary Failover alias record is created pointing to the Amazon S3 static website endpoint.

This establishes the active-passive DR pair, ensuring traffic shifts to the static page when the primary record is determined to be unhealthy.

Key Concept

Active-passive DNS failover using Route 53 Failover routing policies and Alias records with target health evaluation.

Question 1096Question →

A company hosts a secure financial transaction processing service on Amazon EC2 instances managed by an Auto Scaling group (ASG). The instances are registered with a target group for an Application Load Balancer (ALB). The application listens on port 8443. However, due to security compliance, the application health check endpoint runs on a separate administrative service on port 8080 on the same instances. The target group is configured with the port set to 8443, and the health check port is set to the default 'traffic-port'. The EC2 instances are in private subnets, while the ALB is in public subnets. Custom Network ACLs (NACLs) are applied to both subnets. The security groups are configured to allow port 8443 and port 8080 inbound from the ALB security group, and outbound security groups are configured to allow all traffic. After deployment, the ALB marks all targets as unhealthy, and the ASG begins continuously terminating and replacing the instances. Which combination of actions will resolve this issue? (Select two.)

Select all that apply

Modify the target group's health check configuration to explicitly set the health check port to 8080.

Add an outbound rule to the private subnet's Network ACL allowing traffic to the public subnets on ephemeral ports (1024-65535).

Change the target group port configuration to 8080 and keep the health check port set to the default traffic-port.

Modify the security group of the EC2 instances to allow outbound traffic to the ALB security group on ephemeral ports (1024-65535).

Configure a Route 53 latency routing policy with target health evaluation enabled pointing directly to the private IP addresses of the EC2 instances.

Show answer & explanation

Answer: Modify the target group's health check configuration to explicitly set the health check port to 8080.; Add an outbound rule to the private subnet's Network ACL allowing traffic to the public subnets on ephemeral ports (1024-65535).

Answer

To resolve the health check failure, you must override the target group health check port configuration to explicitly probe port 8080, and add an outbound rule to the private subnet's Network ACL to permit return traffic to the public subnets on ephemeral ports (1024-65535).

The correct options are the actions to modify the target group's health check configuration to explicitly set the health check port to port 8080, and to add an outbound rule to the private subnet's Network ACL allowing traffic to the public subnets on ephemeral ports (1024-65535). Overriding the health check port is necessary because the target group traffic port (8443) does not host the health check service. Furthermore, because Network ACLs are stateless, an outbound rule is required on the private subnet to permit the return traffic initiated by the load balancer, which falls within the ephemeral port range.

Step-by-Step Solution

Analyze the target group configuration and locate the port mismatch.

The target group is configured to forward client traffic to port 8443, but the health check port is set to 'traffic-port'. This causes the ALB to probe port 8443 for health checks, whereas the administrative service only listens on port 8080.

By default, the target group uses the traffic port for health checks unless overridden.

Identify the remedy for the health check port mismatch.

Modify the target group settings to override the health check port, changing it from 'traffic-port' to 8080.

This directs the ALB health probes to the correct service running on the instances.

Evaluate the network filtering layer for potential blocks.

Since the ALB is in the public subnets and the EC2 instances are in the private subnets with custom Network ACLs, we must assess NACL rules. Security groups are stateful and allow return traffic automatically, but Network ACLs are stateless.

Stateless filters require explicit rules for both inbound request traffic and outbound return traffic.

Formulate the correct Network ACL configuration.

Ensure the private subnet's Network ACL has an outbound rule allowing traffic back to the public subnets (where the ALB resides) on ephemeral ports (1024-65535).

When the ALB establishes a connection to the backend target, the response traffic from the target is sent back using the ephemeral port range of the client (the ALB).

Key Concept

Configuring load balancer health checks on custom ports requires overriding the target group health check settings, and ensuring stateless network filters (Network ACLs) are configured to permit return traffic on ephemeral ports.

Estimated Time:3m 0s

Question 1097Question →

A company hosts a web application on Amazon EC2 instances in an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application listens on custom port $8443$ for HTTPS traffic. The target group is configured to forward traffic to port $8443$ . Although the application is running normally and accepting connections locally, the ALB is marking all EC2 instances as unhealthy. The EC2 instance security group allows inbound traffic on port $8443$ from the ALB security group. Which of the following is the most likely cause of this issue?

The security group for the EC2 instances does not have an outbound rule allowing response traffic on port

8443

to the Application Load Balancer.

The Route 53 latency-based routing policy is failing to route health check traffic to the healthy instances because health checking is disabled in Route 53.

The target group's health check configuration is using the default protocol port of

80

instead of

8443

or the 'traffic-port' setting.

The Network ACL associated with the Application Load Balancer subnets does not have an inbound rule allowing return traffic on port

8443

from the EC2 subnets.

Show answer & explanation

Answer: The target group's health check configuration is using the default protocol port of $80$ instead of $8443$ or the 'traffic-port' setting.

Answer

The target group's health check configuration is using the default protocol port of

80

instead of

8443

or the 'traffic-port' setting.

The correct answer states that the target group's health check is misconfigured to use the default protocol port of

80

. In AWS Elastic Load Balancing, target groups default to performing health checks on the protocol's standard port (such as port

80

for HTTP) unless they are explicitly configured to use a custom port or the 'traffic-port' setting. Since the web application is only listening on port

8443

, health check probes sent to port

80

fail, leading the ALB to identify the targets as unhealthy.

Step-by-Step Solution

Analyze the application port settings and target group settings.

The application listens on port

8443

, the target group forwards traffic to port

8443

, and the EC2 security group allows inbound traffic on port

8443

from the ALB.

This confirms that the application is reachable on its listening port from the ALB, meaning the issue must be related to health check configurations or misconfigured network filters.

Examine target group default behaviors for health checks.

By default, the target group health check uses the default protocol port (

80

for HTTP) unless explicitly configured otherwise.

Since the application only runs on port

8443

, health checks sent to port

80

will not be answered, causing the ALB to mark the instances as unhealthy.

Evaluate network configuration distractors regarding statefulness.

Security groups are stateful, so no outbound rule is needed on the EC2 instances. Network ACLs are stateless, but return traffic from the EC2 targets back to the ALB uses ephemeral ports (

1024

65535

), not port

8443

This rules out security group and Network ACL configuration misconceptions as the root cause of the unhealthy status.

Key Concept

ELB Target Group Health Check Port configuration and its default protocol port behavior.

Estimated Time:1m 30s

Question 1098Question →

A solutions architect is deploying a web application on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application runs on a custom port 8080. The security group of the EC2 instances allows inbound traffic only from the ALB's security group on port 8080. The solutions architect needs to configure the environment so that unhealthy instances are automatically detected and replaced by the ASG. Which TWO configurations should the solutions architect perform to meet these requirements? (Select TWO.)

Select all that apply

Configure the target group health check port to use the traffic port or port 8080.

Configure the Auto Scaling group to use Elastic Load Balancing (ELB) health checks.

Keep the default target group health check port 80 and let the load balancer automatically forward the health checks to port 8080.

Modify the subnet's stateless Network ACL (NACL) to automatically track and allow return traffic from the load balancer's health checks.

Configure an Amazon Route 53 Latency routing policy to target the private IP addresses of the EC2 instances directly for health checks.

Show answer & explanation

Answer: Configure the target group health check port to use the traffic port or port 8080.; Configure the Auto Scaling group to use Elastic Load Balancing (ELB) health checks.

Answer

Configure the target group health check port to use the traffic port or port 8080, and configure the Auto Scaling group to use Elastic Load Balancing (ELB) health checks.

To ensure correct application health detection and automatic recovery, the Solutions Architect must perform two actions. First, the Application Load Balancer target group must perform health checks on the actual port where the application is listening (port 8080) because the security group blocks other ports such as the default port 80. Second, the Auto Scaling group must have its health check type set to 'ELB' so it can receive health check failures from the load balancer and automatically replace unhealthy instances.

Step-by-Step Solution

Align the Target Group health check port with the application's listening port.

The target group health checks are sent to port 8080, which is allowed by the security group and listened to by the web server.

By default, target groups run health checks on the traffic port or port 80. Since the custom application port is 8080 and security groups block port 80, the default checks would fail.

Enable ELB health checks in the Auto Scaling group configuration.

The Auto Scaling group receives health status updates from the Application Load Balancer target group.

By default, the ASG only uses EC2 status checks (hardware/system level). It must be explicitly configured to use ELB health checks so that application-level failures detected by the ALB prompt the replacement of unhealthy instances.

Key Concept

ELB health checks integrated with Auto Scaling groups for custom application ports.

Question 1099Question →

A company is developing a high-throughput financial ledger application running on Amazon EKS across multiple AWS accounts. The containerized application pods need access to:
1. A third-party payment gateway API password that must be encrypted at rest and rotated automatically every 45 days.
2. Regional service endpoint URLs (non-sensitive) that must be retrieved with minimal latency and zero additional storage cost.
Additionally, the security team requires that the AWS KMS customer managed key (CMK) used to encrypt the credentials must be rotated annually. The operations team incorrectly believes that this annual rotation will automatically decrypt and re-encrypt all historical database backups and secrets logs using the new key version.

Which combination of configurations should a solutions architect recommend to satisfy these requirements?

Store the database password in AWS Secrets Manager with automatic rotation configured for 45 days, and retrieve it using the AWS Secrets Manager CSI provider. Store the endpoint URLs as String parameters in AWS Systems Manager Parameter Store. Enable automatic key rotation for the KMS CMK, and clarify to the team that key rotation does not re-encrypt historical data, which remains decryptable using the archived key version.

Store the database password as a String parameter in AWS Systems Manager Parameter Store to minimize cost, and retrieve it using an EKS startup script. Store the endpoint URLs in AWS Secrets Manager. Enable automatic key rotation for the KMS CMK, and clarify to the team that key rotation does not re-encrypt historical data, which remains decryptable using the archived key version.

Store the database password in AWS Secrets Manager with automatic rotation configured for 45 days, and retrieve it using the AWS Secrets Manager CSI provider. Store the endpoint URLs as String parameters in AWS Systems Manager Parameter Store. Enable automatic key rotation for the KMS CMK, and advise the team that the KMS service will automatically run a background process to decrypt and re-encrypt all historical transaction data under the new key version.

Store both the database password and the endpoint URLs as String parameters in AWS Systems Manager Parameter Store to avoid Secrets Manager monthly fees. Enable automatic key rotation for the KMS CMK, and advise the team that the KMS service will automatically run a background process to decrypt and re-encrypt all historical transaction data under the new key version.

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager with automatic rotation configured for 45 days, and retrieve it using the AWS Secrets Manager CSI provider. Store the endpoint URLs as String parameters in AWS Systems Manager Parameter Store. Enable automatic key rotation for the KMS CMK, and clarify to the team that key rotation does not re-encrypt historical data, which remains decryptable using the archived key version.

Answer

Store the database password in AWS Secrets Manager with automatic rotation, store the endpoint URLs in AWS Systems Manager Parameter Store as String parameters, and enable KMS key rotation while clarifying that historical data is not automatically re-encrypted.

The correct configuration uses AWS Secrets Manager for the database password to leverage automatic 45-day rotation and secure EKS integration. Non-sensitive endpoint URLs are stored as String parameters in Parameter Store for zero storage cost. Enabling KMS key rotation is recommended, but the solutions architect must clarify that KMS does not automatically re-encrypt historical data; instead, it retains the old key version to allow decryption of existing data.

Step-by-Step Solution

Determine the storage for sensitive credentials requiring automatic rotation.

AWS Secrets Manager is chosen for the database password because it natively supports automatic rotation (e.g., using AWS Lambda) and integrates with EKS via the CSI provider.

Parameter Store does not natively manage secrets rotation lifecycles, and Secrets Manager is designed specifically for securing and rotating credentials.

Determine the storage for non-sensitive regional endpoints.

AWS Systems Manager Parameter Store with the String data type is selected.

String parameters in Parameter Store are free of charge for standard parameters and provide low-latency configuration retrieval, minimizing costs for non-sensitive data.

Analyze KMS Key Rotation behavior for customer managed keys (CMKs).

Explain that enabling automatic key rotation creates a new backing key version for new encryption operations, but does not re-encrypt existing historical data.

Historical data remains encrypted with the previous backing key version, which AWS KMS automatically retains to decrypt older data when requested.

Key Concept

AWS Secrets Manager is preferred for credentials requiring automated rotation. AWS Systems Manager Parameter Store offers a cost-effective solution for non-sensitive configurations. AWS KMS key rotation creates a new key version for future operations but does not re-encrypt existing data.

Estimated Time:2m 30s

Question 1100Question →

A company is designing a cost-effective architecture for a new application workload. The workload consists of the following components:

* A web application backend with a constant, predictable baseline of $10$ Amazon EC2 instances running $24/7$ , which scales up to $30$ instances during peak hours.
* An offline data processing pipeline that runs daily for $6$ hours, performs idempotent tasks, and can tolerate interruptions.
* A metadata store running on Amazon DynamoDB that receives highly unpredictable, spiky write requests from mobile clients.

Which two strategies should the solutions architect recommend to minimize costs while meeting these requirements? (Choose two.)

Select all that apply

Purchase EC2 Instance Savings Plans to cover the baseline of

10

EC2 instances.

Use Spot Instances to run the offline data processing pipeline.

Purchase Compute Savings Plans to cover the Amazon DynamoDB metadata store writes.

Migrate the offline data processing pipeline to AWS Lambda to run continuously for the

6

-hour duration.

Configure the Amazon DynamoDB table with Provisioned Capacity mode to handle the spiky write requests.

Show answer & explanation

Answer: Purchase EC2 Instance Savings Plans to cover the baseline of $10$ EC2 instances.; Use Spot Instances to run the offline data processing pipeline.

Answer

Purchase EC2 Instance Savings Plans to cover the baseline of

10

EC2 instances, and use Spot Instances to run the offline data processing pipeline.

The correct options are to purchase EC2 Instance Savings Plans for the

10

baseline EC2 instances, and to use Spot Instances for the interruptible,

6

-hour offline data processing pipeline. EC2 Instance Savings Plans offer significant savings for predictable, continuous

24/7

compute. Spot Instances offer the lowest cost for batch processing jobs that can tolerate interruptions.

Step-by-Step Solution

Analyze the baseline web application requirements.

The baseline of

10

EC2 instances runs

24/7

continuously and predictably, making it eligible for commitment-based discounts.

EC2 Instance Savings Plans provide up to

72\%

discount for a steady state commitment.

Analyze the offline data processing pipeline requirements.

The pipeline runs for

6

hours daily, performs idempotent tasks, and tolerates interruptions.

Spot Instances are ideal for fault-tolerant, interruptible workloads, providing the highest possible cost savings (up to

90\%

Analyze the database/metadata store requirements.

DynamoDB receives unpredictable, spiky write requests.

On-Demand capacity mode should be used to avoid over-provisioning or throttling costs. Compute Savings Plans do not apply to DynamoDB.

Key Concept

Selecting cost-optimized compute purchasing options (Savings Plans, Spot Instances) based on workload predictability and fault tolerance.

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