All practice questions

1462 questions

All types1,462 Multiple choice739 Multiple select723

A solutions architect is configuring network security for Amazon EC2 instances in a VPC. The instances must receive inbound HTTPS traffic from the internet and be able to send outbound requests to download updates. Which two statements correctly describe the behavior of security groups and network access control lists (network ACLs) for this traffic? (Select TWO.)

Select all that apply

A security group is stateful, which means allowing inbound HTTPS traffic automatically allows the return outbound traffic.

A network ACL is stateless, which means allowing inbound HTTPS traffic requires an outbound rule to allow return traffic on ephemeral ports.

A security group is stateless, so an outbound rule must be configured to allow return traffic for the inbound HTTPS connections.

A network ACL is stateful, which means allowing inbound HTTPS traffic automatically allows the return outbound traffic.

Security groups operate at the subnet level to protect all instances, while network ACLs operate at the individual network interface level.

Show answer & explanation

Answer: A security group is stateful, which means allowing inbound HTTPS traffic automatically allows the return outbound traffic.; A network ACL is stateless, which means allowing inbound HTTPS traffic requires an outbound rule to allow return traffic on ephemeral ports.

Answer

Security groups are stateful (allowing inbound traffic automatically allows the return outbound traffic) and network ACLs are stateless (allowing inbound traffic requires an outbound rule to allow return traffic on ephemeral ports).

Security groups are stateful firewalls. When you allow inbound HTTPS traffic, the security group tracks the connection state and automatically permits return traffic outbound. Conversely, network ACLs are stateless and do not track connection states. Therefore, allowing inbound traffic requires an explicit outbound rule to permit return traffic, which typically utilizes ephemeral ports.

Step-by-Step Solution

Analyze the stateful behavior of AWS Security Groups.

Security groups are stateful, meaning any inbound traffic allowed on a port (like port 443 for HTTPS) automatically allows the corresponding return outbound traffic on ephemeral ports.

This determines if security groups need explicit outbound rules for return traffic.

Analyze the stateless behavior of AWS Network ACLs.

Network ACLs are stateless, meaning they do not track connection states. Inbound traffic allowed must also be explicitly allowed outbound (usually using ephemeral ports 1024-65535) to let response packets return.

This determines if network ACLs need explicit outbound rules for return traffic.

Evaluate the scoping level of Security Groups and Network ACLs.

Security groups operate at the instance/network interface level, whereas network ACLs operate at the subnet level as a firewall.

This verifies the boundaries and application scope of both security mechanisms.

Key Concept

Stateful security groups vs stateless network ACLs

Question 1042Question →

A company runs a web application on Amazon EC2 instances behind an Application Load Balancer (ALB). The EC2 instances are managed by an Auto Scaling group. The web application is configured to listen on custom port 8080. However, the ALB is currently marking all instances in the target group as unhealthy, preventing users from accessing the application. A solutions architect verifies that the application is running normally on the instances. Which action should the solutions architect take to resolve this issue?

Configure the target group to forward traffic and run health checks on port 80.

Update the ALB target group's health check configuration to use port 8080.

Create a stateful Network Access Control List (NACL) rule allowing traffic on port 80 to enable the return traffic from the health checks.

Change the Amazon Route 53 routing policy to Latency routing to distribute traffic directly to the instances.

Show answer & explanation

Answer: Update the ALB target group's health check configuration to use port 8080.

Answer

Update the ALB target group's health check configuration to use port 8080.

Updating the health check port to 8080 allows the Application Load Balancer to perform health checks directly against the port where the web application is listening, correctly identifying the instances as healthy.

Step-by-Step Solution

Identify the port on which the web application is listening on the EC2 instances.

The application listens on custom port 8080.

This is the actual port where health checks must be directed to confirm application availability.

Compare this with the load balancer health check configuration.

The default health check configuration queries port 80, which is not receiving any response from the instances.

This mismatch explains why the ALB is reporting the instances as unhealthy.

Modify the target group's health check settings.

The health checks are updated to query port 8080.

This ensures the ALB validates the application's actual listening port, restoring the healthy status of the instances.

Key Concept

Aligning Elastic Load Balancing health checks with custom application ports

Estimated Time:1m 0s

Question 1043Question →

An organization's software application requires access to two configurations: a static partner API token that does not change, and a backend database password that must rotate automatically every 45 days. The organization wants a cost-effective solution that keeps both secrets encrypted at rest. Which two actions should a solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Store the database password in AWS Secrets Manager and configure automatic rotation.

Store the static partner API token as a SecureString parameter in AWS Systems Manager Parameter Store.

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

Store the database password as a SecureString parameter in AWS Systems Manager Parameter Store and enable automatic rotation on the default aws/ssm KMS key.

Store the static partner API token as a String parameter in AWS Systems Manager Parameter Store and restrict access using a custom IAM policy.

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and configure automatic rotation.; Store the static partner API token as a SecureString parameter in AWS Systems Manager Parameter Store.

Answer

Store the database password in AWS Secrets Manager and configure automatic rotation, and store the static partner API token as a SecureString parameter in AWS Systems Manager Parameter Store.

AWS Secrets Manager is ideal for credentials that require lifecycle management and automatic rotation. Storing the static partner API token as a SecureString parameter in AWS Systems Manager Parameter Store is the most cost-effective and secure method for static secrets that do not require rotation.

Step-by-Step Solution

Analyze the requirements for the static partner API token.

The token is static, does not require automatic rotation, but must be encrypted at rest. Standard parameters of type SecureString in AWS Systems Manager Parameter Store provide free, secure, encrypted storage.

Parameter Store is more cost-effective than AWS Secrets Manager for secrets that do not require rotation.

Analyze the requirements for the database password.

The password requires automatic rotation every 45 days. AWS Secrets Manager natively integrates with AWS Lambda to rotate credentials automatically.

AWS Systems Manager Parameter Store does not natively support automatic rotation of secrets, making AWS Secrets Manager the correct choice for this requirement.

Key Concept

Choosing between AWS Secrets Manager and AWS Systems Manager Parameter Store based on rotation requirements and cost.

Question 1044Question →

An enterprise is deploying a high-volume payment processing application on Amazon ECS using the AWS Fargate launch type. The application requires access to a sensitive API key for a third-party payment gateway. The API key must be encrypted at rest using a customer managed key (CMK) in AWS Key Management Service (AWS KMS) and must be rotated every 90 days. The application tasks scale dynamically, launching and terminating thousands of containers daily, and the application queries the third-party gateway frequently, which requires reading the API key multiple times per minute. The solutions architect must design a secure, cost-effective secrets management solution that automates key rotation with zero downtime. Which combination of actions should the solutions architect recommend to meet these requirements? (Select TWO.)

Select all that apply

Store the API key as a secret in AWS Secrets Manager, and configure a custom AWS Lambda function to rotate the API key every 90 days.

Use the AWS Secrets Manager client-side caching library in the ECS application containers to retrieve and cache the API key.

Store the API key as a plaintext String parameter in AWS Systems Manager Parameter Store to avoid Secrets Manager storage costs, and enable automatic key rotation on the AWS KMS customer managed key.

Enable automatic rotation on the AWS KMS customer managed key to automatically update the API key value and re-encrypt the secret in Secrets Manager every 90 days.

Store the API key as a SecureString parameter in AWS Systems Manager Parameter Store, and configure the AWS KMS customer managed key to automatically trigger a Lambda function to rotate the parameter when the key is rotated.

Show answer & explanation

Answer: Store the API key as a secret in AWS Secrets Manager, and configure a custom AWS Lambda function to rotate the API key every 90 days.; Use the AWS Secrets Manager client-side caching library in the ECS application containers to retrieve and cache the API key.

Answer

Store the API key as a secret in AWS Secrets Manager with a custom AWS Lambda function for rotation, and implement the client-side caching library in the ECS application containers to minimize API call costs.

The correct solution uses AWS Secrets Manager to store the secret and a custom AWS Lambda function to orchestrate rotation because Secrets Manager lacks a built-in template for custom third-party APIs. To optimize API costs and latency under high container scaling and frequent API requests, client-side caching should be implemented in the ECS container code, allowing the container to fetch the secret from a local memory cache rather than querying the AWS Secrets Manager API and KMS decrypt operation on every request.

Step-by-Step Solution

Store the sensitive API key securely using AWS Secrets Manager.

The secret is encrypted at rest using the specified AWS KMS Customer Managed Key (CMK).

Secrets Manager provides secure storage and native integration with KMS for encrypting secrets.

Implement a custom AWS Lambda function to manage secret rotation.

The API key is rotated every 90 days by calling the third-party payment gateway's API and updating the secret value in Secrets Manager.

Since the API key belongs to a third-party gateway, there is no built-in Secrets Manager rotation template, necessitating custom Lambda code.

Implement client-side caching within the ECS container application using the AWS Secrets Manager caching library.

Frequent lookups of the secret are served from the local cache instead of making remote API calls to Secrets Manager and AWS KMS.

Caching drastically reduces API invocation costs and database latency under high query volumes and dynamic scaling conditions.

Key Concept

Secrets management and key rotation for third-party integrations with cost optimization.

Question 1045Question →

A logistics tracking application ingests real-time GPS telemetry data from fleet vehicles. The backend processing service runs on Amazon EC2 instances in an Auto Scaling group (ASG) located in private subnets behind an Application Load Balancer (ALB) in public subnets. The backend service listens on TCP port 9000. The ALB uses an HTTPS listener on port 443 and forwards requests to a target group configured to use port 9000.

To satisfy a new security policy, a network administrator modified the Network Access Control List (NACL) of the private subnets to allow inbound traffic from the public subnets only on port 9000. Shortly after this modification, the ALB marks all EC2 instances as unhealthy, and the ASG begins repeatedly terminating and replacing them. Local system logs show that the application is running and listening on port 9000 successfully on all instances.

Which configuration change will resolve this issue and restore high availability?

Configure the target group's health check settings to use port 443 instead of port 9000 to match the Application Load Balancer's public-facing listener port.

Add a rule to the security group of the EC2 instances to allow outbound traffic to the public subnets on ports 1024-65535, because security groups require explicit outbound rules for return traffic.

Modify the network ACL of the private subnet to allow outbound traffic to the public subnets on ephemeral ports (1024-65535) to permit return traffic for the health checks.

Change the Amazon Route 53 DNS routing policy to Latency routing with target health evaluation enabled, directing client traffic to bypass the Application Load Balancer.

Show answer & explanation

Answer: Modify the network ACL of the private subnet to allow outbound traffic to the public subnets on ephemeral ports (1024-65535) to permit return traffic for the health checks.

Answer

Modify the network ACL of the private subnet to allow outbound traffic to the public subnets on ephemeral ports (1024-65535) to permit return traffic for the health checks.

The correct configuration change is to modify the network ACL of the private subnet to allow outbound traffic to the ephemeral ports. Network Access Control Lists (NACLs) are stateless, which means that return traffic must be explicitly allowed by an outbound rule. When the Application Load Balancer performs health checks or forwards traffic to the EC2 instances on port 9000, the instances attempt to respond using a destination port from the ephemeral range (1024-65535). Since the outbound NACL is blocking this return traffic, the ALB receives no response and marks the targets as unhealthy, causing the Auto Scaling group to replace them.

Step-by-Step Solution

Analyze the stateful vs. stateless nature of the security controls applied to the EC2 instances.

Recognize that security groups are stateful, meaning they track connection states and automatically allow return traffic. Network Access Control Lists (NACLs) are stateless, requiring explicit rules for both inbound and outbound directions.

Correctly identifying which security boundary is blocking the response traffic is essential for implementing the correct fix.

Determine the path of the Load Balancer health checks and how return traffic is routed.

The Application Load Balancer sends health check requests to the instances on port 9000. The EC2 instances attempt to return the response to the load balancer using a dynamic port within the ephemeral port range (1024-65535).

Understanding the source and destination ports of the return packets reveals why they are being dropped by the stateless network barrier.

Identify the missing rule in the subnet-level configuration.

The private subnet NACL only allows inbound traffic on port 9000 but lacks an outbound rule to allow return traffic back to the load balancer on the ephemeral ports.

This explains why the EC2 instances show the service is running locally, but the load balancer marks them as unhealthy.

Apply the outbound rule correction to the NACL.

Add an outbound rule to the private subnet NACL that allows traffic destined for the public subnets over ports 1024-65535.

This allows the return packets of the health check probes to pass through the NACL to the ALB, resolving the health check failures.

Key Concept

Stateless vs. Stateful Network Filtering in AWS VPC and ELB Health Checks

Question 1046Question →

A software publisher distributes installer packages globally. The primary files are stored in an Amazon S3 bucket in the us-west-2 Region, and a backup replica is maintained in an S3 bucket in the eu-central-1 Region. The publisher requires a content delivery solution that ensures high availability and low latency for downloads, even if the primary S3 bucket becomes temporarily unavailable. The solution must minimize operational overhead. Which configuration should a solutions architect recommend to meet these requirements?

Configure Amazon Route 53 with latency-based routing policies pointing to both Amazon S3 buckets. Attach Route 53 health checks to the S3 bucket endpoints to enable automatic failover to the secondary region if the primary bucket is unhealthy.

Configure an Amazon CloudFront distribution with an origin group containing the primary S3 bucket as the primary origin and the backup S3 bucket as the secondary origin. Configure origin failover based on specific HTTP status codes such as 500, 502, 503, or 504.

Configure an Amazon CloudFront distribution with the primary S3 bucket as the origin. Configure AWS WAF with custom rules to monitor origin health and dynamically rewrite requests to point to the backup S3 bucket if the primary bucket is unreachable.

Configure an Amazon CloudFront distribution with the primary S3 bucket as the origin. Set the default Time to Live (TTL) values to 0 seconds on all cache behaviors to force CloudFront to query a Route 53 active-passive failover record set on every client request.

Show answer & explanation

Answer: Configure an Amazon CloudFront distribution with an origin group containing the primary S3 bucket as the primary origin and the backup S3 bucket as the secondary origin. Configure origin failover based on specific HTTP status codes such as 500, 502, 503, or 504.

Answer

The correct configuration utilizes Amazon CloudFront origin groups to achieve both low-latency content delivery and high availability. By grouping the primary Amazon S3 bucket (in us-west-2) and the backup S3 bucket (in eu-central-1) into an origin group, CloudFront can automatically fail over to the backup origin when the primary origin returns specific HTTP status codes (such as 500, 502, 503, or 504). This provides seamless, resilient content delivery with minimal latency and zero manual intervention or complex routing overhead.

Step-by-Step Solution

Identify the performance and availability requirements.

The solution requires low latency for global downloads (implying the use of a CDN like Amazon CloudFront) and high availability (implying multi-region storage failover).

CloudFront reduces latency by caching content at edge locations close to users, and S3 provides resilient storage across multiple regions.

Evaluate the mechanism for automatic failover under CloudFront.

Select Amazon CloudFront Origin Groups as the correct architectural feature to bind the two S3 buckets.

Origin Groups allow a primary and secondary origin to be grouped together, automatically failing over to the secondary origin if the primary origin returns configured HTTP error status codes.

Eliminate configurations that introduce high latency or misuse service scopes.

Discard Route 53 direct routing (no caching), AWS WAF routing (incorrect service scope), and setting TTL to 0 (bypasses caching).

These alternatives fail to meet the performance requirement or misapply AWS service capabilities.

Key Concept

Amazon CloudFront Origin Groups and Origin Failover

Estimated Time:1m 30s

Question 1047Question →

A financial services company hosts a multi-tier application in a VPC and must comply with a strict security policy requiring all subnet-level Network Access Control Lists (NACLs) to block unrestricted inbound SSH (port 22) and RDP (port 3389) traffic. The security team needs a solution that continuously monitors the NACL configurations, automatically alerts on any non-compliant changes, and reverts the non-compliant configurations to their secure state in near-real-time. Which solution meets these requirements with the least operational overhead?

Deploy AWS WAF at the subnet boundary and subscribe to AWS Shield Advanced. Configure a Web ACL rule to inspect incoming packets on ports 22 and 3389, and automatically block traffic from unauthorized IP ranges.

Configure AWS Config to monitor Network ACL configurations using the nacl-no-unrestricted-ssh-rdp managed rule. Set up an AWS Systems Manager Automation document as the remediation action to revert any non-compliant NACL rules when a change is detected.

Enable VPC Flow Logs to capture traffic. Use Amazon CloudWatch Logs to trigger an AWS Lambda function that dynamically creates stateful Security Group rules and applies them to the subnets to drop return traffic from unauthorized external addresses.

Configure AWS CloudTrail to monitor API activity. Create an Amazon EventBridge rule that filters for AuthorizeSecurityGroupIngress API calls, and configure it to trigger an AWS Lambda function to delete any rules that allow unrestricted SSH or RDP access.

Show answer & explanation

Answer: Configure AWS Config to monitor Network ACL configurations using the nacl-no-unrestricted-ssh-rdp managed rule. Set up an AWS Systems Manager Automation document as the remediation action to revert any non-compliant NACL rules when a change is detected.

Answer

AWS Config is designed for configuration monitoring and compliance tracking. The managed rule 'nacl-no-unrestricted-ssh-rdp' automatically checks if any Network ACLs allow unrestricted inbound SSH or RDP traffic. When a non-compliant resource is detected, AWS Config can trigger a remediation action using AWS Systems Manager Automation to automatically modify the NACL and revert it to a secure state, providing a native, low-overhead solution.

Step-by-Step Solution

Enable AWS Config in the target region and record the AWS::EC2::NetworkAcl resource type.

AWS Config tracks the configuration states and changes of all Network ACLs in the VPC.

This establishes the monitoring foundation needed to detect configuration changes.

Deploy the nacl-no-unrestricted-ssh-rdp AWS Config managed rule.

The rule automatically evaluates all Network ACL configurations for compliance against the policy prohibiting unrestricted SSH/RDP access.

This provides automated compliance detection without requiring custom detection logic or script development.

Configure an AWS Systems Manager Automation document as a remediation action for the managed rule.

When a non-compliant NACL configuration is detected, the Systems Manager Automation document executes in near-real-time to modify the NACL back to its compliant state.

This accomplishes automated remediation and recovery of the resources with minimal operational overhead.

Key Concept

Automated configuration monitoring and remediation using AWS Config and Systems Manager Automation

Estimated Time:2m 0s

Question 1048Question →

A financial technology company is launching a global peer-to-peer payment application. The application requires a database backend that can handle two distinct workloads. First, it must record millions of transaction ledger entries per day in Amazon DynamoDB with low latency, avoiding partition write bottlenecks. Second, it must support a reporting database using Amazon RDS for PostgreSQL that requires high availability, automatic low-latency failover, and offloading read queries to optimize primary database performance. Which two database design configurations should the solutions architect select to meet these performance and high availability requirements? (Select two.)

Select all that apply

Design the Amazon DynamoDB table using a partition key with high cardinality, such as a combination of transaction UUID and user ID, to distribute write operations evenly across partitions.

Configure Amazon RDS for PostgreSQL in a Multi-AZ deployment to provide automatic failover to a standby instance, and deploy RDS read replicas to offload read-heavy query traffic.

Design the Amazon DynamoDB table using the transaction date formatted as YYYY-MM-DD as the partition key to group daily transactions and maximize sequential write performance.

Configure Amazon RDS for PostgreSQL with read replicas in a different Availability Zone, and configure the application client to automatically promote a read replica to the primary role during an outage to minimize write downtime.

Show answer & explanation

Answer: Design the Amazon DynamoDB table using a partition key with high cardinality, such as a combination of transaction UUID and user ID, to distribute write operations evenly across partitions.; Configure Amazon RDS for PostgreSQL in a Multi-AZ deployment to provide automatic failover to a standby instance, and deploy RDS read replicas to offload read-heavy query traffic.

Answer

The solutions architect should design the Amazon DynamoDB table using a partition key with high cardinality, such as a transaction UUID and user ID, to distribute writes evenly. Additionally, they should configure Amazon RDS for PostgreSQL in a Multi-AZ deployment and deploy read replicas to offload read traffic.

Designing the DynamoDB table with a high-cardinality partition key distributes write operations evenly across multiple partitions, preventing hot keys. Deploying Amazon RDS in a Multi-AZ configuration enables synchronous replication and automated, low-latency failover, while read replicas offload read operations from the primary instance.

Step-by-Step Solution

Analyze the DynamoDB write performance requirement to identify potential bottlenecks.

Determine that choosing a partition key with high cardinality (transaction UUID + user ID) prevents write throttling by distributing traffic uniformly, whereas a sequential date key leads to a hot partition.

DynamoDB partitions data based on the partition key hash value; uneven distribution causes hot partitions and throttles throughput.

Analyze the Amazon RDS for PostgreSQL high availability and read-scaling requirements.

Select a Multi-AZ configuration to ensure synchronous replication and automatic failover, and deploy read replicas to handle read queries.

Multi-AZ is the primary mechanism for automatic failover in RDS, whereas read replicas are intended for scaling reads asynchronously and cannot serve as automated failover targets without manual configuration.

Key Concept

High-performance database architectures require designing high-cardinality partition keys for Amazon DynamoDB to avoid write throttling, and deploying Amazon RDS in a Multi-AZ configuration with read replicas to achieve automated failover and read scaling.

Estimated Time:2m 0s

Question 1049Question →

A company hosts a simple web application on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The ASG health check type is configured to use EC2 status checks. When the web application process crashes on an instance, the ALB marks that instance as unhealthy and stops routing traffic to it. However, the ASG does not terminate or replace the instance because the underlying EC2 instance status checks remain healthy. Which configuration change should a solutions architect implement to ensure that instances with failed web application processes are automatically replaced?

Configure the Auto Scaling group health check type to use ELB health checks.

Change the health check port in the Application Load Balancer target group to query the default HTTP port 80 instead of the custom application port.

Modify the inbound Network Access Control List (NACL) rules of the public subnets to allow stateful TCP traffic from the Application Load Balancer.

Create an Amazon Route 53 latency routing policy to direct user traffic to a backup Auto Scaling group in another AWS Region.

Show answer & explanation

Answer: Configure the Auto Scaling group health check type to use ELB health checks.

Answer

Configure the Auto Scaling group health check type to use ELB health checks.

By default, an Auto Scaling group (ASG) only monitors EC2 status checks. If the application process crashes but the OS/hypervisor remains healthy, the ASG will not replace the instance. Configuring the ASG to use ELB health checks allows it to query the Application Load Balancer's target group status, triggering the automatic replacement of instances that fail application-level health checks.

Step-by-Step Solution

Analyze the current health check configuration of the Auto Scaling group (ASG) and Application Load Balancer (ALB).

The ASG is configured to use EC2 health checks, which only monitor the hardware and hypervisor status, whereas the ALB is performing application-level health checks on the targets.

This explains why the ASG does not replace instances when the web application process crashes but the EC2 instance remains running.

Identify the mechanism required to link the ALB's health check results to the ASG's lifecycle management.

The health check type of the ASG must be updated from EC2 to ELB.

This configuration allows the ASG to receive health status updates from the ALB target group and take corrective action (termination and replacement) when the application health check fails.

Key Concept

Auto Scaling Group Health Check Configuration

Question 1050Question →

An organization runs a containerized payment processing service on Amazon ECS that requires credentials to access an Amazon RDS for MySQL database. The organization's security policy requires the database credentials to be rotated every 30 days. Additionally, the AWS Key Management Service (AWS KMS) customer managed key used to encrypt the credentials must be rotated annually. The policy also specifies that once the KMS key is rotated, the stored credentials must be immediately re-encrypted with the new key material to ensure that the retired key material is no longer used to protect the active credentials. Which solution should a solutions architect recommend to satisfy these security requirements?

Store the credentials in AWS Secrets Manager with automatic rotation enabled on a 30-day schedule. Enable automatic key rotation on the KMS customer managed key. Configure an AWS Lambda function triggered by AWS CloudTrail events for KMS key rotation to programmatically update the secret value, forcing Secrets Manager to re-encrypt the credentials using the new key material.

Store the credentials in AWS Systems Manager Parameter Store as a String parameter. Configure an Amazon EventBridge rule to trigger an AWS Lambda function every 30 days to rotate the database credentials and update the parameter. Enable automatic key rotation on the KMS customer managed key.

Store the credentials in AWS Secrets Manager with automatic rotation enabled on a 30-day schedule. Enable automatic key rotation on the KMS customer managed key, which automatically and immediately re-encrypts the existing database credentials in Secrets Manager with the new key material.

Store the credentials in AWS Systems Manager Parameter Store as a SecureString parameter. Enable automatic rotation for the parameter on a 30-day schedule. Enable automatic key rotation on the KMS customer managed key, and configure Parameter Store to automatically re-encrypt the parameter value using the new key version.

Show answer & explanation

Answer: Store the credentials in AWS Secrets Manager with automatic rotation enabled on a 30-day schedule. Enable automatic key rotation on the KMS customer managed key. Configure an AWS Lambda function triggered by AWS CloudTrail events for KMS key rotation to programmatically update the secret value, forcing Secrets Manager to re-encrypt the credentials using the new key material.

Answer

Store the credentials in AWS Secrets Manager with 30-day automatic rotation, enable automatic key rotation on the KMS customer managed key, and use a Lambda function triggered by CloudTrail key rotation events to programmatically update and re-encrypt the secret.

The correct solution uses AWS Secrets Manager for database credentials because it provides built-in 30-day automatic rotation for RDS databases. Since automatic KMS customer managed key rotation does not retroactively re-encrypt existing ciphertexts, a custom workflow using AWS CloudTrail, EventBridge, and AWS Lambda is required to detect the key rotation event, retrieve the secret, and update it. This update action forces Secrets Manager to request a new encryption operation from KMS, which will use the newly rotated key material to encrypt the active credentials immediately.

Step-by-Step Solution

Store database credentials in AWS Secrets Manager and enable built-in automatic rotation.

Automatic rotation of the RDS MySQL credentials occurs every 30 days without custom orchestration code.

Secrets Manager natively supports scheduled rotation for RDS databases, reducing operational overhead.

Enable automatic key rotation for the KMS Customer Managed Key (CMK) used to encrypt the secret.

The KMS key material is rotated automatically every year.

This satisfies the requirement for annual encryption key rotation without manual intervention.

Implement an AWS Lambda function triggered by EventBridge when a CloudTrail API call logs the KMS key rotation event to update the secret.

The active credentials in Secrets Manager are retrieved and re-saved, resulting in immediate re-encryption with the new key material.

Since automatic KMS key rotation does not retroactively re-encrypt existing ciphertexts, re-saving the secret programmatically forces the use of the new key version.

Key Concept

AWS KMS key rotation mechanics do not retroactively re-encrypt existing ciphertexts; dynamic re-encryption requires a re-save or manual re-encryption operation.

Estimated Time:2m 30s

Question 1051Question →

A company is designing a high-performance web application to track user activity logs. The application must write up to $10,000$ events per second, with each event payload containing a user ID, a timestamp, and action details. The read queries will be highly spiky and unpredictable, requiring sub-millisecond latency to display user dashboards. A solutions architect is designing the Amazon DynamoDB table for this workload. Which database configuration will provide the highest performance and efficiency?

Configure the DynamoDB table with a partition key of `user_id` and a sort key of `timestamp`. Set the table capacity to Provisioned mode with static capacity limits, and use Amazon ElastiCache for Memcached to cache read queries.

Configure the DynamoDB table with a partition key of `timestamp` formatted as `YYYY-MM-DD-HH` and a sort key of `user_id`. Set the table capacity to Provisioned mode with auto scaling enabled.

Configure the DynamoDB table with a partition key of `user_id` and a sort key of `timestamp`. Set the table capacity to On-Demand mode, and deploy Amazon DynamoDB Accelerator (DAX) to cache read queries.

Configure an Amazon RDS for PostgreSQL database with a primary instance and multiple Read Replicas. Configure the application to write to the primary instance and route read queries to the Read Replicas, using the replicas as automatic failover targets.

Show answer & explanation

Answer: Configure the DynamoDB table with a partition key of `user_id` and a sort key of `timestamp`. Set the table capacity to On-Demand mode, and deploy Amazon DynamoDB Accelerator (DAX) to cache read queries.

Answer

The correct configuration uses a high-cardinality partition key (`user_id`) combined with a sort key (`timestamp`) to distribute writes evenly across multiple partitions. Utilizing On-Demand capacity mode allows DynamoDB to handle unpredictable and spiky read and write traffic without throttling or manual capacity planning. Amazon DynamoDB Accelerator (DAX) provides the required sub-millisecond latency for read operations by caching query results in-memory.

Step-by-Step Solution

Evaluate the ingestion throughput and latency constraints.

The application requires high write throughput of

10,000

writes per second and sub-millisecond read latency under spiky load, pointing to a NoSQL solution like Amazon DynamoDB with an in-memory cache.

Choosing the correct database engine type is the foundation of high-performance architecture design.

Determine the partition key design to prevent bottlenecks.

Using `user_id` as the partition key ensures write operations are evenly distributed across physical partitions, whereas using `timestamp` would create a hot partition.

High cardinality in partition keys is crucial to avoid hot partitions and throttling in DynamoDB.

Configure the capacity scaling mode and read cache.

Select On-Demand capacity mode to dynamically adjust to spiky read/write patterns, and deploy Amazon DynamoDB Accelerator (DAX) to serve reads with sub-millisecond latency.

On-Demand mode prevents over-provisioning or throttling for unpredictable traffic, and DAX provides microsecond latency for cached reads.

Key Concept

High-Performing Database Solutions

Estimated Time:2m 0s

Question 1052Question →

A telemetry data processing system runs on Amazon Elastic Container Service (Amazon ECS) tasks inside a private subnet. The system requires secure access to three configuration items: database credentials for an Amazon RDS for MySQL DB instance that must be rotated every 30 days, a static API key for an external mapping provider, and the database endpoint host address along with the application logging verbosity level. The solutions architect needs to design a secure storage and rotation solution that minimizes costs and operational overhead. Which two options should the solutions architect select to meet these requirements?

Select all that apply

Store the database credentials in AWS Secrets Manager, and configure automatic rotation using the built-in Amazon RDS rotation template.

Store the database credentials and the mapping provider API key as String parameters in AWS Systems Manager Parameter Store to eliminate AWS Secrets Manager pricing.

Store the database endpoint, logging verbosity level, and the external API key in AWS Systems Manager Parameter Store, using String parameters for non-sensitive data and a SecureString parameter for the API key.

Enable automatic key rotation on the AWS KMS customer managed key used to encrypt the Secrets Manager secrets, expecting this to automatically update and rotate the database credentials every 30 days.

Store the database credentials as a String parameter in AWS Systems Manager Parameter Store, and write a custom AWS Lambda function to perform rotation every 30 days.

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager, and configure automatic rotation using the built-in Amazon RDS rotation template.; Store the database endpoint, logging verbosity level, and the external API key in AWS Systems Manager Parameter Store, using String parameters for non-sensitive data and a SecureString parameter for the API key.

Answer

Store the database credentials in AWS Secrets Manager with automatic RDS rotation enabled, and store the non-sensitive parameters as String parameters and the API key as a SecureString parameter in AWS Systems Manager Parameter Store.

To satisfy the requirements securely and cost-effectively, the database credentials should be stored in AWS Secrets Manager, which natively supports automatic 30-day rotation for Amazon RDS DB instances. Non-sensitive settings (database endpoint and logging level) and the static API key should be stored in AWS Systems Manager Parameter Store. Using String parameters for the non-sensitive configuration and a SecureString parameter for the API key ensures both security and cost efficiency.

Step-by-Step Solution

Analyze the security and rotation requirements for each configuration item.

The database credentials require rotation every 30 days, which makes AWS Secrets Manager the ideal service due to its built-in RDS rotation templates. The external API key is static and does not require automatic rotation, meaning it can be securely stored in AWS Systems Manager Parameter Store.

Evaluating rotation needs determines the proper secrets management service, aligning with security requirements while optimizing for simplicity.

Select the most cost-effective parameters for non-sensitive data.

The database endpoint and logging verbosity are non-sensitive configuration items and should be stored as free standard String parameters in Parameter Store.

Using Parameter Store for non-sensitive parameters avoids the monthly per-secret cost of AWS Secrets Manager.

Evaluate the encryption requirements for static sensitive data.

The static API key is sensitive and must be encrypted at rest. It should be stored as a SecureString parameter in Systems Manager Parameter Store, which is backed by AWS KMS.

SecureString parameters provide free storage (with standard parameters limit) and secure KMS-based encryption for sensitive, non-rotating values.

Key Concept

AWS Secrets Manager provides native support for rotating active credentials such as database passwords, while AWS Systems Manager Parameter Store is a cost-effective service for static secrets (using SecureString) and non-sensitive configuration data (using String parameters).

Question 1053Question →

An enterprise is designing a secure architecture for a microservices application. The application's compute resources run in an Amazon ECS cluster hosted in AWS Account A, while the backend Amazon Aurora PostgreSQL database is hosted in AWS Account B. The security architecture must satisfy the following constraints:
1. The database credentials must be encrypted at rest and automatically rotated every 30 days without manual intervention.
2. The application requires access to a third-party payment API token that must be encrypted at rest and rotated every 90 days.
3. Non-sensitive configurations (such as the database endpoint and port) must be stored in a cost-optimized manner and accessible without decryption overhead.
4. The ECS tasks in Account A must access these resources securely with minimal operational complexity.

Which two options should the solutions architect choose to meet these requirements?

Select all that apply

Store the database credentials in AWS Secrets Manager in Account B, encrypted with a customer managed KMS key. Enable automatic rotation using the built-in Aurora PostgreSQL rotation template, and attach a resource-based policy to the secret to grant read access to the ECS task execution role in Account A.

Store the non-sensitive database configurations as standard String parameters in AWS Systems Manager Parameter Store in Account A, and store the third-party API token in AWS Secrets Manager in Account A with a custom AWS Lambda function configured for its 90-day rotation.

Store the database credentials and the third-party API token in AWS Systems Manager Parameter Store in Account B as String parameters, and use AWS KMS automatic key rotation to automatically update the credentials in the database and re-encrypt the parameter values.

Store the database credentials and non-sensitive configurations in AWS Systems Manager Parameter Store in Account B as SecureString parameters, and configure the ECS tasks in Account A to retrieve them directly using a resource-based policy attached to the parameters.

Store the third-party API token in AWS Systems Manager Parameter Store in Account A as a String parameter, and configure an Amazon EventBridge rule that triggers a custom AWS Lambda function to rotate the token and update the parameter value every 90 days.

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager in Account B, encrypted with a customer managed KMS key. Enable automatic rotation using the built-in Aurora PostgreSQL rotation template, and attach a resource-based policy to the secret to grant read access to the ECS task execution role in Account A.; Store the non-sensitive database configurations as standard String parameters in AWS Systems Manager Parameter Store in Account A, and store the third-party API token in AWS Secrets Manager in Account A with a custom AWS Lambda function configured for its 90-day rotation.

Answer

Store the database credentials in AWS Secrets Manager in Account B with a resource-based policy and built-in rotation template. Store the non-sensitive configurations in AWS Systems Manager Parameter Store in Account A as standard String parameters, and store the third-party API token in AWS Secrets Manager in Account A using a custom Lambda function for rotation.

For the database credentials in Account B, AWS Secrets Manager is the optimal choice because it supports native database password rotation and resource-based policies, allowing direct cross-account access from Account A's ECS task role. For the non-sensitive parameters, Systems Manager Parameter Store standard String parameters provide a free, no-decryption-overhead solution within Account A. For the third-party API key, Secrets Manager in Account A allows custom 90-day rotation via AWS Lambda while maintaining encryption at rest.

Step-by-Step Solution

Select the database credentials storage and cross-account access strategy.

Database credentials should be stored in AWS Secrets Manager in Account B.

Secrets Manager natively supports automatic 30-day rotation for RDS/Aurora using built-in Lambda templates. It also supports resource-based policies, which allow ECS tasks in Account A to read the secret directly across accounts.

Select the storage strategy for non-sensitive configurations to minimize cost and latency.

Store non-sensitive configurations as standard String parameters in Systems Manager Parameter Store in Account A.

Standard String parameters in Parameter Store do not incur storage or decryption costs, and since they are stored in the same account as the ECS tasks, no cross-account access overhead is introduced.

Select the storage and rotation strategy for the third-party API token.

Store the third-party API token in AWS Secrets Manager in Account A, using a custom AWS Lambda function for rotation.

The API token requires encryption at rest (achieved via Secrets Manager) and a custom rotation mechanism since it is an external third-party API. Secrets Manager integrates directly with Lambda to schedule and execute this rotation logic.

Key Concept

Cross-account access and automated lifecycle management of sensitive credentials and non-sensitive configurations using AWS Secrets Manager and Systems Manager Parameter Store.

Estimated Time:3m 0s

Question 1054Question →

A company stores database backups in an Amazon S3 bucket. The backup files average $10\text{ GB}$ in size. The backups are accessed frequently for the first $15\text{ days}$ for verification. After $15\text{ days}$ , they are rarely accessed, but the company must retain them for a total of $25\text{ days}$ for emergency recovery before they are permanently deleted. Which S3 lifecycle configuration provides the most cost-effective storage solution for these backups?

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

15\text{ days}

, and delete them after

25\text{ days}

Configure a lifecycle rule to transition the backups to Amazon S3 Glacier Flexible Retrieval after

15\text{ days}

, and delete them after

25\text{ days}

Keep the backups in Amazon S3 Standard, and configure a lifecycle rule to permanently delete them after

25\text{ days}

Configure a lifecycle rule to transition the backups to Amazon S3 Intelligent-Tiering after

15\text{ days}

, and delete them after

25\text{ days}

Show answer & explanation

Answer: Keep the backups in Amazon S3 Standard, and configure a lifecycle rule to permanently delete them after $25\text{ days}$ .

Answer

Keep the backups in Amazon S3 Standard, and configure a lifecycle rule to permanently delete them after

25\text{ days}

Keeping the database backups in Amazon S3 Standard for the entire

25\text{ days}

and deleting them via a lifecycle rule is the most cost-effective option. Because the backups are deleted at day

25

, any transition to S3 Standard-IA at day

15

results in only

10\text{ days}

of storage in the Infrequent Access tier. S3 Standard-IA charges a minimum of

30\text{ days}

of storage, meaning the user would pay for

30\text{ days}

of S3 Standard-IA storage in addition to the

15\text{ days}

of S3 Standard storage, resulting in a higher total cost.

Step-by-Step Solution

Calculate the storage cost of keeping backups in Amazon S3 Standard for

25\text{ days}

Storage cost is calculated based on the actual duration of

25\text{ days}

without any minimum storage duration penalty.

Amazon S3 Standard has no minimum storage duration constraints.

Evaluate S3 Standard-IA cost constraints for the remaining

10\text{ days}

of retention.

Transitioning to S3 Standard-IA at day

15

and deleting at day

25

means the data resides in S3 Standard-IA for only

10\text{ days}

. Because S3 Standard-IA enforces a

30\text{ days}

minimum storage charge, the company is billed for

30\text{ days}

of IA storage, which offsets the tier's lower rate and increases overall costs.

Identifying the S3 Standard-IA minimum duration rule is critical to avoiding unexpected cost penalties.

Evaluate Amazon S3 Glacier Flexible Retrieval and S3 Intelligent-Tiering constraints.

S3 Glacier Flexible Retrieval enforces a

90\text{ days}

minimum storage duration. S3 Intelligent-Tiering requires

30\text{ consecutive days}

of no access to tier down, which cannot be met within a

25\text{ days}

lifespan, and adds monitoring charges.

Confirming that alternative tiers are more expensive due to early deletion penalties or tiering requirements.

Key Concept

S3 Storage Class Minimum Duration Constraints

Estimated Time:1m 30s

Question 1055Question →

A company hosts a data processing application on Amazon EC2 instances in private subnets within VPC A. The application replicates approximately $30\text{ TB}$ of data monthly to a database cluster hosted on EC2 instances in VPC B within the same AWS Region. Currently, the VPCs are connected using an AWS Transit Gateway, and the application connects to the database cluster using its public DNS hostname, which routes traffic through NAT Gateways. Which configuration should a solutions architect recommend to minimize the data transfer costs?

Establish a VPC peering connection between VPC A and VPC B, and update the route tables to route traffic destined for the database replica's private IP range through the peering connection.

Keep the AWS Transit Gateway connection, but update the application configuration to connect to the database replica using its private IP address.

Establish an AWS Site-to-Site VPN connection between VPC A and VPC B to route the database replication traffic over private IP addresses.

Purchase a Compute Savings Plan to offset the data processing charges incurred by the NAT Gateway and the AWS Transit Gateway.

Show answer & explanation

Answer: Establish a VPC peering connection between VPC A and VPC B, and update the route tables to route traffic destined for the database replica's private IP range through the peering connection.

Answer

Establish a VPC peering connection between VPC A and VPC B, and update the route tables to route traffic destined for the database replica's private IP range through the peering connection.

Establishing a VPC peering connection eliminates the AWS Transit Gateway processing fee of

0.02 per GB. Configuring the application to use the database's private IP range instead of its public DNS hostname routes the traffic directly through the peered VPCs, bypassing the NAT Gateways and eliminating the NAT Gateway data processing charge of

0.045 per GB.

Step-by-Step Solution

Identify the sources of data processing charges in the current architecture.

The current architecture incurs NAT Gateway data processing charges (

0.045/GB) and AWS Transit Gateway data processing charges (

0.02/GB).

Analyzing the components that contribute to the network data transfer fees is necessary to target cost optimization.

Evaluate a lower-cost VPC connection method.

A VPC peering connection has no data processing fees, making it highly cost-effective for point-to-point data transfer within the same Region.

Replacing the Transit Gateway for this high-volume path removes the processing fee.

Reroute the traffic using private IP addresses.

Routing the traffic through the VPC peering connection using private IP addresses bypasses the NAT Gateways.

Using private IPs avoids NAT Gateway data processing charges entirely.

Key Concept

Bypassing intermediate NAT Gateways and Transit Gateways for high-volume inter-VPC traffic using VPC Peering and private IP routing to eliminate data processing fees.

Question 1056Question →

A company runs a critical online transaction processing (OLTP) application on AWS that uses an Amazon RDS for PostgreSQL DB instance. The database size is $800\text{ GB}$ and requires a Multi-AZ deployment for high availability. The workload is characterized by a steady baseline of $2,500$ write IOPS and $1,500$ read IOPS. Every Sunday, a batch data archiving job runs for $4$ hours, generating an additional peak of $12,000$ read IOPS. The database currently uses Provisioned IOPS SSD (`io2`) storage provisioned at $16,000$ IOPS to ensure performance during the Sunday peak. A solutions architect needs to redesign the database storage and capacity configuration to minimize costs while maintaining high availability and performance. Which configuration is the most cost-effective way to meet these requirements?

Modify the primary DB instance to use General Purpose SSD (gp3) storage with

16,000

provisioned IOPS in a Multi-AZ configuration. Purchase a Compute Savings Plan to apply discounts to the database instance and provisioned storage costs.

Modify the primary DB instance to use General Purpose SSD (gp3) storage with

4,000

provisioned IOPS. Create a Single-AZ RDS Read Replica using gp3 storage with

12,000

provisioned IOPS to handle the Sunday archiving workload, and route the archiving queries to the replica.

Modify the primary DB instance to use General Purpose SSD (gp3) storage with

4,000

provisioned IOPS. Create an RDS Read Replica in a different Availability Zone with gp3 storage with

12,000

provisioned IOPS. Configure the replica as the primary failover target to eliminate the need for the Multi-AZ deployment.

Migrate the PostgreSQL database to an Amazon DynamoDB table configured in Provisioned Capacity Mode. Set the write capacity units (WCUs) to

2,500

and read capacity units (RCUs) to

16,000

to accommodate the Sunday peak, and enable DynamoDB Auto Scaling.

Show answer & explanation

Answer: Modify the primary DB instance to use General Purpose SSD (gp3) storage with $4,000$ provisioned IOPS. Create a Single-AZ RDS Read Replica using gp3 storage with $12,000$ provisioned IOPS to handle the Sunday archiving workload, and route the archiving queries to the replica.

Answer

Modify the primary DB instance to use General Purpose SSD (gp3) storage with

4,000

provisioned IOPS. Create a Single-AZ RDS Read Replica using gp3 storage with

12,000

provisioned IOPS to handle the Sunday archiving workload, and route the archiving queries to the replica.

The correct configuration uses gp3 storage for the Multi-AZ primary instance, sized only for the OLTP baseline of

4,000

IOPS, and delegates the Sunday read-heavy batch workload to a Single-AZ Read Replica provisioned with

12,000

IOPS. This leverages gp3's low-cost structure and avoids doubling the provisioning cost of the peak

12,000

IOPS over both Multi-AZ instances.

Step-by-Step Solution

Analyze database workload requirements

Identified a steady baseline of

4,000

IOPS (

2,500

writes +

1,500

reads) and a weekly read-only peak of

12,000

IOPS.

Understanding the baseline vs. peak requirements is necessary to size storage and allocate capacity cost-effectively.

Select the optimal storage class

Selected gp3 storage over io2 storage.

gp3 storage provides cost-efficient baseline performance and allows provisioning IOPS independently of storage size, significantly reducing storage costs compared to io2.

Design database replication and capacity allocation

Allocated

4,000

IOPS to the Multi-AZ primary database and offloaded the

12,000

IOPS Sunday archiving workload to a Single-AZ Read Replica.

Since the archiving job is read-only, using a Single-AZ Read Replica avoids paying for peak IOPS on both primary and standby instances in the Multi-AZ configuration.

Key Concept

Cost-optimized database capacity planning involves matching storage types (like gp3 vs. io2) to workload requirements, utilizing read replicas to offload read-heavy batch processes from Multi-AZ deployments, and understanding the billing scope of compute savings options.

Question 1057Question →

A startup is deploying a microservices application using Amazon ECS with the Amazon EC2 launch type. The tasks run on EC2 instances managed by an Auto Scaling group (ASG) in private subnets. The application uses dynamic port mapping, where the container's port $80$ is mapped to a dynamically allocated host port in the range $32768-61000$ on the EC2 instances. An Application Load Balancer (ALB) in the public subnets routes external traffic from port $443$ to the target group associated with the ECS service.

The security team has configured custom Network ACLs (NACLs) and Security Groups to enforce strict traffic filtering:
1. Public Subnet NACL:
- Inbound: Allows TCP port $443$ from 0.0.0.0/0.
- Outbound: Allows all traffic.
2. Private Subnet NACL:
- Inbound: Allows TCP port $443$ and ephemeral ports $1024-65535$ from the public subnets.
- Outbound: Allows all traffic.
3. EC2 Instance Security Group:
- Inbound: Allows TCP port $80$ from the ALB security group.
- Outbound: Allows all traffic.

The target group has its health check port configured to traffic-port. The ECS tasks fail to register successfully because the ALB marks the targets as unhealthy, causing the ASG to terminate and relaunch the EC2 instances.

Which action should the solutions architect take to resolve this issue and allow the health checks to pass?

Modify the target group health check configuration to use HTTP port

80

instead of the default traffic-port.

Configure the private subnet Network ACL to allow stateful return traffic on ports

32768-61000

from the ALB.

Update the security group of the EC2 instances to allow inbound TCP traffic on the dynamic port range

32768-61000

from the ALB security group.

Create an Amazon Route 53 Latency routing policy to route traffic directly to the private IP addresses of the EC2 instances.

Show answer & explanation

Answer: Update the security group of the EC2 instances to allow inbound TCP traffic on the dynamic port range $32768-61000$ from the ALB security group.

Answer

Update the security group of the EC2 instances to allow inbound TCP traffic on the dynamic port range

32768-61000

from the ALB security group.

The correct answer is to update the security group of the EC2 instances to allow inbound TCP traffic on the dynamic port range

32768-61000

from the ALB security group. Because the ECS tasks use dynamic port mapping, the container port is mapped to a dynamic host port. The ALB health check is configured to use traffic-port, meaning it will query the dynamic host port. The security group of the EC2 instances must allow inbound traffic on this dynamic range from the load balancer's security group to allow the health checks to succeed.

Step-by-Step Solution

Analyze the application architecture and port configurations.

The ECS tasks use dynamic port mapping, mapping container port

80

to host ports in the range

32768-61000

. The ALB target group health check is set to traffic-port.

Understanding which ports are actively listening on the host EC2 instances is critical to determining where health check traffic is being sent.

Identify the destination port of the ALB health checks.

The ALB health checks are sent to the dynamically allocated host ports in the range

32768-61000

Since traffic-port is configured, the load balancer dynamically targets the host port registered for each container task.

Evaluate the network access control and security group rules for the destination ports.

The private subnet NACL allows inbound traffic on ephemeral ports

1024-65535

(which covers

32768-61000

). However, the EC2 instance security group only allows inbound traffic on port

80

Both NACLs and security groups must allow the traffic. The security group is currently blocking the health check traffic on the dynamic host ports.

Formulate the correct modification to allow the health checks to pass.

Updating the EC2 instance security group to allow inbound TCP traffic on the dynamic range

32768-61000

from the ALB's security group allows the health checks to reach the containerized tasks.

This configuration allows the ALB to reach the dynamically mapped host ports while maintaining security group-level access control.

Key Concept

Auto Scaling and Elastic Load Balancing (ELB) integration with ECS dynamic port mapping

Estimated Time:3m 0s

Question 1058Question →

A software development company is launching a new REST API deployed on Amazon EC2 instances within an Auto Scaling group. The API application is configured to listen on port $5000$ . An Application Load Balancer (ALB) is deployed to distribute incoming traffic across the instances. The Solutions Architect needs to configure the load balancer and security settings to ensure the ALB can successfully perform health checks and route traffic to the application. Which TWO configurations should the Solutions Architect implement? (Select two).

Select all that apply

Set the target group health check port to 'traffic-port' or explicitly define it as port

5000

Allow inbound TCP traffic on port

5000

in the EC2 instance security group, sourcing from the Application Load Balancer's security group.

Leave the target group health check port at the default port

80

and rely on the load balancer to automatically redirect requests to port

5000

Configure the subnet Network Access Control List (NACL) to be stateful and allow inbound traffic on port

5000

Configure a Route 53 latency routing policy to dynamically detect and remove unhealthy EC2 instances from the target group.

Show answer & explanation

Answer: Set the target group health check port to 'traffic-port' or explicitly define it as port $5000$ .; Allow inbound TCP traffic on port $5000$ in the EC2 instance security group, sourcing from the Application Load Balancer's security group.

Answer

The Solutions Architect must configure the target group health check port to use the traffic port (or explicitly port 5000) and update the EC2 instance security group to allow inbound TCP traffic on port 5000 from the Application Load Balancer's security group.

For an application listening on a custom port like port 5000, the Application Load Balancer must be configured to send health check requests to that specific port (or use the 'traffic-port' option). Additionally, the EC2 instances' security group must allow inbound traffic on port 5000 from the ALB's security group to permit health checks and application traffic to flow.

Step-by-Step Solution

Identify the application port configuration.

The application listens on port 5000 on the EC2 instances.

This determines the target port for both health checks and application traffic.

Configure the health check port in the target group.

Set the health check port to 'traffic-port' or port 5000.

This ensures the Application Load Balancer performs health checks on the actual port where the API is running instead of defaulting to port 80.

Configure instance-level firewalls (security groups).

Allow inbound traffic on port 5000 from the ALB security group.

This permits the load balancer to successfully connect to the instances for health checks and traffic forwarding.

Key Concept

Configuring load balancer target groups and instance security groups for custom port applications to ensure proper health monitoring and routing.

Question 1059Question →

A company hosts a global car-sharing application on AWS. The application consists of a frontend static website hosted in an Amazon S3 bucket, and a backend REST API hosted on Amazon EC2 instances behind an Application Load Balancer (ALB). The API queries a primary Amazon RDS for MySQL database. Users report slow load times for both the static images of cars and the dynamic vehicle search results. Which two actions should a solutions architect take to improve application performance and reduce latency? (Select TWO.)

Select all that apply

Deploy an Amazon CloudFront distribution in front of the Amazon S3 bucket to cache and serve the static vehicle images closer to users.

Implement an Amazon ElastiCache cluster to store and retrieve frequent database query results for vehicle availability.

Configure the Amazon CloudFront distribution with a cache behavior that sets the Minimum TTL, Maximum TTL, and Default TTL to 0 seconds for all static assets.

Route all static media download traffic from the Amazon S3 bucket to the private EC2 instances through a NAT Gateway to speed up internal data processing.

Transition the static vehicle images to Amazon S3 Glacier Flexible Retrieval and configure the application to retrieve them in real-time when a user loads a page.

Show answer & explanation

Answer: Deploy an Amazon CloudFront distribution in front of the Amazon S3 bucket to cache and serve the static vehicle images closer to users.; Implement an Amazon ElastiCache cluster to store and retrieve frequent database query results for vehicle availability.

Answer

Deploying an Amazon CloudFront distribution in front of the S3 bucket to cache static assets, and implementing an Amazon ElastiCache cluster to cache database query results.

Deploying an Amazon CloudFront distribution in front of the S3 bucket caches static vehicle images at edge locations close to global users, reducing load times. Implementing an Amazon ElastiCache cluster caches read-heavy database queries, offloading work from the primary RDS MySQL database and resolving latency issues for the dynamic search REST API.

Step-by-Step Solution

Analyze the application components and identify performance bottlenecks for both static assets (vehicle images in S3) and dynamic content (RDS MySQL queries via REST API).

Identified that static assets need caching at the edge and database queries need caching near the application tier.

This establishes a clear optimization plan targeting both frontend and backend layers.

Introduce Amazon CloudFront to serve the static assets from the S3 bucket.

Static assets are cached at edge locations, dramatically reducing latency for global users.

CloudFront is the standard AWS global CDN service designed for low-latency distribution of static files.

Introduce Amazon ElastiCache in front of the Amazon RDS MySQL database.

Frequent and repetitive SQL queries are cached, offloading read traffic from RDS and providing sub-millisecond response times.

ElastiCache is standard for dynamic read-heavy database caching in high-performing architectures.

Key Concept

Multi-tier caching using Amazon CloudFront for edge content delivery and Amazon ElastiCache for database query acceleration.

Question 1060Question →

A solutions architect needs to store a database password for a web application. The password must be encrypted at rest, but the application does not require automatic password rotation. The solutions architect wants to choose the most cost-effective storage option. Which AWS service should be used to meet these requirements?

AWS Systems Manager Parameter Store with a SecureString parameter

AWS Systems Manager Parameter Store with a String parameter

AWS Key Management Service (AWS KMS) key policies to directly store the database password

Amazon S3 Standard-Infrequent Access (S3 Standard-IA) to store the database password file

Show answer & explanation

Answer: AWS Systems Manager Parameter Store with a SecureString parameter

Answer

AWS Systems Manager Parameter Store with a SecureString parameter

Using AWS Systems Manager Parameter Store with a SecureString parameter satisfies the requirement to encrypt the database password at rest using AWS KMS. Since the application does not require automatic credential rotation, standard Parameter Store parameters are the most cost-effective choice as they are offered at no additional cost.

Step-by-Step Solution

Analyze the requirements for the secret database password.

The secret must be stored with encryption at rest, but automatic rotation is not required.

This rules out the necessity of AWS Secrets Manager's automatic rotation, allowing the use of simpler, free alternatives like Systems Manager Parameter Store.

Compare Systems Manager Parameter Store parameter types.

Parameter Store standard parameters are free of charge. A SecureString parameter type integrates with AWS KMS to encrypt the value at rest.

This securely encrypts the secret at rest without incurring the monthly secret hosting fees associated with AWS Secrets Manager.

Key Concept

AWS Systems Manager Parameter Store SecureString parameters provide a free and secure storage mechanism for sensitive configuration data and passwords when automated rotation is not needed.

Estimated Time:45s

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