Determine a strategy to improve reliability

Ingleby Ticketing runs a web application in a VPC with public and private subnets in two Availability Zones. An internet-facing Application Load Balancer sends traffic to an Auto Scaling group of EC2 instances in both private subnets, and the ALB uses sticky sessions because user sessions are stored on each instance's local disk. Both private subnets route outbound traffic through one NAT gateway in AZ-a. The database is a Single-AZ Amazon RDS for MySQL instance in AZ-a.

Which three changes remove single points of failure? Each correct answer presents part of the solution.

1. ACreate a NAT gateway in each Availability Zone and update each private subnet's route table to use the NAT gateway in its own zone.A NAT gateway is zonal, so one gateway in AZ-a cuts off outbound traffic for both zones if AZ-a fails; one per zone removes that dependency.
2. BConvert the RDS instance to a Multi-AZ deployment.Multi-AZ keeps a synchronous standby in another zone and fails over automatically, so the database no longer depends on one zone or one host.
3. CStore session state in Amazon ElastiCache or Amazon DynamoDB and turn off sticky sessions.Externalizing sessions lets any instance serve any user, so losing an instance or a zone does not log users out.
4. DCreate an RDS read replica in AZ-a to take over if the primary fails.A replica in the same zone shares the zone failure, and promotion is a manual step that also breaks replication, so it is not an automatic failover solution.
5. EDeploy a second ALB and use Route 53 weighted records to split traffic between the two load balancers.An ALB is already a managed, multi-AZ service with nodes in each enabled zone, so a second ALB adds cost without removing a real single point of failure.

Pickering Clinics runs an Amazon RDS for PostgreSQL DB instance with a Multi-AZ deployment that has one standby. A developer configured the monthly reporting tool to connect to the standby to avoid loading the primary, but the connection fails. The company wants to keep automatic failover and move reporting reads off the primary.

What should the solutions architect recommend?

1. APoint the reporting tool at the standby instance's private IP address instead of its DNS name.In a Multi-AZ DB instance deployment the standby does not accept connections at all, regardless of how it is addressed.
2. BKeep the Multi-AZ deployment and create a read replica, then point the reporting tool at the read replica's endpoint.The Multi-AZ standby exists only for failover, while a read replica uses asynchronous replication to serve read traffic through its own endpoint.
3. CTurn off Multi-AZ and create a read replica in another Availability Zone instead.A read replica does not provide automatic failover, so removing Multi-AZ gives up the availability the company wants to keep.
4. DScale the primary instance to a larger class so it can absorb the reporting load.A larger instance may help but does not move reads off the primary, which is the stated goal.

Thornbury Engineering runs a legacy license server on a single EC2 instance in AZ-a. The vendor license allows only one running copy, and the server keeps its license database on an attached EBS volume. Last month an underlying host failure took the server offline for three hours until an engineer rebuilt it. The company wants the server to recover automatically from both instance failure and the loss of an Availability Zone, while never running more than one copy.

Which solution meets these requirements?

1. ACreate a CloudWatch alarm on the StatusCheckFailed_System metric with the EC2 recover action.Instance recovery moves the instance to new hardware in the same Availability Zone only, so it does not handle the loss of AZ-a.
2. BRun a second instance in AZ-b as a hot standby with a copy of the license database.Two running copies violate the vendor license.
3. CMove the license database to Amazon EFS, and run the server from a launch template in an Auto Scaling group with minimum, maximum and desired capacity of 1 across subnets in two Availability Zones, registered behind a Network Load Balancer.EFS stores data across multiple zones, the Auto Scaling group replaces a failed instance in any healthy zone while keeping exactly one copy, and the NLB gives clients a stable endpoint.
4. DTake hourly EBS snapshots with Amazon Data Lifecycle Manager so an engineer can rebuild faster.Snapshots improve the restore point but still require a person to rebuild the server, so recovery is not automatic.

Merrow Learning runs its student portal on an EC2 Auto Scaling group with a target tracking policy at 50% CPU. Traffic rises sharply every weekday between 07:45 and 08:15, and new instances need about 6 minutes to boot and warm up, so early users see slow pages each morning. Usage has grown about 4% month over month for the last year, and the team does not want to keep editing schedules by hand as it grows.

Which change should the solutions architect recommend?

1. AAdd a scheduled action that raises the minimum capacity at 07:30 every weekday.A fixed schedule must be retuned by hand as traffic grows, which is the effort the team wants to avoid.
2. BAdd a predictive scaling policy in forecast and scale mode, with a pre-launch buffer that covers the warm-up time, alongside the existing target tracking policy.Predictive scaling learns daily and weekly patterns from history, launches capacity ahead of the forecast peak, and adapts as the trend grows, while target tracking still handles unexpected changes.
3. CLower the target tracking value to 30% CPU.A lower target only reacts sooner after load arrives and keeps more idle capacity all day, so the boot delay still hurts the first users.
4. DSet the minimum capacity to the morning peak level all day.This removes the latency problem at the cost of paying for peak capacity around the clock, and the peak level must still be raised as usage grows.