Auto Scaling practice questions

A solutions architect is designing a batch processing workload that runs for 4 hours every night. The workload can be interrupted and resumed without data loss. Cost optimization is a primary requirement for this deployment.

Trap 1: Use Amazon EC2 Reserved Instances to cover the nightly batch…

Reserved Instances are designed for continuous workloads running 24/7 to maximize hourly savings. Because this workload only runs for 4 hours per night, paying for idle capacity during the remaining 20 hours makes Reserved Instances financially inefficient.

Trap 2: Provision Amazon EC2 On-Demand Instances and terminate them…

On-Demand instances bill per second while running and offer no discount, and manual termination via Lambda adds no cost benefit over automatic lifecycle management. They are tempting when workloads cannot tolerate interruption, but this batch job explicitly can be interrupted and resumed.

Trap 3: Purchase Amazon EC2 Dedicated Hosts to run the nightly batch…

Dedicated Hosts bill per host for the full allocation period regardless of instance usage, defeating cost optimisation for a 4-hour interruptible job. They are tempting when licensing or compliance demands physical server isolation and tenancy visibility.

A
Use Amazon EC2 Reserved Instances to cover the nightly batch processing requirements over a one-year term.
Why it fails: Reserved Instances are designed for continuous workloads running 24/7 to maximize hourly savings. Because this workload only runs for 4 hours per night, paying for idle capacity during the remaining 20 hours makes Reserved Instances financially inefficient.
B
Provision Amazon EC2 On-Demand Instances and terminate them manually through an AWS Lambda script after completion.
Why it fails: On-Demand instances bill per second while running and offer no discount, and manual termination via Lambda adds no cost benefit over automatic lifecycle management. They are tempting when workloads cannot tolerate interruption, but this batch job explicitly can be interrupted and resumed.
C
Configure an Auto Scaling group using Amazon EC2 Spot Instances with an appropriate instance diversification strategy.
Spot Instances bill at up to 90% below On-Demand rates and suit interruptible, resumable workloads. Diversifying across instance types and Availability Zones reduces the chance of simultaneous two-minute interruption notices, satisfying the cost-optimisation requirement while tolerating the nightly four-hour job being reclaimed.
D
Purchase Amazon EC2 Dedicated Hosts to run the nightly batch processing instances securely and predictably.
Why it fails: Dedicated Hosts bill per host for the full allocation period regardless of instance usage, defeating cost optimisation for a 4-hour interruptible job. They are tempting when licensing or compliance demands physical server isolation and tenancy visibility.

Question 2mediummultiple choice

An application running on Amazon Aurora MySQL experiences significant performance degradation during peak hours due to a surge in read-only traffic. The database currently uses a single primary instance and one replica. What is the most effective way to scale the database for these spikes while maintaining high performance?

Trap 1: Manually add more Aurora Replicas during peak hours.

Manual intervention is inefficient and prone to human error, often resulting in delayed responses to traffic spikes. While adding replicas increases read capacity, doing so manually does not provide the elasticity required for unpredictable workloads. This approach leads to either performance bottlenecks during sudden surges or wasted costs when traffic levels drop.

Trap 2: Increase the instance size of the primary Aurora instance.

Scaling up the primary instance increases the overall cost and may cause downtime during the modification process. While a larger instance provides more resources, it does not specifically address the need for distributed read capacity. Using multiple read replicas is a more effective strategy for handling high-volume read traffic than vertical scaling alone.

Trap 3: Use Amazon SQS to buffer incoming read requests.

Amazon SQS is a message queuing service intended for asynchronous processing and decoupling components, not for caching or buffering synchronous database read requests. Implementing SQS for read traffic would introduce significant latency and architectural complexity. It is not a suitable solution for improving the performance of a real-time, read-heavy relational database application.

A
Manually add more Aurora Replicas during peak hours.
Why it fails: Manual intervention is inefficient and prone to human error, often resulting in delayed responses to traffic spikes. While adding replicas increases read capacity, doing so manually does not provide the elasticity required for unpredictable workloads. This approach leads to either performance bottlenecks during sudden surges or wasted costs when traffic levels drop.
B
Configure Aurora Auto Scaling for the Aurora Replicas.
Aurora Auto Scaling automatically manages the number of read replicas based on a specified target metric like CPU utilization. This ensures that the read capacity scales out instantly during traffic peaks and scales in when the demand decreases. It provides a highly performant and cost-optimized solution for managing fluctuating read-heavy workloads on Aurora.
C
Increase the instance size of the primary Aurora instance.
Why it fails: Scaling up the primary instance increases the overall cost and may cause downtime during the modification process. While a larger instance provides more resources, it does not specifically address the need for distributed read capacity. Using multiple read replicas is a more effective strategy for handling high-volume read traffic than vertical scaling alone.
D
Use Amazon SQS to buffer incoming read requests.
Why it fails: Amazon SQS is a message queuing service intended for asynchronous processing and decoupling components, not for caching or buffering synchronous database read requests. Implementing SQS for read traffic would introduce significant latency and architectural complexity. It is not a suitable solution for improving the performance of a real-time, read-heavy relational database application.

Question 3easymultiple choice

A company is migrating a compute-intensive web application to AWS. The application requires high CPU performance and needs to scale automatically based on demand. Which EC2 instance family and scaling feature should the architect choose to ensure optimal performance?

Trap 1: T-family instances with a standard Auto Scaling group.

T-family instances are burstable general-purpose instances intended for workloads with low baseline CPU usage that occasionally need to burst. For a consistently compute-intensive application, these instances might run out of CPU credits, leading to throttled performance. They are not suitable for high-performance, compute-bound workloads that require sustained high CPU levels.

Trap 2: R-family instances with a scheduled scaling policy.

R-family instances are memory-optimized and are best suited for memory-intensive applications like high-performance databases or distributed caches. While they provide high performance, they are not the most cost-effective or performant choice for compute-intensive tasks. Additionally, scheduled scaling is less effective than dynamic scaling for responding to unpredictable real-time demand.

Trap 3: M-family instances with manual scaling adjustments.

M-family instances are general-purpose and provide a balance of compute, memory, and networking resources. While versatile, they are not specifically optimized for compute-heavy tasks compared to the C-family. Manual scaling is also inefficient for web applications with fluctuating traffic, as it cannot respond rapidly enough to ensure consistent performance for users.

A
T-family instances with a standard Auto Scaling group.
Why it fails: T-family instances are burstable general-purpose instances intended for workloads with low baseline CPU usage that occasionally need to burst. For a consistently compute-intensive application, these instances might run out of CPU credits, leading to throttled performance. They are not suitable for high-performance, compute-bound workloads that require sustained high CPU levels.
B
R-family instances with a scheduled scaling policy.
Why it fails: R-family instances are memory-optimized and are best suited for memory-intensive applications like high-performance databases or distributed caches. While they provide high performance, they are not the most cost-effective or performant choice for compute-intensive tasks. Additionally, scheduled scaling is less effective than dynamic scaling for responding to unpredictable real-time demand.
C
C-family instances with a dynamic scaling policy.
C-family instances are compute-optimized and provide the highest ratio of CPU to memory, making them perfect for compute-intensive web applications. Combining these instances with a dynamic scaling policy allows the fleet to expand or contract based on actual CPU utilization. This ensures high performance during peak traffic while maintaining cost-efficiency during periods of low demand.
D
M-family instances with manual scaling adjustments.
Why it fails: M-family instances are general-purpose and provide a balance of compute, memory, and networking resources. While versatile, they are not specifically optimized for compute-heavy tasks compared to the C-family. Manual scaling is also inefficient for web applications with fluctuating traffic, as it cannot respond rapidly enough to ensure consistent performance for users.

Question 4mediummultiple choice

A company hosts a web application on EC2 instances behind an Application Load Balancer (ALB). The application has spikes in traffic. What should be configured to ensure performance and cost efficiency?

Trap 1: Use a fixed size Auto Scaling group at maximum capacity.

Maintaining a fixed size at maximum capacity ensures performance but is highly cost-inefficient. It wastes resources during off-peak hours and does not scale dynamically to meet unexpected traffic surges. This approach ignores the cost-saving benefits of cloud elasticity and is generally not recommended for variable production workloads.

Trap 2: Configure the ALB to handle all scaling automatically.

An Application Load Balancer manages the distribution of traffic among instances, but it does not control the scaling of the instances themselves. While the ALB itself is highly scalable, the underlying EC2 instances require an Auto Scaling group to handle changes in compute capacity based on demand.

Trap 3: Use reserved instances to handle all peak traffic.

Reserved Instances offer significant cost savings, but they commit you to a specific instance count. If you reserve capacity for peak traffic, you pay for unused resources during low-traffic periods. Auto Scaling is required to adjust the actual fleet size in response to real-time traffic fluctuations.

A
Use a fixed size Auto Scaling group at maximum capacity.
Why it fails: Maintaining a fixed size at maximum capacity ensures performance but is highly cost-inefficient. It wastes resources during off-peak hours and does not scale dynamically to meet unexpected traffic surges. This approach ignores the cost-saving benefits of cloud elasticity and is generally not recommended for variable production workloads.
B
Implement Auto Scaling with target tracking policies.
Target tracking scaling policies allow the architecture to maintain a specific metric, such as average CPU utilization, across a fleet. This ensures that the application always has enough compute power to handle load spikes while reducing the instance count when demand drops, achieving both performance and cost-efficiency.
C
Configure the ALB to handle all scaling automatically.
Why it fails: An Application Load Balancer manages the distribution of traffic among instances, but it does not control the scaling of the instances themselves. While the ALB itself is highly scalable, the underlying EC2 instances require an Auto Scaling group to handle changes in compute capacity based on demand.
D
Use reserved instances to handle all peak traffic.
Why it fails: Reserved Instances offer significant cost savings, but they commit you to a specific instance count. If you reserve capacity for peak traffic, you pay for unused resources during low-traffic periods. Auto Scaling is required to adjust the actual fleet size in response to real-time traffic fluctuations.

Question 5hardmultiple choice

Refer to the exhibit. A solutions architect reviewed an AWS CloudFormation template used to deploy an Auto Scaling group for a production web application. During an AWS Availability Zone outage in us-east-1, users experienced partial application downtime even though the Auto Scaling group reported instances running. Why is this architecture failing resiliency best practices?

Exhibit

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Resources": {
    "WebserverGroup": {
      "Type": "AWS::AutoScaling::AutoScalingGroup",
      "Properties": {
        "AvailabilityZones": ["us-east-1a", "us-east-1b"],
        "LaunchTemplate": {
          "LaunchTemplateId": {
            "Ref": "WebLaunchTemplate"
          },
          "Version": "1"
        },
        "MinSize": "2",
        "MaxSize": "10",
        "DesiredCapacity": "2"
      }
    }
  }
}

Trap 1: The Launch Template version is hardcoded to version 1 instead of…

A hardcoded launch template version still deploys instances across the group's subnets, so it does not by itself cause partial downtime during an AZ outage. The failure stems from the group spanning too few Availability Zones or an unbalanced subnet distribution. Pinning a version matters only when a newer template must be rolled out.

Trap 2: The MinSize and DesiredCapacity are set too low to handle sudden…

While a minimum size of two instances provides basic high availability, the primary cause of downtime during an AZ outage is the inability to provision replacement instances outside the hardcoded zone list, not just the initial capacity.

Trap 3: The Auto Scaling group is missing a health check type configuration…

While setting the health check type to ELB improves application-level health monitoring, it is not the primary root cause preventing the Auto Scaling group from surviving an entire Availability Zone outage in this template configuration.

A
The Launch Template version is hardcoded to version 1 instead of using $Latest or $Default.
Why it fails: A hardcoded launch template version still deploys instances across the group's subnets, so it does not by itself cause partial downtime during an AZ outage. The failure stems from the group spanning too few Availability Zones or an unbalanced subnet distribution. Pinning a version matters only when a newer template must be rolled out.
B
The Auto Scaling group defines Availability Zones directly instead of referencing subnets across multiple zones.
Hardcoding Availability Zones rather than referencing subnets across multiple zones prevents the Auto Scaling group from launching replacement instances elsewhere during a zone outage. Referencing multi-AZ subnets satisfies the resiliency constraint, maintaining capacity when one zone fails.
C
The MinSize and DesiredCapacity are set too low to handle sudden spikes in traffic during an outage.
Why it fails: While a minimum size of two instances provides basic high availability, the primary cause of downtime during an AZ outage is the inability to provision replacement instances outside the hardcoded zone list, not just the initial capacity.
D
The Auto Scaling group is missing a health check type configuration set to ELB instead of EC2.
Why it fails: While setting the health check type to ELB improves application-level health monitoring, it is not the primary root cause preventing the Auto Scaling group from surviving an entire Availability Zone outage in this template configuration.

Question 6mediummultiple choice

A company hosts a web application on Amazon EC2 instances behind an Application Load Balancer. The application stores session state in the local memory of the EC2 instances. Users report losing their sessions when the Auto Scaling group scales in or replaces unhealthy instances. Which solution ensures session persistence while maintaining high availability?

Trap 1: Configure the Application Load Balancer to use stickiness with a…

Duration-based cookies rely on the specific instance remaining healthy. If the instance is terminated by the Auto Scaling group during a scale-in event, the session data stored in memory is permanently lost, and the user will be forced to re-authenticate, providing no true state protection.

Trap 2: Store the session state in an Amazon S3 bucket with versioning…

Amazon S3 is designed for object storage and introduces significant latency for session-based read/write operations compared to in-memory stores. Using S3 for high-frequency session updates is inefficient and performance-prohibitive for web applications requiring low-latency access to user state information.

Trap 3: Replicate the session data across all EC2 instances using a…

Broadcasting session data across instances creates a synchronization bottleneck and increases network overhead significantly. This approach is not scalable, prone to race conditions, and does not handle the dynamic nature of an Auto Scaling group effectively as new instances would require full state replication.

A
Configure the Application Load Balancer to use stickiness with a duration-based cookie.
Why it fails: Duration-based cookies rely on the specific instance remaining healthy. If the instance is terminated by the Auto Scaling group during a scale-in event, the session data stored in memory is permanently lost, and the user will be forced to re-authenticate, providing no true state protection.
B
Store the session state in an Amazon S3 bucket with versioning enabled.
Why it fails: Amazon S3 is designed for object storage and introduces significant latency for session-based read/write operations compared to in-memory stores. Using S3 for high-frequency session updates is inefficient and performance-prohibitive for web applications requiring low-latency access to user state information.
C
Move the session state to an Amazon ElastiCache for Redis cluster.
ElastiCache for Redis offers low-latency, in-memory performance ideal for session management. By centralizing the session data, the application becomes stateless, allowing the Auto Scaling group to terminate or replace instances without impacting the user experience, as the state is preserved independently of the compute resources.
D
Replicate the session data across all EC2 instances using a broadcast script.
Why it fails: Broadcasting session data across instances creates a synchronization bottleneck and increases network overhead significantly. This approach is not scalable, prone to race conditions, and does not handle the dynamic nature of an Auto Scaling group effectively as new instances would require full state replication.

Question 7mediummultiple choice

A high-traffic application uses an Application Load Balancer (ALB) and an Auto Scaling group (ASG). During peak hours, some EC2 instances fail, but the ASG does not replace them immediately because the instances are still in a 'running' state despite the application being unresponsive. How should the architect fix this?

Trap 1: Increase the ASG health check grace period to 600 seconds.

Increasing the grace period only delays the initial health check after an instance starts. This would actually make the problem worse by allowing unresponsive instances to stay in service longer before the ASG attempts to evaluate their health. It does not address the core issue of the ASG not recognizing application-level failures.

Trap 2: Create a CloudWatch alarm for high CPU usage to trigger replacement.

While CPU usage can be an indicator of load, it is not a direct measure of application health. An application might be unresponsive due to a deadlock or database connection issue while CPU usage remains low. Relying on CPU alarms for instance replacement would lead to both false positives and missed application failures.

Trap 3: Configure a Lambda function to manually terminate unresponsive…

Developing a custom Lambda function to manage instance lifecycles adds unnecessary complexity and operational overhead. AWS provides native integration between ELB health checks and Auto Scaling groups to handle this exact scenario automatically. Using native features is always preferred over custom scripts to ensure long-term maintainability and reliability of the architecture.

A
Change the ASG health check type from EC2 to ELB.
The ELB health check type ensures that the Auto Scaling group considers an instance unhealthy if the Application Load Balancer determines the application is not responding correctly. This provides a more accurate view of application health than basic EC2 status checks, which only monitor the underlying hardware and network connectivity of the virtual machine.
B
Increase the ASG health check grace period to 600 seconds.
Why it fails: Increasing the grace period only delays the initial health check after an instance starts. This would actually make the problem worse by allowing unresponsive instances to stay in service longer before the ASG attempts to evaluate their health. It does not address the core issue of the ASG not recognizing application-level failures.
C
Create a CloudWatch alarm for high CPU usage to trigger replacement.
Why it fails: While CPU usage can be an indicator of load, it is not a direct measure of application health. An application might be unresponsive due to a deadlock or database connection issue while CPU usage remains low. Relying on CPU alarms for instance replacement would lead to both false positives and missed application failures.
D
Configure a Lambda function to manually terminate unresponsive instances.
Why it fails: Developing a custom Lambda function to manage instance lifecycles adds unnecessary complexity and operational overhead. AWS provides native integration between ELB health checks and Auto Scaling groups to handle this exact scenario automatically. Using native features is always preferred over custom scripts to ensure long-term maintainability and reliability of the architecture.

Question 8mediummulti select

A solutions architect is designing a caching layer for a high-traffic web application that uses a multi-node cluster. The architect needs to ensure high availability and the ability to scale horizontally while supporting complex data types such as sorted sets and lists. Which TWO features of Amazon ElastiCache for Redis support these requirements?

Trap 1: Support for multi-threaded execution.

Redis is primarily a single-threaded engine for command execution, although recent versions have introduced some background threading for I/O. Memcached is typically the choice for multi-threaded performance, but it lacks the complex data structures and high availability features like Multi-AZ and replication required in this scenario.

Trap 2: Automatic data compression at the cache level.

Amazon ElastiCache does not provide native automatic data compression at the service level. Compression is typically handled by the application code before the data is sent to the cache. Relying on the cache for compression would introduce unnecessary latency and CPU overhead on the cache nodes.

Trap 3: Use of UDP protocol for low-latency writes.

Redis uses the TCP protocol to ensure reliable delivery of data and commands. While UDP can be faster in some networking contexts, it is not supported by ElastiCache for Redis because reliability and data integrity are paramount for a persistent data store and caching engine.

A
Multi-AZ with automatic failover.
This feature provides high availability by automatically detecting a primary node failure and promoting a replica to primary in a different Availability Zone. This minimizes downtime and ensures that the caching layer remains performant and available even during infrastructure failures in a single zone.
B
Support for multi-threaded execution.
Why it fails: Redis is primarily a single-threaded engine for command execution, although recent versions have introduced some background threading for I/O. Memcached is typically the choice for multi-threaded performance, but it lacks the complex data structures and high availability features like Multi-AZ and replication required in this scenario.
C
Redis Cluster mode for horizontal scaling.
Redis Cluster mode allows data to be partitioned across multiple shards. This enables the cache to scale horizontally by adding more shards, providing increased memory capacity and throughput. This is essential for high-performing applications that outgrow the capacity of a single primary node.
D
Automatic data compression at the cache level.
Why it fails: Amazon ElastiCache does not provide native automatic data compression at the service level. Compression is typically handled by the application code before the data is sent to the cache. Relying on the cache for compression would introduce unnecessary latency and CPU overhead on the cache nodes.
E
Use of UDP protocol for low-latency writes.
Why it fails: Redis uses the TCP protocol to ensure reliable delivery of data and commands. While UDP can be faster in some networking contexts, it is not supported by ElastiCache for Redis because reliability and data integrity are paramount for a persistent data store and caching engine.

Question 9mediummultiple choice

A solutions architect is designing a mission-critical web application running on Amazon EC2 instances behind an Application Load Balancer. The application must remain highly available even during an Availability Zone outage. Which deployment strategy meets this requirement with optimal resilience?

Trap 1: Deploy all EC2 instances in a single Availability Zone and…

Placing all instances inside a single Availability Zone creates a single point of failure. If that specific data center experiences a power outage or hardware failure, the entire application becomes completely inaccessible, violating basic resilience principles.

Trap 2: Provision EC2 instances in multiple AWS Regions and use Route 53…

Multi-Region deployment with Route 53 latency routing does not keep the Application Load Balancer serving through an Availability Zone outage, since each Region's load balancer still spans its own zones and failover is DNS-based. It is tempting because Regions do survive wider failures, but the requirement is AZ-level resilience.

Trap 3: Use a single EC2 instance of a larger size to handle peak traffic…

A single larger instance still runs in one Availability Zone, so an AZ outage takes the application offline entirely and the load balancer has no healthy target. It is tempting because vertical scaling avoids the operational work of distributing instances, but it provides no redundancy across zones.

A
Deploy all EC2 instances in a single Availability Zone and configure an AWS Auto Scaling group with a maximum capacity of one.
Why it fails: Placing all instances inside a single Availability Zone creates a single point of failure. If that specific data center experiences a power outage or hardware failure, the entire application becomes completely inaccessible, violating basic resilience principles.
B
Distribute EC2 instances across multiple Availability Zones within a single AWS Region using an Auto Scaling group.
Spreading instances across multiple Availability Zones guarantees high availability by ensuring that an outage in one zone does not disrupt the entire application workload. The Auto Scaling group automatically maintains the desired capacity across remaining zones.
C
Provision EC2 instances in multiple AWS Regions and use Route 53 with a latency routing policy.
Why it fails: Multi-Region deployment with Route 53 latency routing does not keep the Application Load Balancer serving through an Availability Zone outage, since each Region's load balancer still spans its own zones and failover is DNS-based. It is tempting because Regions do survive wider failures, but the requirement is AZ-level resilience.
D
Use a single EC2 instance of a larger size to handle peak traffic loads without scaling.
Why it fails: A single larger instance still runs in one Availability Zone, so an AZ outage takes the application offline entirely and the load balancer has no healthy target. It is tempting because vertical scaling avoids the operational work of distributing instances, but it provides no redundancy across zones.

Question 10hardmulti select

An organization wants to identify and eliminate waste in their AWS account. They are specifically looking for idle resources that are still incurring charges. Which THREE AWS tools or features can help identify these cost-optimization opportunities?

Trap 1: AWS CloudTrail.

CloudTrail is a service that records API calls and account activity for security, auditing, and compliance. While it tells you who created a resource, it does not provide analysis of resource utilization or cost-saving recommendations, making it the wrong tool for identifying idle resource waste.

Trap 2: Amazon Inspector.

Amazon Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS. It focuses on finding vulnerabilities and deviations from best practices in security, not on cost optimization or identifying idle infrastructure resources.

A
AWS Trusted Advisor.
Trusted Advisor includes a 'Cost Optimization' pillar that specifically flags idle resources, such as unassociated Elastic IP addresses, underutilized Amazon EBS volumes, and idle Amazon RDS instances. It provides a quick dashboard view of immediate savings that can be achieved by terminating or resizing these resources.
B
AWS Compute Optimizer.
Compute Optimizer analyzes the configuration and utilization metrics of your AWS resources. It uses machine learning to identify if resources are over-provisioned and provides recommendations to downsize or change instance types to save money while maintaining performance, covering EC2, EBS, and Lambda functions.
C
AWS Cost Explorer Rightsizing Recommendations.
Cost Explorer provides a dedicated rightsizing tool that looks at your EC2 instance usage. It identifies instances that could be downsized within the same family or moved to a different family to reduce costs, providing estimated monthly savings for each recommendation based on your actual usage patterns.
D
AWS CloudTrail.
Why it fails: CloudTrail is a service that records API calls and account activity for security, auditing, and compliance. While it tells you who created a resource, it does not provide analysis of resource utilization or cost-saving recommendations, making it the wrong tool for identifying idle resource waste.
E
Amazon Inspector.
Why it fails: Amazon Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS. It focuses on finding vulnerabilities and deviations from best practices in security, not on cost optimization or identifying idle infrastructure resources.

Question 11hardmulti select

An organization needs to improve the resilience of its EC2-based application. Which THREE actions should the architect perform? (Select THREE.)

Trap 1: Use a single large EC2 instance instead of multiple smaller ones.

Relying on a single large instance creates a single point of failure. If that instance fails, the application goes down immediately. Using multiple smaller instances in a load-balanced configuration is significantly more resilient because the failure of one instance does not result in total service downtime for the application's users.

Trap 2: Place all instances in a single Auto Scaling group with a fixed…

Fixed capacity does not allow the application to adapt to changes in traffic demand or recover from unexpected instance termination as effectively as dynamic scaling policies. While it provides basic capacity, it lacks the elasticity needed to maintain resilience during high-demand events or when multiple instances fail simultaneously due to issues.

A
Distribute EC2 instances across multiple Availability Zones.
Spreading instances across multiple Availability Zones ensures that the application remains operational even if an entire data center experiences an outage. This is a primary requirement for high availability, as it mitigates the risk of localized infrastructure failures affecting the entire application availability and preventing end-user service disruption during regional events.
B
Configure an Auto Scaling group to replace unhealthy instances.
Auto Scaling groups automatically monitor instance health and terminate instances that fail checks, replacing them with new ones. This self-healing mechanism is vital for maintaining consistent capacity and ensuring that the application continues to run without human intervention, which is a key component of building a resilient and scalable cloud architecture.
C
Use a single large EC2 instance instead of multiple smaller ones.
Why it fails: Relying on a single large instance creates a single point of failure. If that instance fails, the application goes down immediately. Using multiple smaller instances in a load-balanced configuration is significantly more resilient because the failure of one instance does not result in total service downtime for the application's users.
D
Implement health checks for the load balancer to monitor instances.
Load balancer health checks ensure that traffic is only routed to healthy instances. By continuously monitoring the status of the application, the load balancer can detect failures and redirect requests, preventing users from experiencing errors and ensuring that the application environment remains in a stable and responsive state at all times.
E
Place all instances in a single Auto Scaling group with a fixed capacity.
Why it fails: Fixed capacity does not allow the application to adapt to changes in traffic demand or recover from unexpected instance termination as effectively as dynamic scaling policies. While it provides basic capacity, it lacks the elasticity needed to maintain resilience during high-demand events or when multiple instances fail simultaneously due to issues.

Question 12hardmulti select

A company is designing a high-throughput, fault-tolerant payment processing system running on Amazon EC2 instances across multiple Availability Zones. The architecture must withstand the sudden failure of any single AZ without dropping active database transactions or corrupting state. Which TWO design practices should the solutions architect implement?

Trap 1: Store application state files on a single Amazon EBS General…

Amazon EBS volumes are tied to a specific Availability Zone and cannot span multiple zones natively. Relying on a single EBS volume creates a single point of failure that will cause data loss or downtime if that Availability Zone experiences an outage.

Trap 2: Configure an Amazon Route 53 latency-based routing policy to direct…

Route 53 latency-based routing optimizes performance globally across regions rather than managing intra-region Availability Zone failover. An Application Load Balancer should be used in front of EC2 instances for localized traffic distribution and health checking.

Trap 3: Pin all payment processing worker threads to a single static EC2…

Pinning all workload threads to a single EC2 instance eliminates fault tolerance and introduces a severe single point of failure. If that instance or its underlying host fails, the entire payment processing capability will experience an outage.

A
Deploy an Amazon Aurora database cluster configured across multiple Availability Zones with an automatic failover replica.
Amazon Aurora automatically replicates storage across three Availability Zones and promotes a read replica to primary within seconds if the primary instance fails. This prevents database downtime and protects against data corruption during infrastructure failures.
B
Store application state files on a single Amazon EBS General Purpose SSD attached to the primary EC2 instance.
Why it fails: Amazon EBS volumes are tied to a specific Availability Zone and cannot span multiple zones natively. Relying on a single EBS volume creates a single point of failure that will cause data loss or downtime if that Availability Zone experiences an outage.
C
Configure an Amazon Route 53 latency-based routing policy to direct user traffic directly to EC2 instances in each zone.
Why it fails: Route 53 latency-based routing optimizes performance globally across regions rather than managing intra-region Availability Zone failover. An Application Load Balancer should be used in front of EC2 instances for localized traffic distribution and health checking.
D
Distribute Amazon EC2 instances across an Auto Scaling group configured with subnets spanning at least three Availability Zones.
Spanning an Auto Scaling group across multiple Availability Zones allows AWS to automatically launch replacement instances in healthy zones if one zone fails. This maintains required compute capacity and preserves application availability without manual intervention.
E
Pin all payment processing worker threads to a single static EC2 instance to simplify debugging and transaction logging.
Why it fails: Pinning all workload threads to a single EC2 instance eliminates fault tolerance and introduces a severe single point of failure. If that instance or its underlying host fails, the entire payment processing capability will experience an outage.

Question 13mediummultiple choice

A web application runs on Amazon EC2 instances managed by an Auto Scaling group across three Availability Zones behind an Application Load Balancer. The application performs heavy computations that consume high CPU resources. Users report intermittent 504 Gateway Timeouts during peak hours. The solutions architect notices that newly launched instances take several minutes to bootstrap before they can serve traffic. How should the architect resolve this issue?

Trap 1: Configure an Amazon SQS queue in front of the EC2 instances to…

Asynchronous queueing decouples request submission from processing but does not shorten the several-minute bootstrap delay that leaves new instances unable to serve traffic, so 504s persist. It tempts because SQS genuinely absorbs spikes for workloads that tolerate deferred results, which this synchronous web application does not.

Trap 2: Switch the load balancer from an Application Load Balancer to a…

A Network Load Balancer forwards TCP without terminating HTTP, so it cannot generate or mitigate 504 Gateway Timeouts, and it does nothing about slow instance bootstrap. It tempts because NLB reduces latency for extreme-throughput or non-HTTP workloads, which is the actual reason to choose it.

Trap 3: Decrease the Auto Scaling group health check grace period to zero…

A zero grace period makes Auto Scaling terminate instances mid-bootstrap before they register as healthy, causing replacement loops rather than fixing the timeout. It tempts because shortening grace periods genuinely helps when health checks are misconfigured and instances are wrongly marked unhealthy.

A
Configure an Amazon SQS queue in front of the EC2 instances to offload computational tasks asynchronously.
Why it fails: Asynchronous queueing decouples request submission from processing but does not shorten the several-minute bootstrap delay that leaves new instances unable to serve traffic, so 504s persist. It tempts because SQS genuinely absorbs spikes for workloads that tolerate deferred results, which this synchronous web application does not.
B
Implement pre-baked Amazon Machine Images (AMIs) with application code pre-installed and configure an Auto Scaling health check grace period.
Pre-baked AMIs remove the multi-minute bootstrap, so new instances serve traffic almost immediately and scale out before peak load causes 504s. The health check grace period prevents the Auto Scaling group terminating instances that are still initialising, avoiding premature replacement.
C
Switch the load balancer from an Application Load Balancer to a Network Load Balancer for faster TCP packet routing.
Why it fails: A Network Load Balancer forwards TCP without terminating HTTP, so it cannot generate or mitigate 504 Gateway Timeouts, and it does nothing about slow instance bootstrap. It tempts because NLB reduces latency for extreme-throughput or non-HTTP workloads, which is the actual reason to choose it.
D
Decrease the Auto Scaling group health check grace period to zero so failing instances are replaced immediately.
Why it fails: A zero grace period makes Auto Scaling terminate instances mid-bootstrap before they register as healthy, causing replacement loops rather than fixing the timeout. It tempts because shortening grace periods genuinely helps when health checks are misconfigured and instances are wrongly marked unhealthy.

Question 14mediummultiple choice

A video transcoding application runs on EC2 instances. The processing is highly CPU-intensive and can be interrupted if the job is resumed later. Which compute strategy offers the best cost-performance balance?

Trap 1: Use Reserved Instances for the entire workload.

Reserved Instances require a long-term commitment and are best for predictable, steady-state workloads. Since the transcoding application's processing needs might vary, paying for fixed capacity is inefficient compared to using Spot Instances for burstable or highly flexible workloads that can handle interruptions and dynamic scaling requirements.

Trap 2: Use On-Demand instances for all processing tasks.

On-Demand instances are expensive for large-scale, CPU-intensive batch processing. While they offer reliability, they do not provide the cost efficiency required for this workload type. Spot Instances are explicitly designed for workloads like transcoding where cost savings are prioritized over constant, guaranteed availability of specific instances.

Trap 3: Use Dedicated Hosts for the transcoding tasks.

Dedicated Hosts are used for compliance and licensing requirements where physical server isolation is mandatory. They are the most expensive compute option and provide no performance benefit for this type of distributed transcoding workload. Using them would unnecessarily inflate costs without improving the actual processing throughput of the application.

A
Use Reserved Instances for the entire workload.
Why it fails: Reserved Instances require a long-term commitment and are best for predictable, steady-state workloads. Since the transcoding application's processing needs might vary, paying for fixed capacity is inefficient compared to using Spot Instances for burstable or highly flexible workloads that can handle interruptions and dynamic scaling requirements.
B
Use On-Demand instances for all processing tasks.
Why it fails: On-Demand instances are expensive for large-scale, CPU-intensive batch processing. While they offer reliability, they do not provide the cost efficiency required for this workload type. Spot Instances are explicitly designed for workloads like transcoding where cost savings are prioritized over constant, guaranteed availability of specific instances.
C
Use Spot Instances for the transcoding tasks.
Spot Instances are ideal for fault-tolerant, batch-oriented workloads like video transcoding. They offer significant cost savings, and since the application can handle interruptions by resuming jobs, the risk associated with Spot capacity reclamation is mitigated, resulting in an optimal high-performance and low-cost architectural design for this specific use case.
D
Use Dedicated Hosts for the transcoding tasks.
Why it fails: Dedicated Hosts are used for compliance and licensing requirements where physical server isolation is mandatory. They are the most expensive compute option and provide no performance benefit for this type of distributed transcoding workload. Using them would unnecessarily inflate costs without improving the actual processing throughput of the application.

Question 15mediummultiple choice

A company is migrating a web application to AWS. The application relies on session state. Which approach is the most scalable and performant for managing sessions?

Trap 1: Store sessions in a local file on the web server.

Storing sessions locally makes the application stateful, preventing easy horizontal scaling. If a user is routed to a different server due to load balancing, their session will be lost. This is a significant anti-pattern for scalable, distributed web applications and results in poor user experiences.

Trap 2: Store sessions in a relational database like RDS.

Storing session data in a relational database is slow due to disk I/O and query overhead. As session volume increases, the database becomes a bottleneck for the entire application. In-memory storage like ElastiCache is specifically designed for this type of high-frequency, low-latency access requirement.

Trap 3: Use sticky sessions on the Application Load Balancer.

Sticky sessions force a user to connect to the same backend instance. While this solves the session issue, it creates uneven load distribution and prevents the application from truly scaling horizontally. If an instance fails, the session is lost. It is less robust than using external session storage.

A
Store sessions in a local file on the web server.
Why it fails: Storing sessions locally makes the application stateful, preventing easy horizontal scaling. If a user is routed to a different server due to load balancing, their session will be lost. This is a significant anti-pattern for scalable, distributed web applications and results in poor user experiences.
B
Use Amazon ElastiCache (Redis) to store session data.
ElastiCache provides sub-millisecond latency for session data access. By offloading session state to an external cache, the application servers become stateless, which allows for seamless horizontal scaling. This architecture is both highly performant and the industry-standard approach for managing sessions in distributed, high-scale applications.
C
Store sessions in a relational database like RDS.
Why it fails: Storing session data in a relational database is slow due to disk I/O and query overhead. As session volume increases, the database becomes a bottleneck for the entire application. In-memory storage like ElastiCache is specifically designed for this type of high-frequency, low-latency access requirement.
D
Use sticky sessions on the Application Load Balancer.
Why it fails: Sticky sessions force a user to connect to the same backend instance. While this solves the session issue, it creates uneven load distribution and prevents the application from truly scaling horizontally. If an instance fails, the session is lost. It is less robust than using external session storage.

Question 16hardmulti select

An application uses a monolithic architecture on EC2 instances. The company wants to improve resilience against regional failures. Which TWO actions should the architect take to achieve this? (Select TWO.)

Trap 1: Deploy the application to multiple Availability Zones within a…

Multi-AZ deployment provides high availability against localized data center failures but does not protect against full regional outages. While it is a best practice for general availability, it fails to meet the specific requirement of regional resilience requested in the scenario.

Trap 2: Use an AWS Direct Connect connection to link the two regions.

Direct Connect is intended for private connectivity between an on-premises data center and AWS, not for replicating data between two AWS regions. While it provides consistent network performance, it does not solve the challenge of regional application failover or state synchronization between regions.

Trap 3: Increase the minimum number of EC2 instances in the Auto Scaling…

Increasing the instance count improves capacity and localized redundancy but does not mitigate risks associated with regional outages. If the entire region goes down, the increased instance count remains unreachable, failing to address the fundamental requirement of regional resilience and disaster recovery planning.

A
Deploy the application to multiple Availability Zones within a single region.
Why it fails: Multi-AZ deployment provides high availability against localized data center failures but does not protect against full regional outages. While it is a best practice for general availability, it fails to meet the specific requirement of regional resilience requested in the scenario.
B
Configure Amazon Route 53 with failover routing policies to a secondary region.
Route 53 failover routing policies monitor the health of primary region endpoints. If health checks fail, traffic is automatically routed to the secondary region. This is a foundational step in building a resilient multi-region architecture that provides automated business continuity during a regional disaster.
C
Implement Amazon Aurora Global Database for cross-region data replication.
Aurora Global Database enables fast, low-latency cross-region replication. This ensures that the secondary region has an up-to-date copy of the primary database. In the event of a regional failure, the global database can be promoted to provide full read-write capabilities in the failover region.
D
Use an AWS Direct Connect connection to link the two regions.
Why it fails: Direct Connect is intended for private connectivity between an on-premises data center and AWS, not for replicating data between two AWS regions. While it provides consistent network performance, it does not solve the challenge of regional application failover or state synchronization between regions.
E
Increase the minimum number of EC2 instances in the Auto Scaling group.
Why it fails: Increasing the instance count improves capacity and localized redundancy but does not mitigate risks associated with regional outages. If the entire region goes down, the increased instance count remains unreachable, failing to address the fundamental requirement of regional resilience and disaster recovery planning.

Question 17mediummulti select

A media company experiences unpredictable traffic spikes on its web application. The architect needs to ensure the application remains responsive while optimizing for performance. Which TWO strategies should be implemented? (Select TWO.)

Trap 1: Use a Simple Scaling Policy with a large cooldown period.

Simple scaling policies are less responsive than target tracking because they wait for a specific alarm and cooldown period before taking further action. Large cooldown periods can lead to performance degradation during rapid traffic spikes because the system cannot add new instances quickly enough to meet demand.

Trap 2: Provision IOPS (io2) for all EC2 root volumes.

While provisioned IOPS improve disk performance, they do not address the scaling requirements of a web application facing traffic spikes. Root volumes for web servers typically do not require high IOPS for request handling; instead, the bottleneck is usually CPU, memory, or network bandwidth.

Trap 3: Implement vertical scaling by increasing instance sizes manually.

Vertical scaling requires stopping and starting instances to change their size, which causes downtime and is not a viable strategy for handling unpredictable traffic spikes. Horizontal scaling through Auto Scaling is the preferred AWS architecture for ensuring high performance and availability for web applications.

A
Configure a Target Tracking Scaling Policy for the Auto Scaling group.
Target tracking scaling policies allow the Auto Scaling group to maintain a specific metric value, such as average CPU utilization. This approach ensures the application scales out proactively to handle incoming traffic spikes while scaling in during low activity to maintain optimal performance and cost-efficiency.
B
Use a Simple Scaling Policy with a large cooldown period.
Why it fails: Simple scaling policies are less responsive than target tracking because they wait for a specific alarm and cooldown period before taking further action. Large cooldown periods can lead to performance degradation during rapid traffic spikes because the system cannot add new instances quickly enough to meet demand.
C
Deploy Amazon CloudFront in front of the Application Load Balancer.
Amazon CloudFront caches content at edge locations, which significantly reduces the latency for end-users and decreases the request load on the backend web servers. This allows the application to handle much higher traffic volumes without requiring a proportional increase in expensive EC2 compute resources.
D
Provision IOPS (io2) for all EC2 root volumes.
Why it fails: While provisioned IOPS improve disk performance, they do not address the scaling requirements of a web application facing traffic spikes. Root volumes for web servers typically do not require high IOPS for request handling; instead, the bottleneck is usually CPU, memory, or network bandwidth.
E
Implement vertical scaling by increasing instance sizes manually.
Why it fails: Vertical scaling requires stopping and starting instances to change their size, which causes downtime and is not a viable strategy for handling unpredictable traffic spikes. Horizontal scaling through Auto Scaling is the preferred AWS architecture for ensuring high performance and availability for web applications.

Question 18hardmultiple choice

A data analytics company uses Amazon Redshift for complex queries. The workload is mostly consistent but experiences heavy spikes during the last three days of every month. What is the most cost-effective way to handle these spikes?

Trap 1: Manually resize the Redshift cluster to a larger size during the…

Manual resizing (Classic Resize) can take several hours or even days depending on data volume, during which the cluster may be in read-only mode. While Elastic Resize is faster, both methods require manual intervention and involve paying for higher capacity 24/7 during those three days, which is less efficient than automated scaling.

Trap 2: Use a Redshift Serverless workgroup for the monthly reporting tasks.

Redshift Serverless is a great option for variable workloads, but migrating an existing, fine-tuned provisioned cluster to serverless just for a 3-day monthly spike is complex and potentially more expensive. Concurrency Scaling allows the company to keep their optimized provisioned cluster while handling spikes seamlessly and economically.

Trap 3: Move the data to Amazon S3 and use Amazon Athena for the monthly…

While Athena is cost-effective (pay-per-query), it may not provide the same performance or support the complex SQL features utilized in the Redshift environment. Moving large datasets from Redshift to S3 monthly would also incur significant data movement and operational costs that would likely outweigh the savings from using Athena.

A
Manually resize the Redshift cluster to a larger size during the last three days.
Why it fails: Manual resizing (Classic Resize) can take several hours or even days depending on data volume, during which the cluster may be in read-only mode. While Elastic Resize is faster, both methods require manual intervention and involve paying for higher capacity 24/7 during those three days, which is less efficient than automated scaling.
B
Enable Redshift Concurrency Scaling for the cluster.
Concurrency Scaling is designed for exactly this scenario. It provides extra compute power when needed and scales back down when the spike is over. Since Redshift offers free Concurrency Scaling credits for every 24 hours the main cluster is running, the company may even handle these spikes at no additional cost.
C
Use a Redshift Serverless workgroup for the monthly reporting tasks.
Why it fails: Redshift Serverless is a great option for variable workloads, but migrating an existing, fine-tuned provisioned cluster to serverless just for a 3-day monthly spike is complex and potentially more expensive. Concurrency Scaling allows the company to keep their optimized provisioned cluster while handling spikes seamlessly and economically.
D
Move the data to Amazon S3 and use Amazon Athena for the monthly spikes.
Why it fails: While Athena is cost-effective (pay-per-query), it may not provide the same performance or support the complex SQL features utilized in the Redshift environment. Moving large datasets from Redshift to S3 monthly would also incur significant data movement and operational costs that would likely outweigh the savings from using Athena.

Question 19mediummultiple choice

A company hosts a web application on EC2 instances behind an Application Load Balancer (ALB). The application requires high availability across two Availability Zones (AZs). Which architectural design ensures the most resilient traffic distribution?

Trap 1: Deploy all instances in one AZ and use a Route 53 failover policy…

Relying on a single AZ creates a single point of failure within the region, violating high availability requirements. While multi-region failover provides disaster recovery, it does not address the need for low-latency, resilient local traffic distribution between AZs as requested by the architectural design scope.

Trap 2: Use an Auto Scaling group with a single AZ and enable Cross-Zone…

Cross-zone load balancing distributes traffic across instances in multiple AZs, but if the single AZ fails, the entire application becomes unavailable. Resilience requires distributing instances across multiple physically separate AZs to ensure that infrastructure failures in one location do not impact the overall application availability.

Trap 3: Use a Network Load Balancer (NLB) with static IP addresses for each…

Static IP addressing provides reachability but does not provide fault tolerance if the AZ housing the instances suffers a failure. Resilience is achieved by decoupling the traffic entry point from specific compute locations, allowing the architecture to survive the loss of an entire data center facility.

A
Deploy all instances in one AZ and use a Route 53 failover policy to a secondary region.
Why it fails: Relying on a single AZ creates a single point of failure within the region, violating high availability requirements. While multi-region failover provides disaster recovery, it does not address the need for low-latency, resilient local traffic distribution between AZs as requested by the architectural design scope.
B
Use an Auto Scaling group with a single AZ and enable Cross-Zone Load Balancing on the ALB.
Why it fails: Cross-zone load balancing distributes traffic across instances in multiple AZs, but if the single AZ fails, the entire application becomes unavailable. Resilience requires distributing instances across multiple physically separate AZs to ensure that infrastructure failures in one location do not impact the overall application availability.
C
Place EC2 instances in an Auto Scaling group distributed across two AZs behind the ALB.
Distributing Auto Scaling groups across multiple AZs ensures that if one AZ experiences an outage, instances in the other AZ continue serving traffic. The ALB automatically routes requests to healthy targets across the available zones, maintaining service continuity and ensuring the application remains resilient against localized hardware or power failures.
D
Use a Network Load Balancer (NLB) with static IP addresses for each instance in one AZ.
Why it fails: Static IP addressing provides reachability but does not provide fault tolerance if the AZ housing the instances suffers a failure. Resilience is achieved by decoupling the traffic entry point from specific compute locations, allowing the architecture to survive the loss of an entire data center facility.