Auto Scaling practice questions

Launch the database instance in a public subnet.

Why it fails: A public subnet exposes the RDS instance to internet routing, contradicting the requirement that the database be unreachable from the internet. Public subnets are tempting because they suit internet-facing load balancers and bastion hosts, but RDS belongs in private subnets reachable only from the web tier's security group.

Store database credentials in AWS Systems Manager Parameter Store.

Why it fails: Parameter Store secures credential storage and rotation, but it neither restricts database access to a specific port nor removes internet reachability, so it fails the stated security objectives. It is tempting because it is a genuine best practise for secrets management, and would be correct if the question asked how to avoid hard-coded credentials.

AWS Lambda with scheduled scaling

Why it fails: Lambda cannot run or scale the existing EC2 fleet, and scheduled scaling triggers on time, not CPU utilisation. It is tempting because Lambda is serverless and event-driven, and would be correct for scheduled batch jobs or event-triggered functions rather than load-driven EC2 scaling.

Amazon CloudFront with origin scaling

Why it fails: CloudFront caches and delivers content at edge locations; it has no origin scaling capability and cannot add EC2 capacity from CPU metrics. It is tempting because it fronts web applications, and would be correct for reducing latency and offloading static content, not for scaling compute.

AWS Elastic Beanstalk with environment scaling

Why it fails: Elastic Beanstalk manages its own environment and scaling policies, which conflicts with the requirement to scale the existing EC2 fleet behind an Application Load Balancer directly from CPU metrics. It is tempting as a managed platform, and would be correct for deploying a new application without existing infrastructure.

Use a scheduled scaling policy to add or remove instances based on historical usage patterns.

Why it fails: Scheduled scaling acts on time-based predictions, not the live active-user metric, so it cannot track variable workload. It is tempting because it suits predictable diurnal traffic patterns, and would be correct if usage followed a known schedule rather than fluctuating with concurrent users.

Use AWS Lambda to periodically evaluate the custom metric and adjust the desired capacity via API calls.

Why it fails: Lambda polling adds custom code, invocation latency and API throttling risk versus native metric-driven scaling. It is tempting because it offers arbitrary logic, and would be correct where no CloudWatch metric can express the scaling signal and bespoke evaluation is genuinely required.

Create a step scaling policy that uses CloudWatch alarms based on the custom metric.

Why it fails: Step scaling adjusts capacity in predefined bands from a CloudWatch alarm, adding tuning overhead and coarser response than target tracking on the custom metric. It is tempting for non-linear thresholds, and would be correct if capacity needed distinct step increments at specific metric values.

Increase the instance size to handle more load per instance.

Why it fails: Vertical scaling raises per-instance capacity but cannot respond automatically to sudden spikes; the Auto Scaling group still lacks a scaling policy, so no new instances launch. It suits steady, predictable growth where instance count stays fixed and each node simply needs more CPU or memory.

Manually increase the desired capacity when traffic spikes.

Why it fails: Manual capacity changes require human intervention, directly contradicting the requirement for automatic handling of sudden spikes. It fits planned, one-off events where an operator is present and traffic timing is known in advance, not unpredictable demand.

Use scheduled scaling to add instances at expected peak times.

Why it fails: Scheduled scaling acts on a calendar, so it cannot react to unplanned spikes arriving outside the configured windows. It is the right choice for predictable daily or weekly peaks, such as a batch job or known business-hours load.

Add Amazon ElastiCache to cache database queries.

Why it fails: ElastiCache offloads database reads, but the stem attributes latency spikes to EC2 CPU utilisation, so caching queries does not relieve the saturated compute. It tempts because ElastiCache genuinely reduces latency when the bottleneck is repeated database access rather than instance CPU.

Use Spot Instances to reduce costs and scale horizontally.

Why it fails: Spot Instances are reclaimed on two-minute interruption notices and do not lower per-request CPU consumption, so latency spikes persist and capacity becomes unreliable. It tempts because Spot genuinely cuts cost for interruption-tolerant, stateless or batch workloads, not latency-sensitive web tiers.

Increase the EC2 instance size to handle peak loads.

Why it fails: Vertical scaling to a larger instance size raises the ceiling but leaves capacity fixed between changes, so peak-hour CPU contention persists and cost scales with idle headroom. It is tempting for steady, predictable workloads, yet the scenario needs elastic horizontal scaling driven by demand.

Store session state in Amazon DynamoDB

Why it fails: DynamoDB is a key-value store, not a session cache; it adds per-request latency and cost compared with ElastiCache, and the ALB cannot route by session ID. It is tempting because DynamoDB offers durable, highly available storage, and would suit persistent user profile or order data rather than ephemeral session state.

Store session state on the local instance store of each EC2 instance

Why it fails: Instance store is ephemeral and tied to one EC2 instance, so sessions vanish on stop or replacement and are invisible to other instances behind the ALB. It is tempting for its low latency and zero cost, and would be correct for scratch data or temporary caches that can be regenerated.

Store session state in Amazon S3

Why it fails: S3 offers no low-latency atomic read-modify-write for concurrent session updates, and the ALB cannot route requests by session ID. It is tempting because S3 is durable, highly available and cheap, and would be correct for storing static assets, logs or backups rather than live session state.

Store logs on an EBS volume and take regular snapshots.

Why it fails: An EBS volume is tied to one Availability Zone and one instance attachment; when the application tier instance is terminated by scaling, the volume detaches and logs written since the last snapshot are lost. Snapshots suit periodic backup of persistent data, not continuous log retention across ephemeral instances.

Write logs to the instance store volume of each EC2 instance.

Why it fails: Instance store is physically attached to the host and its data is erased on instance stop, termination, or host failure, so logs vanish exactly when scaling replaces the instance. It tempts because it offers high-throughput local writes, but it suits temporary scratch or cache data, never durable log retention.

Write logs to an Amazon S3 bucket mounted on each instance using NFS.

Why it fails: Mounting S3 over NFS still leaves each instance writing to its own mount; when the instance terminates, in-flight writes and any local caching are lost, and S3's NFS interface is not designed for concurrent log appends. It tempts because S3 offers durable object storage, but direct SDK or agent delivery is the correct pattern.

Use Amazon RDS for MySQL with Multi-AZ and read replicas, and implement a caching layer using Amazon ElastiCache.

Why it fails: RDS is a relational database that requires manual scaling and is not designed for the massive write throughput and automatic scaling of DynamoDB. While ElastiCache can reduce read latency, the underlying RDS instance may become a bottleneck under 100,000 requests per second. This solution is more complex and costly to scale.

Use DynamoDB with provisioned capacity mode and set up Auto Scaling with a target utilization of 70%.

Why it fails: Provisioned mode with Auto Scaling still requires setting minimum and maximum capacity, and scaling takes time to react to sudden bursts. For a spiky workload like real-time bidding, this can lead to throttling during rapid increases. It also may over-provision during low traffic, increasing cost. It does not provide the microsecond read latency that DAX offers.

Use Amazon Aurora Serverless v2 with auto-scaling and enable Aurora Global Database for low-latency reads.

Why it fails: Aurora Serverless v2 scales automatically but is still a relational database with higher latency than DynamoDB for key-value access patterns. It is not optimized for the extreme write throughput of real-time bidding. Global Database adds cross-region replication, which increases cost and complexity without addressing the need for microsecond read latency.

Use Amazon Aurora (MySQL-compatible) with Multi-AZ.

Why it fails: Aurora is MySQL- and PostgreSQL-compatible and cannot run Oracle schemas or PL/SQL, so the existing database would need rewriting. Aurora Multi-AZ is genuinely highly available with automated failover, making it correct only when the engine is MySQL or PostgreSQL, not Oracle.

Use Amazon RDS for Oracle with a Read Replica in another AZ.

Why it fails: An RDS for Oracle Read Replica is asynchronous and read-only; it provides no automated failover, so promotion is manual and data loss is possible. Read Replicas serve read scaling. Multi-AZ Oracle, which maintains a synchronous standby with automatic failover, is the correct choice here.

Deploy Oracle on EC2 in two Availability Zones and use asynchronous replication.

Why it fails: Oracle on EC2 with asynchronous replication leaves failover entirely to custom scripting, so recovery is manual and recent transactions may be lost. EC2 hosting suits engine versions or options RDS cannot offer. RDS for Oracle Multi-AZ provides the synchronous standby and automated failover the scenario demands.

Increase the deployment timeout in the CodeDeploy deployment group to allow more time for validation.

Why it fails: Extending the deployment timeout only lets failing validation scripts run longer before the deployment aborts; the scripts still fail. It is tempting because timeouts do cause deployment failures, so raising the value is correct when validation legitimately needs more time than the configured window.

Configure an Auto Scaling lifecycle hook to perform health checks before the instance is placed in service.

Why it fails: A lifecycle hook delays instance termination or launch; it cannot fix validation scripts failing on already-running, in-service instances. It is tempting because lifecycle hooks genuinely gate instance health during scale-in and scale-out events, which is the right control when instances enter service unhealthy.

AWS Lambda functions to process each file.

Why it fails: AWS Lambda caps execution at 15 minutes, so a 2-hour CPU-intensive file cannot complete within a single invocation. It is tempting because Lambda suits short, event-driven S3 processing with no idle capacity, and would be correct for sub-15-minute tasks triggered per object.

Auto Scaling group with scheduled scaling policies.

Why it fails: Scheduled scaling follows a time-based calendar, so it cannot react to unpredictable S3 upload arrivals and leaves capacity idle between batches. It is tempting for predictable traffic patterns, but this workload needs event-driven scaling from queue depth or CloudWatch alarms.

Use lifecycle hooks to save session data to Amazon S3 before instance termination.

Why it fails: Lifecycle hooks fire on termination and cannot persist sessions for requests already in flight, so users still lose state during scale-in. They suit graceful draining, deregistration or cleanup tasks, not continuous session storage that must survive instance replacement.

Enable sticky sessions (session affinity) on the Application Load Balancer.

Why it fails: Session affinity pins a client to one instance, so terminating that instance still destroys the session; it cannot preserve state across scale-in. Sticky sessions suit short-lived state or caching on stable fleets, not sessions that must survive instance termination.

Increase the Auto Scaling group's cooldown period to prevent rapid scaling.

Why it fails: Cooldown merely delays subsequent scaling activities; it does not stop the terminating instance from discarding its in-memory sessions. Cooldown periods suit smoothing flapping metrics and avoiding thrashing, not preserving state that must outlive any individual instance.

Amazon CloudFront

Why it fails: CloudFront is a content delivery network that caches and serves content from edge locations; it does not load-balance traffic across EC2 instances in an Auto Scaling group. It is tempting because it fronts origins, but the required distribution is handled by Application Load Balancer or Network Load Balancer.

AWS Global Accelerator

Why it fails: Global Accelerator routes traffic over the AWS global network to regional endpoints using static anycast IP addresses; it does not balance requests across EC2 instances in an Auto Scaling group. It is tempting for multi-Region failover, but the required distribution uses Application Load Balancer or Network Load Balancer.

Amazon Route 53

Why it fails: Route 53 is a DNS service that resolves names to endpoints, including weighted and latency routing; it does not distribute traffic across instances within an Auto Scaling group. It is tempting because it can steer traffic between regions, but here the load balancing is done by Application Load Balancer or Network Load Balancer.

Use Amazon EC2 Auto Scaling to add more Fargate tasks.

Why it fails: EC2 Auto Scaling manages EC2 instances, not Fargate tasks; Fargate capacity is scaled through ECS Service Auto Scaling using Application Auto Scaling target tracking. It is tempting because the name suggests generic compute scaling, and it would be correct for an ECS cluster using the EC2 launch type with instance capacity to expand.

Use AWS Auto Scaling Plans with predictive scaling.

Why it fails: Predictive scaling requires historical traffic data spanning at least 14 days to generate forecasts, but the scenario describes a new application with variable patterns and no existing usage history, so the algorithm cannot build a baseline. It is tempting because predictive scaling proactively provisions capacity ahead of demand spikes, which would be correct for a mature application with stable, repeating traffic cycles.

Manually adjust the desired count of tasks in the ECS service based on traffic analysis.

Why it fails: Manual desired-count changes require human intervention and cannot respond to variable traffic patterns, contradicting the automatic scaling requirement. It is tempting because it offers direct control and zero configuration, and would suit predictable, scheduled workloads where capacity is known in advance and cost control outweighs responsiveness.

Disable cross-zone load balancing on the NLB.

Why it fails: Cross-zone load balancing governs how the NLB distributes traffic across availability zones; it does not create flow affinity, so sessions still break when instances are added or removed. It is tempting because zone settings affect routing, but stickiness requires source IP affinity or a load balancer that tracks sessions.

Enable cookie-based stickiness on the NLB listener.

Why it fails: NLB listeners support flow-hash-based stickiness, not cookie-based stickiness; cookie stickiness is an Application Load Balancer feature. It is tempting because cookie stickiness is the standard session-persistence mechanism, making it correct behind an ALB, but the NLB cannot generate or inspect HTTP cookies.

Switch to an Application Load Balancer and enable cookie-based stickiness.

Why it fails: An Application Load Balancer operates at layer 7 and terminates HTTP, so it cannot preserve the layer 4 TCP flows this stateful application relies on; scaling events still sever sessions. It is tempting because cookie stickiness is the usual persistence mechanism, and it would be correct for HTTP workloads.

Use a single EC2 instance in one AZ and a standby instance in another AZ

Why it fails: A single instance with a standby in another AZ provides no automatic failover; recovery requires manual intervention or a script, so instance failure is not handled automatically. It is tempting because cross-AZ standby is a recognised DR pattern, and would be correct for cost-sensitive workloads tolerating manual recovery, not automatic HA.

Use AWS Elastic Beanstalk with a single instance environment

Why it fails: A single-instance Elastic Beanstalk environment runs one EC2 instance with no load balancer or Auto Scaling group, so an instance failure is not automatically recovered. It is tempting because Beanstalk handles deployment and platform configuration, and would be correct for development or low-traffic environments, not production HA.

Use AWS CloudFormation to launch a single instance in each AZ

Why it fails: CloudFormation launches the instances once but does not monitor or replace them; a failed instance stays failed until the stack is updated or re-run. It is tempting because CloudFormation gives repeatable, versioned infrastructure provisioning, and would be correct for standardised deployments, not for automatic instance recovery.

Use an Auto Scaling group with a target tracking scaling policy based on CPU utilization. Use Amazon SQS to queue read requests during peak traffic.

Why it fails: SQS queues requests for asynchronous processing; it does not increase Aurora's read throughput, and the web tier would still wait on the database. Queuing suits decoupling background workloads, but Aurora Replicas with Auto Scaling serve the additional read traffic directly.

Use an Auto Scaling group with a simple scaling policy based on CPU utilization. Use DynamoDB Auto Scaling for the database.

Why it fails: Simple scaling reacts to alarms with cooldowns, so it lags variable traffic, and DynamoDB Auto Scaling cannot scale an Aurora MySQL database. DynamoDB suits key-value workloads, but the stem specifies Aurora, which scales reads through Aurora Replicas with Auto Scaling.

Use an Auto Scaling group with a step scaling policy based on CPU utilization. Use ElastiCache Auto Scaling to add cache nodes for read traffic.

Why it fails: ElastiCache caches query results in memory; it does not scale Aurora's read capacity, and the stem asks for the database to absorb increased read traffic automatically. Caching suits reducing repeated identical reads, but Aurora Replicas with Auto Scaling add genuine read endpoints.

Configure a simple scaling policy based on CPU utilization.

Why it fails: Simple scaling reacts only after CPU utilization breaches a threshold, and its cooldown delays further changes, so latency during a spike is not prevented. It suits steady workloads with gradual load shifts; anticipating traffic changes requires target tracking on a demand metric such as ALB requests per target.

Configure a scheduled scaling policy to add instances during known peak hours.

Why it fails: Scheduled scaling acts on wall-clock times, so it cannot anticipate spikes that do not align with a fixed timetable. It is right for predictable daily or weekly peaks, but the stem requires reacting to changing traffic patterns, which needs a target tracking policy driven by a load metric such as ALB request count per target.

Configure a target tracking scaling policy based on average CPU utilization.

Why it fails: Target tracking responds reactively to CPU already consumed, so scaling lags the spike rather than anticipating it. It suits steady workloads with defined thresholds, not predictive capacity. Scheduled scaling, driven by known traffic patterns, provisions instances before the surge arrives.

Weighted routing

Why it fails: Weighted routing distributes traffic by assigned proportions across records, ignoring user location, so it cannot deliver lowest-latency selection. It suits gradual traffic shifting, canary releases or A/B testing where controlled percentage splits matter, not proximity-based routing for active-active regions.

Failover routing

Why it fails: Failover routing directs traffic to a standby region only when the primary health check fails, so it cannot distribute load across active regions by proximity. It is tempting because it delivers resilience for disaster recovery, where a secondary region serves traffic only after the primary becomes unhealthy.

Geolocation routing

Why it fails: Geolocation routing maps users to regions by their geographic origin, which may not be the lowest-latency region and requires per-country or continent records. It suits content localisation, licensing or language requirements, not latency-optimised routing, which needs latency records instead.

Amazon RDS Single-AZ deployment with automated backups

Why it fails: Single-AZ deployment places the database in one Availability Zone, so no automatic failover to a second AZ occurs; automated backups restore data but do not provide multi-AZ high availability. It suits dev/test or cost-sensitive workloads tolerating downtime, not production systems needing minimal-downtime failover.

Amazon DynamoDB with global tables

Why it fails: DynamoDB is a NoSQL key-value store, so it cannot satisfy the stem's relational database requirement; global tables replicate across Regions, not Availability Zones. It would be correct for multi-Region, low-latency NoSQL workloads needing active-active replication, not relational multi-AZ failover.

Amazon RDS Read Replica

Why it fails: A Read Replica serves read scaling and can be promoted manually, but promotion is not automatic failover and introduces downtime; it also uses asynchronous replication. It would suit offloading read-heavy reporting traffic, not the stem's requirement for automatic multi-AZ failover with minimal downtime.