AWS Certified SysOps Administrator Associate SOA-C02 (SOA-C02) — Questions 751–825

Sticky sessions on an NLB are implemented through flow-based routing, also known as client IP affinity, which uses a consistent hash of the connection's protocol, source IP, source port, destination IP, and destination port to route all flows from a client to the same target. Unlike ALBs, NLBs cannot rely on cookie-based stickiness because they operate at Layer 4, so this affinity mechanism is the correct way to ensure a stateful web application's user requests consistently hit the same EC2 instance, preserving session state.

Amazon Route 53 is the highly available and scalable Domain Name System (DNS) web service in AWS, designed specifically for domain registration, health checking, and authoritative DNS record management. It supports A, AAAA, CNAME, MX, and AWS-specific ALIAS records, and offers distinct routing policies such as latency-based, geolocation, weighted, and failover routing. With its global network of DNS servers, Route 53 can answer queries to route users to the appropriate application endpoints, fulfilling the exact need of a SysOps administrator who must route traffic for a domain.

Configuring the Auto Scaling group to use EC2 status checks for health checks is the correct native mechanism because Auto Scaling continuously monitors the StatusCheckFailed metrics (system status and instance status) for each instance in the group. When a status check fails, the ASG marks the instance as unhealthy, terminates it, and launches a replacement instance to maintain the desired capacity—all without custom code or manual intervention. This approach leverages Amazon's built-in health check integration and is the intended method for automatically replacing instances that have failed EC2 status checks, ensuring the web application remains available.

A Network Load Balancer (NLB) is a Layer 4 load balancer that supports Elastic IP address association per Availability Zone. Each Elastic IP assigned to an NLB subnet provides a static public IP that remains constant, giving clients a fixed address for whitelisting or legacy applications. The NLB can then forward traffic to targets such as an Application Load Balancer, EC2 instances, or other services, making it a valid way to expose a static IP.

Stack policies are JSON-based IAM-style policies attached to a CloudFormation stack that act as an explicit guard against certain update actions. By configuring a stack policy that denies the Update:Replace action for the RDS DB instance resource (using "Effect": "Deny" and "Action": ["Update:Replace"]), CloudFormation will refuse to replace the database during any stack update. This is exactly the protection the administrator needs to ensure the database is not inadvertently replaced.

An S3 bucket policy can use the s3:x-amz-server-side-encryption condition key to require that PUT requests include the x-amz-server-side-encryption header with a specific value. By denying s3:PutObject when the condition is not met, the policy blocks any upload that lacks the required encryption header. This directly enforces the requirement at the bucket level for all principals.

This is correct because CloudWatch Logs metric filters increment the target metric by the specified metric value each time a log event matches the given pattern. The pattern 'ERROR' is a simple, case-sensitive term that CloudWatch matches against the entire log event, not just the beginning, so it will catch every log line that contains the substring ERROR. Setting the metric value to 1 ensures that each matching event adds exactly 1, giving you an accurate real-time count of ERROR-level log entries.

A target tracking scaling policy is the correct approach because it lets Amazon EC2 Auto Scaling automatically adjust the desired instance count to keep average CPU utilization near a predefined target value (e.g., 50%). CloudWatch alarms monitor the metric, and the policy scale out or scale in by incrementing or decrementing capacity based on the measured deviation from the target. This automated, reactive method handles peak load efficiently and reduces instances during low traffic, directly reducing costs without manual intervention.

Creating an S3 VPC gateway endpoint gives your VPC private, routable connectivity to S3 without traversing the public internet. To actually enforce that restriction, the bucket policy must include a condition such as "aws:SourceVpce" or "aws:SourceVpc" so that only requests originating from that endpoint or VPC are allowed; otherwise, the endpoint alone does not block other network paths. This is the only option that both enables private access and explicitly limits the source network to your VPC.

This is correct because when you launch an instance in a VPC, AWS requires you to reference security groups by their group ID (e.g., sg-12345678), not by their name. In a VPC, the CLI parameter "--security-group-ids" expects the resource ID, and passing the name "default" (how it appears in the console) causes a "security group does not exist" error. The default VPC's default security group has a unique ID, and you must retrieve and use that ID to successfully launch the instance.

A CloudWatch Events rule (EventBridge) can filter Auto Scaling group state-change events, such as EC2 Instance Launch Successful and EC2 Instance Terminate Successful, which are published automatically by the ASG service. The rule targets an SNS topic, delivering near real-time notifications to subscribed endpoints like email or SMS. This is the simplest, fully managed approach because it requires no instances, scripts, or custom code, and leverages an existing, reliable event stream.

Scheduled scaling allows you to scale the Auto Scaling group based on a schedule, such as increasing capacity at 8 AM and decreasing at 8 PM. Because the traffic pattern is predictable, scheduled scaling ensures that enough instances are running during peak hours and reduces cost by terminating unnecessary instances at night. This is the most cost-effective and performance-safe approach for a stateless application with known traffic patterns.

AWS CloudTrail records every API call made on the account, including root user sign-ins and root-access-key usage, and these are delivered as event history. Amazon CloudWatch Events (now Amazon EventBridge) can monitor CloudTrail events in real time and use a rule to match a pattern such as a ConsoleLogin event with a root user identity. When matched, the rule can invoke an SNS topic to send the desired notification, making this the correct combination for real-time root activity alerts.

AWS Secrets Manager is a purpose-built service for storing and managing secrets, including database credentials, with native support for automatic rotation. It uses AWS Lambda functions to rotate credentials for supported services such as Amazon RDS, Redshift, and DocumentDB, without requiring custom code. Secrets Manager also integrates with IAM for fine-grained access control and with KMS for encryption of the secret payload at rest. This makes it the correct choice because it directly satisfies both requirements: secure storage and automated rotation.

Amazon CloudFront is a content delivery network that caches static assets such as images, CSS, and JavaScript at edge locations in AWS's global point-of-presence network. When a user requests content, CloudFront serves it from the nearest edge location instead of the origin S3 bucket, which cuts network round-trip time and reduces load on the origin. This behavior directly minimizes latency for global downloads, making it the correct choice for this scenario.

When an EC2 instance fails to respond to the ALB's health check requests — for example, because the application is overloaded, the health check path returns an error, or the instance's security group blocks the health check — the ALB marks the target unhealthy and stops sending traffic to it. If all registered instances are unhealthy, the ALB has no valid target to forward the request to and returns an HTTP 503 Service Unavailable. Since health checks are sent only at a fixed interval, a temporary application slowdown or resource exhaustion can cause intermittent failures, matching the symptom in the question.

CloudWatch agent requires 'logs:CreateLogGroup' to create the specified log group when it does not already exist. The policy in question grants only 'logs:CreateLogStream' and 'logs:PutLogEvents', but not 'logs:CreateLogGroup', so the agent cannot provision the MyAppLogGroup on startup. As a result, the agent fails to deliver any log data, making the missing CreateLogGroup permission the correct explanation for the issue.

AWS Organizations is the correct answer because it provides consolidated billing, which automatically aggregates cost and usage data from all member accounts into a single payer account. This gives you a single monthly bill, enables Cost Explorer to analyze cross-account spend, and supports central cost allocation tags. It is the foundational service that allows you to see and manage costs across the entire AWS environment from one place, making it essential for central cost management.

IAM Roles Anywhere enables on-premises applications to safely obtain temporary AWS credentials by presenting an X.509 certificate issued by a trusted certificate authority (CA). The service uses the certificate's subject and issuer information to match the workload to an IAM role, then calls AWS STS to return temporary credentials that automatically expire after a configurable duration. This approach eliminates the need for long-term access keys and is the recommended pattern for non-AWS servers or hybrid workloads. It is the only option listed that directly satisfies the company's need for temporary credentials for an on-premises application.

CloudFormation does not automatically create an intrinsic dependency between a DBInstance and a DBSubnetGroup when the DBSubnetGroup is referenced by its name string rather than through the Ref function. Since the DBSubnetGroupName property in an RDS DBInstance expects a string, passing a literal name or a parameter does not establish a resource dependency, so CloudFormation may attempt to create the DBInstance before the DBSubnetGroup exists. This results in an error such as 'The specified DB Subnet Group does not exist' or 'DBSubnetGroup not found.' Adding an explicit DependsOn attribute to the DBInstance forces CloudFormation to wait until the DBSubnetGroup has been successfully created, making the creation order deterministic and resolving the failure.

Setting the ALB health check interval to 5 seconds, timeout to 2 seconds, and unhealthy threshold to 2 is the fastest configuration AWS allows; a target that fails two consecutive checks is deregistered within roughly 10 seconds, so ECS can quickly stop the unhealthy task and start a replacement. The 2-second timeout ensures a hung or unresponsive process is detected promptly, and because the unhealthy threshold is 2, transient blips are still somewhat filtered while maintaining minimal delay.

CloudWatch alarms support a native 'Systems Manager Automation' action that directly invokes an SSM automation runbook, such as the pre-built AWS-RestartRDSInstance runbook, when the alarm enters an alarm state. This runbook encapsulates the RDS reboot API call and includes appropriate wait/verify steps, all without requiring you to write or maintain any custom code. The integration is purpose-built for metric-driven remediation and is the minimal-effort, fully managed way to automatically restart an RDS DB instance.

EC2 publishes only infrastructure metrics such as CPU, network, and disk I/O by default; memory utilization is invisible unless the CloudWatch agent publishes a custom metric. By creating a custom metric like mem_used_percent and attaching a target tracking scaling policy, the Auto Scaling group continuously adjusts capacity to keep average memory utilization at a specified target (e.g., 70%). This correlates scaling decisions with the actual memory-bound workload, preventing both wasted running instances and performance degradation from memory exhaustion.

A cross-Region read replica uses asynchronous replication from the primary RDS instance to a secondary Region, keeping the replica typically within seconds of the source. In a disaster, you can promote the replica to a standalone primary database in minutes, minimizing RPO to near zero, and then repoint Route 53 to the new region's ALB. Having a duplicate ASG and ALB pre-provisioned ensures your application layer is ready to accept traffic immediately after the DNS switch.

Amazon CloudWatch Alarm continuously monitors the StatusCheckFailed, StatusCheckFailed_System, and StatusCheckFailed_Instance metrics that EC2 automatically publishes at one-minute frequency. When one of these alarm metrics crosses a configured threshold, the alarm transitions to ALARM state and publishes a message to an Amazon SNS topic, which can be configured to send an email notification. This directly satisfies the requirement to receive an email when an EC2 instance's health changes.

Deploy is the OpsWorks lifecycle event explicitly designed for deploying applications. When you deploy, OpsWorks runs the Deploy recipes on specified instances, which typically perform tasks like pulling source code from a repository, running database migrations, and restarting application services. This is the correct event to use whenever you need to roll out a new version of an application to existing instances.

Ephemeral ports are the temporary high-numbered ports clients open for receiving responses. Because NACLs are stateless, return traffic must be explicitly allowed by an outbound rule. The rule 'Allow TCP outbound to 0.0.0.0/0 on ports 1024–65535' covers all client ephemeral port ranges and allows the web server's responses to flow back to the client.

For a gateway endpoint to carry S3 traffic from a subnet, that subnet's route table must have a route whose destination is the S3 prefix list (e.g., pl-63a5400a) and whose target is the gateway endpoint ID. The exhibit shows the endpoint is associated exclusively with rtb-11111111, whereas the subnet in question uses rtb-22222222, which has no such route. Without that route, traffic from the subnet destined to S3 follows the default route out to the internet, bypassing the endpoint entirely and therefore failing to use its private connectivity.

The 'system status check failed' event indicates that AWS has detected a problem with the physical host that cannot be resolved by the instance or the guest OS. Common causes include loss of system power, loss of network connectivity, or hardware degradation on the host. Because the instance is tied to that host, a stop and start operation forces AWS to provision the instance on a fresh, healthy host, which is the documented remediation for a failed system status check.

When CloudFront uses an ALB as a custom origin, it relies on the ALB to have healthy targets in its target groups. If the ALB's targets are unhealthy, the ALB cannot route requests and may return 503 or terminate connections, which CloudFront reports as 502 Bad Gateway. Scaling events, such as rapidly changing instance counts or insufficient capacity, can cause intermittent connection timeouts or reset errors. These conditions are the leading cause of transient 502 errors in a CloudFront-to-ALB architecture.

Increasing the minimum, maximum, and default TTL values instructs CloudFront to retain objects at edge locations for a longer period, so more requests are satisfied directly from the cache rather than going back to the origin. Longer TTLs mean that the same content remains fresh in the cache, directly increasing the cache hit ratio for popular objects. This is the appropriate way to improve cache efficiency, though you should balance longer TTLs against the need to serve updated content.

To delegate access, an IAM policy must be attached to the management account user that explicitly allows the sts:AssumeRole action against the member account role's Amazon Resource Name (ARN). When the user assumes the role, AWS STS returns temporary security credentials that are automatically scoped to the role's permissions policy. This permission is the identity-based side of the trust relationship, and it is necessary because a trust policy alone cannot grant the user the right to call the role.

Latency routing uses measurements of latency between AWS regions and the user to direct traffic to the region with the lowest latency. When health checks are attached to the ALBs, latency routing automatically avoids unhealthy endpoints by excluding them from responses.

The NAT Gateway must indeed be placed in a public subnet, meaning that the subnet's route table contains a 0.0.0.0/0 route pointing to an Internet Gateway. This placement is essential because the NAT Gateway needs its own internet reachability to forward traffic from private instances to the internet. Without this route, the NAT Gateway cannot communicate with the internet, and all outbound traffic it receives from private subnets will silently fail, making the NAT Gateway itself unreachable.

Setting the target group protocol to HTTPS forces the ALB to use TLS when forwarding requests to the instances, which requires each instance to present a valid TLS certificate for the domain, typically installed on the web server. Updating the instances' security group to allow inbound traffic only from the ALB's security group (as a source reference, not a CIDR block) ensures that only the ALB can reach the instances on the HTTPS port, providing both encryption and access control. This configuration also avoids relying on static IP addresses, as security group references automatically accommodate ALB scaling.

Using Amazon EventBridge Scheduler or the AWS Instance Scheduler solution, you can automate stopping the instance at the end of the business day and starting it again before the next workday begins. EC2 billing is per-second while the instance is in the running state, so stopping it during evenings and weekends eliminates most compute charges while retaining the EBS volumes, configuration, and data. The schedule ensures the environment is available when developers arrive and requires no manual intervention, directly matching compute spend to actual usage.

Global tables are DynamoDB's multi-Region replication feature, providing active-active copies of a table in up to six AWS Regions. When enabled, all data mutations are automatically propagated to every replica, and each replica supports both reads and writes with conflict resolution, so application traffic can be failed over to a healthy Region. This availability and automatic synchronization directly address the requirement to survive a regional outage.

Configuring the Auto Scaling group to span at least two Availability Zones distributes your stateless web application's instances across independent failure domains. If an entire AZ becomes unavailable—due to power loss, cooling failure, or networking issues—the remaining healthy AZs continue to serve traffic, and the Auto Scaling group automatically replaces failed instances in the healthy zones. This is the core mechanism for high availability, because it removes any single data-center-level dependency and lets a load balancer route only to surviving instances.

Blue/green deployment provisions a complete second environment (green) alongside the current production environment (blue), allowing you to run tests against the new version while old traffic continues to flow. Once the new environment is validated, you shift traffic at the load balancer or DNS level—either all at once or gradually—making the cutover near-instantaneous. If the new environment fails, you simply switch traffic back to the still-available blue environment, enabling instant rollback with zero downtime, which is why this is the correct choice for high-availability web applications.

The ALB idle timeout is the maximum time the load balancer waits for a response from the target after forwarding a request. If the application takes longer than this timeout to send a response, the ALB closes the connection and the client receives an error. Increasing the idle timeout gives long-running requests more time to complete, so this is the correct fix.

Amazon RDS Performance Insights is a database performance tuning and monitoring feature that gives you a visual dashboard of the database load, wait states, and top SQL statements. It helps you quickly identify bottlenecks such as CPU, memory, or lock contention and can publish metrics to Amazon CloudWatch for threshold-based alarms. This makes it a purpose-built service for monitoring the performance of an RDS instance, so it is a correct answer.

A blue/green deployment strategy is a best practice because it provisions the new application version in a separate 'green' environment alongside the existing 'blue' one, allowing traffic to be switched over only after the new version passes health checks. This minimizes downtime and gives an almost instantaneous rollback path by simply redirecting traffic back to blue if a problem is detected. In AWS, this works with CodeDeploy, Elastic Beanstalk, and ECS, though stateful workloads like databases require careful compatibility analysis between the two environments.

Custom cookbooks are Chef cookbooks (recipes, templates, and files) that you store in a repository such as S3 or Git and assign to an OpsWorks layer. OpsWorks runs these cookbooks automatically during lifecycle events (Setup, Configure, Deploy, Undeploy), so you can use a template resource inside a recipe to render configuration files consistently on every instance in the layer. This is the native, supported way to manage configuration files in OpsWorks, and it is the correct answer because it integrates with the layer lifecycle and ensures ongoing convergence.

Enable Multi-AZ on the RDS instance: Multi-AZ creates a synchronous standby replica in a different Availability Zone. When the primary DB instance fails or its Availability Zone becomes unavailable, Amazon RDS automatically flips the DNS record to the standby, providing rapid, automated failover. This directly addresses the high availability requirement for the web application's database layer by eliminating a single point of failure.

The VGW is attached to the VPC and is the entry/exit point for Direct Connect. By adding a route with the on-premises destination and the VGW as the target, traffic is forced through the Direct Connect connection.

An ElastiCache cluster, particularly using Redis, provides a dedicated in-memory data store that can serve as a centralized session repository external to the EC2 instances. Because the session state is decoupled from any individual compute resource, a replacement instance launched by Auto Scaling or a new deployment can immediately read the same session data from the cache, ensuring seamless user continuity. ElastiCache supports native TTL expiration for sessions and can be configured with Multi-AZ replication to provide high availability for the session data itself.

Configure the Auto Scaling group with a target tracking policy based on average CPU utilization, for example a 50% threshold. As CPU approaches the threshold, the ASG launches additional instances in a horizontal scale-out, distributing incoming requests across more targets and reducing CPU load per instance. You must also ensure the minimum, maximum, and desired capacity values are set high enough to absorb peak traffic. This directly eliminates the health check failures caused by CPU saturation, allowing the ALB to register healthy targets and serve requests successfully.

AWS WAF is the recommended service for blocking specific IP addresses at an Application Load Balancer. You create a web ACL, define an IP set with the offending addresses, and attach a rule that blocks requests matching that set, then associate the web ACL with the ALB. This provides layer-7 protection, allowing granular control over source IPs while leaving other traffic unaffected, and integrates with features like rate-based rules and managed rule groups.

Launching EC2 instances in at least two Availability Zones satisfies the requirement to withstand the loss of an entire AZ because the Auto Scaling group distributes instances across those zones. If one AZ fails, the load balancer routes traffic only to healthy instances in the remaining zones, ensuring continued application availability. This directly meets the stem’s constraint of surviving a full AZ outage.

Requiring SSL/TLS for all client connections to the RDS instance encrypts data during transmission, directly fulfilling PCI DSS Requirement 4.2.1, which mandates protecting cardholder data over open networks. By enforcing SSL/TLS at the database parameter group level, you prevent eavesdropping or man-in-the-middle attacks on queries and result sets. This is a foundational security control for any database that stores cardholder data.

Auto Scaling with a minimum instance count is the core corrective mechanism for this scenario: it continuously monitors instance health and replaces any failed instance by launching a new one in its place, while also maintaining the desired capacity across healthy instances. Without a minimum, a single instance failure or an Availability Zone disturbance can drop the fleet to zero and take the stateless web application offline. The auto scaling group also integrates with Elastic Load Balancing to stop sending traffic to unhealthy instances, reinforcing both self-healing and capacity preservation.

Resizing the DB instances to a smaller instance class is the correct approach because it directly reduces the per-hour compute cost that scales with instance size. By analyzing Amazon CloudWatch metrics such as CPUUtilization, FreeableMemory, and DatabaseConnections, you can confirm the current instances are over-provisioned and select a smaller class that still satisfies your workload's peak demand. This right-sizing action lowers the compute component of the RDS bill immediately without sacrificing performance.

An Amazon SNS topic is the correct notification mechanism when paired with a CloudWatch alarm. When you configure an alarm, you can set an action to publish a message to an SNS topic, which then delivers alerts through email, SMS, or other subscribed endpoints. This is the essential step that ensures administrators are actually notified when an instance fails its status checks. Without an SNS action, the alarm would only remain in the ALARM state silently.

Creating a VPC Gateway Endpoint for Amazon S3 adds a prefix list route that directs S3 traffic from private subnets directly to S3 without traversing a NAT gateway or the internet. This eliminates the per-gigabyte NAT data processing fee and internet data transfer charge while keeping traffic within the AWS network. The endpoint is horizontally scalable, highly available, and adds no hourly cost, so it has virtually no performance or operational impact.

VPC Peering is a one-to-one networking connection between two VPCs that enables direct traffic using private IPv4 or IPv6 addresses. Because the peering connection uses AWS's existing global network, traffic never traverses the public internet, and there are no additional hourly costs for the peering itself, aside from data transfer. After the peering request is accepted, you must add explicit routes in each VPC's route table pointing to the other VPC's CIDR block, and update the security group and network ACL rules to allow the traffic. For a simple two-VPC scenario in the same account and region, this is the most straightforward and cost-effective solution.

Enabling sticky sessions (session affinity) on the Application Load Balancer routes requests from a particular client to the same EC2 instance for the duration of the session. This preserves the session data as long as that instance remains healthy and within the Auto Scaling group, even while the group scales out. It is a configuration-only change to the load balancer, requiring no application code modifications, making it the correct solution.

On Amazon Linux 2, Ruby and wget are not installed by default, and the CodeDeploy agent is a Ruby application that also relies on wget to download deployment artifacts. If these dependencies are missing, the agent process either fails to start or crashes immediately, so the instance never registers with CodeDeploy and the deployment hangs at the 'Stop' or 'BeforeInstall' step. The standard installation procedure requires running `yum install -y ruby wget` before installing the agent, so an AMI that omits them will cause exactly this failure.

A load-balanced environment provisions an Elastic Load Balancer (ALB or NLB) in front of the EC2 instances running the microservices. This allows incoming traffic to be distributed across multiple instances, provides a stable endpoint for external clients, and enables services to discover each other via the load balancer DNS name. It also supports health checks, auto scaling, and rolling deployments, which are essential for production microservices.

A cross-region Read Replica for Amazon RDS for PostgreSQL uses asynchronous streaming replication, with typical lag anywhere from a few seconds to several minutes — well within the required 5-minute RPO. During a regional disaster, promoting the replica transitions it to a standalone writable instance in minutes to tens of minutes, comfortably meeting the 1-hour RTO. It is also the most cost-effective option because you pay only for a single replica instance and its storage, and you can use it for read traffic before disaster, unlike a dedicated standby.

AWS Direct Connect is the correct choice because it provides a dedicated, private, physical network connection from the on-premises data center directly to AWS, bypassing the public internet. This delivers consistent, low-latency, high-bandwidth connectivity and is ideal for hybrid workloads that require reliable, secure, and predictable network performance, meeting the organization's requirement for a dedicated connection.

CloudWatch Logs Insights queries have a maximum execution time of 60 seconds, and when a log group contains a very high volume of log events within the queried time range, the query engine may exceed that limit. A timeout causes the query to return no results, even though the data exists. This matches the symptom described in the question, making it the correct explanation.

VPC peering is the natural choice for connecting two VPCs in the same region because it creates a private, point-to-point connection using the AWS global network, with no gateways, VPNs, or physical devices. Since the CIDR blocks do not overlap, route tables are straightforward—just add routes pointing to the peering connection ID. It is highly available, incurs no per-hour fee (only data transfer costs), and is specifically designed for this exact scenario.

Placing the Auto Scaling group across multiple Availability Zones distributes the EC2 instances between isolated data centers, so the application remains available even if one entire AZ becomes unavailable. The ALB also performs cross-zone load balancing, sending traffic only to healthy instances in the remaining AZs. This configuration is primarily a high-availability measure, not a scaling action, but it underpins the group's ability to replace lost capacity without redirecting all traffic to a single location.

A CloudWatch Logs metric filter applies a pattern match to incoming log events, such as the string 'FAILED_AUTH', and increments a specified metric value (e.g., 1) for every matching event. The resulting metric is automatically published to CloudWatch, and an alarm can be configured to trigger when the count exceeds a threshold over a period, such as the sum in 5 minutes. Because this operates directly on the existing log stream, it requires no application changes and provides near-real-time monitoring.

EBS snapshots are block-level, incremental backups of your EC2 volumes, so taking them every 15 minutes captures only the changed blocks since the previous snapshot, keeping storage costs low while meeting the 15-minute RPO. Using cross-region snapshot copy asynchronously replicates those snapshots to the DR Region, ensuring you have recent recoverable point-in-time data there without needing to keep duplicate running instances. On failover, you can create new EBS volumes from the latest snapshot, attach them to pre-provisioned or restored EC2 instances, and start the application—comfortably within a 1-hour RTO because snapshot-to-volume creation is fast and the infrastructure can be pre-staged as a stopped AMI or launch template.

Rolling deployment with rollback updates an Auto Scaling group in controlled batches, replacing or re-launching a subset of instances at a time while the remaining instances continue serving traffic. Elastic Load Balancing health checks verify each batch before the next begins, and if errors exceed a threshold, CodeDeploy or a similar tool automatically redeploys the previous version to restore service. This provides both gradual exposure and a safety net, which matches the requirement of deploying a new version with rollback capability.

CloudWatch Logs Insights is the correct choice because it is a dedicated, fully managed query engine for log data stored in CloudWatch Logs. It uses a SQL-like query language (fields, filter, stats, sort, etc.) to run interactive, ad-hoc searches across one or more log groups, allowing you to discover error patterns, aggregate results, and visualize findings in the console. Unlike the other options, Logs Insights is specifically designed to answer arbitrary questions on historical log data without requiring any external pipeline.

The Auto Scaling group has reached its maximum size, which is a hard limit that prevents any scale-out activity from adding new instances. When a scale-out policy is triggered while the group is already at MaxSize, the scaling process simply skips or fails the launch because it would exceed the group's maximum capacity. This is the most direct explanation for the alarm breaching but no new instances appearing.

CloudTrail records API activity and delivers event logs to Amazon S3, where lifecycle policies retain objects for the mandated seven years. This satisfies the compliance retention constraint, since CloudTrail itself is the capture service feeding durable storage.

The managed rule `s3-bucket-server-side-encryption-enabled` continuously evaluates every S3 bucket in an AWS Region against the requirement that default encryption is enabled. When a bucket is noncompliant, automatic remediation triggers an AWS Systems Manager Automation document, typically `AWS-EnableS3BucketEncryption`, to directly apply SSE-KMS to that bucket. Because Config re-evaluates the rule periodically and whenever bucket configuration changes, this approach corrects existing noncompliant buckets on deployment and continuously handles any future drift without manual intervention.

AWS CloudTrail records API calls and delivers log files to an S3 bucket or CloudWatch Logs, but it does not send proactive notifications in real time. It is the authoritative source for who made which API calls, yet it requires a separate consumer—such as EventBridge, CloudWatch Logs, or a custom script—to parse those logs and trigger alerts. Thus CloudTrail provides the data for auditing but lacks the built-in event-matching and routing capabilities needed for immediate notification.

Spot Instances are spare EC2 capacity sold at discounts of up to 90% compared to On-Demand pricing, but AWS can reclaim them with a two-minute warning. For fault-tolerant, stateless workloads that can endure interruptions, running on Spot Instances dramatically reduces compute spend without sacrificing performance. This makes Spot a primary cost-optimization lever for interruptible workloads.

Attaching an IAM role to the EC2 instances using an instance profile is the correct, secure mechanism for granting access to S3. When a role is attached, the instance can retrieve temporary, automatically rotating credentials from the instance metadata service (IMDSv2), which are assumed via STS. This eliminates the need to distribute or manage long-term access keys, reduces the risk of credential exposure, and simplifies permission updates because changes to the role policy take effect immediately for all associated instances.

No configuration is required because AWS Lambda is a regional, highly available service that executes function code in multiple Availability Zones automatically. When an S3 event triggers a Lambda function asynchronously, the event is queued and the Lambda service manages capacity, scaling, and redundant infrastructure to ensure the invocation can be processed successfully. The function is also covered by the Lambda service SLA, and the S3 event notification mechanism is designed to be reliable within the same region. Therefore, taking no action is the correct and sufficient approach.