AWS Certified SysOps Administrator - Associate (SOA-C02)

The scenario requires configuring Amazon Route 53 failover routing for two on-premises web servers (primary active, secondary passive). Failover should be triggered based on the HTTP status code returned by the primary server. Since the servers are on-premises, they have specific IP addresses. The appropriate Route 53 record type to point a domain name to an IP address is an A record (for IPv4) or an AAAA record (for IPv6). Alias records are typically used to point to AWS resources like ELBs or CloudFront distributions.

The failover logic depends on checking the health of the primary server by verifying if it returns HTTP status codes 2xx or 3xx. This necessitates configuring a Route 53 HTTP health check (or HTTPS if applicable), as TCP health checks only verify connectivity on a specific port without checking the HTTP response status. This HTTP health check must then be associated with the A record corresponding to the primary server. Route 53 will monitor the health of the primary server using this health check. If the health check passes (returns 2xx or 3xx), Route 53 directs traffic to the primary server's A record. If the health check fails, Route 53 directs traffic to the secondary server's A record, assuming the secondary record is configured as the failover target.

Therefore, the correct approach involves creating standard A records for both the primary and secondary on-premises server IP addresses and associating the Route 53 HTTP health check with the primary server's A record.

To securely grant permissions to applications running on Amazon EC2 instances, AWS recommends using IAM roles. Instead of creating and distributing AWS access keys, you can create an IAM role that has the necessary permissions and attach this role to the EC2 instance. Applications running on the instance can then retrieve temporary security credentials from the instance metadata service, eliminating the need to store long-term credentials on the instance itself. This approach significantly enhances security by avoiding the risks associated with managing static access keys, such as accidental exposure or the need for manual rotation.

This solution correctly implements this best practice by creating an IAM role associated with the EC2 instance. Furthermore, it adheres to the principle of least privilege by attaching an IAM policy that grants only the specific permissions required for the application to interact with Amazon SQS: sqs:SendMessage, sqs:ReceiveMessage, and sqs:DeleteMessage for the designated queues. Granting overly broad permissions, such as sqs:*, would violate the least privilege principle and potentially allow unintended actions. Storing IAM user credentials, either as environment variables or embedded in application configuration, is less secure than using IAM roles, as these credentials could be compromised if the instance is accessed inappropriately.

To host a static website using Amazon S3 while ensuring the bucket remains private, the recommended approach is to use Amazon CloudFront with an Origin Access Identity (OAI). An OAI is a special CloudFront user that you associate with your distribution. You then configure the S3 bucket policy to grant this OAI permission (s3:GetObject) to read the objects in your bucket. This configuration allows CloudFront to fetch the content from the private S3 bucket and serve it to users, while direct access to the S3 bucket remains restricted, thereby adhering to the policy that the bucket must not be public. Users will access the web application through the CloudFront distribution's domain name.

Configuring static website hosting directly on the S3 bucket requires making the bucket's objects public, which violates the stated security policy. While an Application Load Balancer (ALB) can route traffic, it is not designed to directly serve static content from an S3 bucket as an origin in this manner; ALBs typically forward traffic to resources like EC2 instances or Lambda functions. Similarly, AWS Global Accelerator enhances availability and performance but does not directly serve content from a private S3 bucket; it usually directs traffic to endpoints like ALBs, NLBs, or EC2 instances.

The requirement is to provide a static set of source IP addresses for outbound traffic originating from EC2 instances spread across multiple Availability Zones, likely residing in private subnets, destined for a third-party API on the public internet. The standard AWS solution for this scenario is to use NAT gateways. By placing a NAT gateway in a public subnet within each Availability Zone used by the application and configuring the route tables of the private subnets in each respective AZ to direct internet-bound traffic (0.0.0.0/0) to the NAT gateway, you achieve the desired outcome. Each NAT gateway is automatically assigned an Elastic IP address upon creation, which provides a stable, static public IP address. Instances within the private subnets will initiate outbound connections, and their traffic will be routed through the NAT gateway in their AZ. The source IP address observed by the third-party API will be the Elastic IP address of the corresponding NAT gateway. This setup ensures high availability because if one AZ fails, instances in other AZs can still route traffic through their respective NAT gateways. The list of static IPs to provide to the third party would consist of the Elastic IP addresses associated with each NAT gateway.

Associating an Elastic IP address directly with each instance is not feasible or scalable for hundreds of instances, and it doesn't address the need for instances in private subnets. Furthermore, a single Elastic IP cannot be associated with multiple instances simultaneously. Updating the main route table to route traffic through an EIP assigned to each instance is also incorrect; instances route based on their subnet's route table, and assigning EIPs to potentially private instances is generally not the intended architecture. A Network Load Balancer (NLB) is used for distributing incoming traffic to targets and does not provide outbound internet connectivity with a static source IP for the instances behind it.

To meet the requirements of automating daily incremental backups for specific EBS volumes based on tags and preventing accidental or malicious deletion, AWS Backup provides a comprehensive solution. You can create a backup plan in AWS Backup configured with a daily schedule. Within this plan, you define a resource assignment that targets resources based on specific tags, in this case, the Lifecycle: Production tag applied to EBS volumes. AWS Backup automatically handles the creation of incremental snapshots according to the schedule.

Furthermore, AWS Backup includes a feature called Backup Vault Lock. By applying Vault Lock in compliance mode to the backup vault where the snapshots (recovery points) are stored, you can make the backups immutable for their retention period. This prevents deletion of the recovery points, even by users with administrative privileges or broad permissions like ec2:*, fulfilling the requirement to protect the production snapshots from deletion.

Using Amazon Data Lifecycle Manager (DLM) could automate snapshot creation based on tags, but it doesn't offer the same robust, built-in protection against deletion as AWS Backup Vault Lock. Creating AMIs is not the specific requirement; the focus is on EBS volume backups. While using an SCP to deny ec2:DeleteSnapshot combined with an EventBridge rule for creation is a possible approach, AWS Backup offers a more integrated and purpose-built solution for managing and protecting backups, including features like Vault Lock specifically designed for immutability.

The scenario requires a shared file storage solution accessible simultaneously by multiple Windows-based application servers across different Availability Zones, replacing an existing setup on EC2 instances. Amazon FSx for Windows File Server is a fully managed file storage service built on Windows Server that provides native support for the Server Message Block (SMB) protocol, which is standard for Windows file sharing. Creating an FSx for Windows File Server Multi-AZ file system directly addresses the requirements. This service provides a highly available and durable file system that spans multiple AZs. Application servers can connect to the file share using standard Windows networking mechanisms without needing complex configurations or custom scripts. AWS manages the file server infrastructure, including patching, backups, and failover, making it the most operationally efficient solution among the choices.

Enabling EBS Multi-Attach allows attaching a single EBS volume to multiple EC2 instances within the same Availability Zone, but it requires a cluster-aware file system and does not provide a native SMB share accessible across AZs without significant additional configuration. Creating two separate FSx file systems and configuring DFS Replication adds operational complexity compared to using a native Multi-AZ FSx file system, which handles high availability automatically. Amazon EFS provides shared file storage using the NFS protocol, which is not native to Windows environments; while Windows can connect via an NFS client, FSx for Windows File Server offers a more seamless and optimized experience for Windows workloads using the native SMB protocol.

To allow EC2 instances in a private subnet to access Amazon S3 buckets within the same AWS Region privately, without traversing the internet, and without requiring modifications to the instances or applications, the appropriate solution is to use an S3 gateway endpoint. A gateway VPC endpoint provides a target for a specific route in your route table for traffic destined for supported AWS services, in this case, Amazon S3. When you create an S3 gateway endpoint and associate it with the route table used by the private subnet, traffic from the EC2 instances destined for S3 in that Region is automatically routed through the endpoint over the AWS private network. This requires no changes on the EC2 instances themselves, as the standard S3 DNS names resolve correctly within the VPC to use the endpoint path. This solution inherently prevents internet access for this traffic path and satisfies the requirement that instances should not have general internet access.

An S3 interface endpoint uses AWS PrivateLink and provides an ENI in the subnet, which might require DNS configuration or application changes unless Private DNS is enabled; however, the gateway endpoint is specifically designed for this VPC-to-S3 scenario and integrates seamlessly via route tables. A NAT gateway provides general outbound internet access, which is explicitly forbidden by the requirements. Configuring a proxy instance adds operational overhead and requires modifying the instances or applications to use the proxy, violating another requirement.

The core challenge is the need for rapid scaling in response to unpredictable traffic surges, combined with long instance startup times due to the boot process creating data caches. Auto Scaling group warm pools are specifically designed to address this scenario. A warm pool maintains a set of pre-initialized EC2 instances, which have already completed the time-consuming boot process. These instances can be kept in either a Running or Stopped state. When the Auto Scaling group needs to scale out due to a traffic surge, it can pull instances from the warm pool much faster than launching new instances from scratch. Using instances from the warm pool significantly reduces the time required to get new capacity online and handling application traffic. Configuring the warm pool to keep enough instances in the Stopped state ensures that the required capacity (up to 100 instances) can be rapidly brought into service when the unpredictable surges occur, while minimizing costs compared to keeping them running.

Predictive scaling relies on historical patterns and may not react effectively to sudden, unpredictable surges caused by external events like television advertisements whose exact timing is unknown. Increasing the instance warmup time parameter merely informs Auto Scaling about the lengthy boot process; it does not accelerate the scaling response itself. Manually starting instances and attempting to store boot data on instance store volumes is not a viable or automated solution, as instance store data is ephemeral and lost upon instance stop.

The requirement is to proactively monitor the usage of the EC2 instance service quota and receive a notification when it reaches 70%. AWS Service Quotas integrates directly with Amazon CloudWatch, allowing you to create alarms based on the utilization of your service quotas. This native integration provides the most operationally efficient solution. You can navigate to the Service Quotas console, select the relevant EC2 instance quota (e.g., 'Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances'), and create a CloudWatch alarm directly from there.

Within the alarm configuration, you can set the threshold to 70% of the quota value and specify an Amazon Simple Notification Service (Amazon SNS) topic as the action to take when the alarm state changes to ALARM. This approach avoids the need to write, deploy, and maintain custom code, leveraging built-in AWS capabilities.

Monitoring EC2 CPU utilization does not address the service quota limit directly.

While high CPU might trigger scaling attempts, the fundamental block is the instance quota, not instance performance.

Creating a custom Lambda function to periodically check the instance count against the quota value obtained via the Service Quotas API (or potentially CloudWatch metrics) and then publish to SNS is a viable but less operationally efficient approach compared to using the direct integration between Service Quotas and CloudWatch Alarms. The built-in method requires less setup and ongoing maintenance.

AWS Systems Manager Patch Manager uses patch baselines to define which patches are approved for installation on your instances and includes rules for auto-approval. Patch groups are used to associate instances with a specific patch baseline, typically using tags. Maintenance Windows define recurring schedules during which patching operations can occur.

To meet the requirements, you need different patching rules (specifically, different auto-approval delays) for development and production instances. This necessitates creating two separate patch baselines: one for development with a 2-day auto-approval delay, and another for production with a 5-day auto-approval delay. You then use tags to identify the development and production instances. These tags are used to create two corresponding patch groups (e.g., Patch Group: Development and Patch Group: Production). Each patch group is then associated with its respective patch baseline (Development patch group linked to the 2-day delay baseline, Production patch group linked to the 5-day delay baseline). Finally, a single maintenance window is required to orchestrate the patching process for all instances within the specified 2-hour timeframe. This maintenance window targets both development and production instances (identified via tags or resource groups) and registers a task (like AWS-RunPatchBaseline) to perform the patching. When the task executes, Patch Manager applies the appropriate baseline based on the patch group membership of each targeted instance.

Configuring only one patch baseline would not allow for different auto-approval delays. Auto-approval delays are properties of the patch baseline, not the patch group or maintenance window. While tags are used to identify instances, they don't directly define the patching rules. Requiring two maintenance windows contradicts the requirement for a single window.