Configure a scheduled scaling action for the EC2 Auto Scaling group that runs just before the monthly jobs is correct because the reconciliation workload is predictable and capacity must be ready before 07:30 UTC to avoid CPU saturation and application slowdowns.

The monthly surge occurs at a known time so proactive scaling launches and warms instances before the spike begins and ensures the load balancer can route traffic to healthy instances. Scheduled scaling avoids the delay inherent in reactive metrics and instance warm up and it prevents users from experiencing degraded performance while new instances start.

Enable predictive scaling for the EC2 Auto Scaling group is not the best choice because predictive scaling expects recurring patterns like daily or weekly seasonality and it may not guarantee instances are available at the exact monthly time.

Configure Amazon ElastiCache to offload read queries from the application does not address a compute bound reconciliation job because caching cannot reduce the CPU consumed by heavy processing on the instances.

Create a simple scaling policy that scales on average CPU utilization is reactive so it waits until CPU rises before adding capacity and users will see performance degradation while instances are launched and warmed.

Full AWS Practitioner Certification Question