Task 2.1: Implement scalability and elasticity.

• ARaise the group's health check grace period to 300 seconds

  Incorrect

  The grace period keeps a new instance from being marked unhealthy and replaced too early. It does not keep the instance's metrics out of the scaling decision.

• BSet a default instance warmup of 300 seconds on the group

  Correct

  During the warmup, a new instance does not contribute usage data to the aggregated metrics, so its start-up CPU no longer drives more scaling.

• CRaise the group's default cooldown to 300 seconds after each scaling activity

  Incorrect

  The scaling cooldown applies to activities started by simple scaling policies, not to a target tracking policy.

• DTurn on instance scale-in protection for newly launched instances

  Incorrect

  Scale-in protection only stops protected instances from being terminated during scale-in. It does nothing about scale-out decisions.

AWS strongly recommends a default instance warmup for target tracking and step scaling policies so that instances that are still starting do not skew the group's metrics.

• AScheduled actions that raise the group's minimum capacity 30 minutes before the morning peak

  Incorrect

  Scheduled actions suit predictable changes, but someone must update the times and sizes by hand as the peak changes.

• BA step scaling policy with larger steps for the morning increase

  Incorrect

  Step scaling is still dynamic scaling, which reacts to load after it arrives, so the long initialization still causes the slow start.

• CA predictive scaling policy that forecasts load and launches capacity ahead of time

  Correct

  Predictive scaling learns daily and weekly patterns from history and launches capacity in advance of the forecast load, which helps applications that take long to initialize.

• DA lower target value, such as 20% CPU, for the target tracking policy

  Incorrect

  A lower target keeps more instances running at all hours, which is the over-provisioning the team wants to avoid.

Cyclical traffic plus slow-starting instances is the case AWS names for predictive scaling: capacity arrives before the load, without waiting for dynamic scaling to react.

• APut a DynamoDB Accelerator (DAX) cluster in front of the table

  Incorrect

  DAX speeds up repeated reads. AWS advises against it for write-intensive applications, and it does not add write capacity.

• BLower the auto scaling target utilization to 20% to keep more capacity in reserve

  Incorrect

  Auto scaling still reacts only after usage breaches the target for two consecutive minutes, and the team would pay for capacity it does not use.

• CTurn the table into a global table with a replica in a second Region

  Incorrect

  Global tables replicate data across Regions for multi-Region availability and local access. They do not stop throttling on a sudden spike.

• DSwitch the table from provisioned capacity to on-demand capacity mode

  Correct

  On-demand mode instantly accommodates traffic up to previously reached levels, bills per request, and charges no throughput when the table is idle.

Spiky, idle-in-between traffic with known peaks is what on-demand mode is for: no capacity planning and no charge for unused throughput.

• AConvert the DB instance to a Multi-AZ DB instance deployment

  Incorrect

  The standby in a Multi-AZ DB instance deployment cannot serve read traffic; it exists for failover.

• BCreate read replicas and send the read-only queries to them

  Correct

  Read replicas are read-only copies that take queries off the primary, which scales out read-heavy workloads.

• CTurn on storage autoscaling for the DB instance

  Incorrect

  Storage autoscaling adds storage when free space runs low. It does not reduce CPU used by queries.

• DCache query results in Amazon ElastiCache with a lazy loading strategy

  Correct

  With lazy loading the application reads from the cache first and goes to the database only on a miss, so repeated reads stop reaching the database.

• ERaise the backup retention period of the DB instance

  Incorrect

  The retention period controls how long automated backups are kept for point-in-time recovery, not how queries are served.

Read-heavy, rarely changing data is relieved in two ways: more copies that can answer reads, and a cache that answers repeated reads before they reach the database.

• AAdd Aurora Replicas and an Aurora Auto Scaling policy that adjusts how many there are

  Incorrect

  Aurora Auto Scaling adds and removes reader DB instances. The writer, which handles the write spikes, stays the same size.

• BChange the writer to an Aurora serverless DB instance with an ACU range

  Correct

  Aurora serverless scales capacity in half-ACU steps as the workload changes and bills per second for what it uses, which suits sudden and unpredictable workloads.

• CSwitch the cluster's storage configuration to Aurora I/O-Optimized

  Incorrect

  I/O-Optimized changes how I/O is billed for I/O-intensive clusters. It does not change the writer's compute capacity.

• DPut an Amazon RDS Proxy in front of the cluster

  Incorrect

  RDS Proxy pools database connections. It does not add compute capacity to the writer.

A provisioned cluster scales by adding whole DB instances; Aurora serverless (Aurora Serverless v2 in the exam guide) grows and shrinks one instance in fine steps within the ACU range you set.