2.1 - Selecting compute, storage and data services

1. A team wants blue/green deployments for an ECS service so a bad release can be rolled back in seconds with no in-place restarts. Which service orchestrates that shift?

• AWS Systems Manager Run Command pushing scripts to each task
• AWS CodeDeploy with an ECS blue/green deployment group (correct answer)
• Amazon EC2 Auto Scaling lifecycle hooks that pause launches
• AWS Config rules running automatic remediation actions

CodeDeploy drives ECS blue/green deployments: it stands up a new task set, shifts traffic via the load balancer, and can roll back instantly by shifting back. Run Command runs scripts, ASG hooks pause scaling events, and Config remediates compliance drift.

2. A stateless web fleet on EC2 must keep average CPU utilization around 50% as traffic rises and falls throughout the day, with the group adjusting capacity on its own. Which Auto Scaling policy meets this most simply?

• A target tracking policy on average CPU utilization (correct answer)
• A set of step scaling policies with several tuned CloudWatch alarm thresholds
• A scheduled action that adds instances every morning and removes them at night
• A simple scaling policy with a fixed cooldown after each adjustment

Target tracking keeps a chosen metric (here CPU) at a target value by automatically computing the needed capacity, like a thermostat. Step scaling needs manually tuned thresholds, scheduled actions only fit known time patterns, and simple scaling reacts one alarm at a time with cooldown gaps.

3. An application has a steep, recurring traffic surge every weekday at 09:00, and reactive scaling alone leaves it under-provisioned for the first several minutes while new instances boot. What best removes that morning cold-start gap?

• Lower the target tracking value so the group reacts earlier to CPU
• Enlarge the instance type so fewer instances are needed at the peak
• Enable predictive scaling to pre-provision capacity ahead of the forecast surge (correct answer)
• Shorten the health check grace period so instances register into service faster during scale-out

Predictive scaling uses machine learning on historical patterns to launch capacity before a recurring surge, closing the boot-time gap that reactive policies cannot. Lowering the target still reacts after load arrives, larger instances still boot, and a shorter grace period risks routing to instances that are not ready.

4. An Auto Scaling group of EC2 instances with a long, heavy application bootstrap is scaling out too slowly during spikes, and the team also needs each instance drained cleanly before termination so in-flight work finishes. Which TWO features address these problems? (Choose TWO.)

• Raise the group's maximum size so more instances can eventually launch during a spike
• A warm pool of pre-initialized instances kept ready to serve during a spike (correct answer)
• A termination lifecycle hook that delays shutdown until connections drain (correct answer)
• A shorter default cooldown so scaling actions can happen back to back

A warm pool keeps instances already bootstrapped so they enter service in seconds during a spike, and a termination lifecycle hook pauses shutdown so in-flight requests drain before the instance is removed. Raising max size does not speed each launch, and a shorter cooldown just fires actions more often without fixing slow boot or ungraceful termination.

5. A web application stores user session state in memory on each EC2 instance, so scaling in during quiet periods logs users out when their instance is terminated. What is the best design to let the tier scale freely without losing sessions?

• Enable sticky sessions on the load balancer so a user always returns to the same instance
• Increase the scale-in cooldown so instances are terminated much less frequently
• Take frequent AMIs of each instance so session memory can be restored after termination
• Store session state in Amazon ElastiCache so instances become stateless (correct answer)

Externalizing session state to ElastiCache (Redis) makes instances stateless, so any instance can serve any user and scaling in never loses sessions. Sticky sessions still tie a user to an instance that may be terminated, longer cooldowns only delay the problem, and AMIs cannot restore live in-memory sessions.

6. A Linux-based content management cluster needs a shared POSIX file system mounted read-write by hundreds of EC2 instances across multiple Availability Zones, scaling capacity automatically. Which service fits?

• Amazon Elastic File System (EFS) (correct answer)
• An Amazon EBS io2 volume attached to the fleet
• Amazon FSx for Windows File Server
• An S3 bucket mounted with a third-party FUSE driver

EFS is a fully managed, elastic NFS file system that many Linux instances across AZs can mount read-write simultaneously, growing automatically. EBS attaches to few instances in one AZ, FSx for Windows serves SMB/Windows workloads, and an S3 FUSE mount is not a true POSIX file system.