AWS Certified SysOps Administrator Associate SOA-C02 (SOA-C02) — Questions 1–75

When every instance in a target group fails consecutive health checks, the ALB marks them unhealthy and has no target to forward client traffic to. Instead of proxying a 5xx error from an overloaded backend, the load balancer itself responds with 503 Service Unavailable because the service is deemed unreachable. The health check interval and threshold settings determine how quickly an unhealthy target is removed from rotation, but the client sees 503 until at least one target passes.

The VPC route table must contain a route for the on-premises CIDR targeting the virtual private gateway; without it, traffic to on-premises has no path despite the Direct Connect virtual interface being up. This is the most common cause of this symptom.

Aurora Global Database is specifically designed for cross-region disaster recovery. It uses a dedicated replication channel, typically with sub-second replication lag between the primary Region and up to five secondary Regions, which gives an RPO of usually under a second. A secondary Region can be promoted to primary in about a minute, providing a low RTO. This makes Aurora Global Database the correct choice when the requirement is for rapid, cross-region failover while losing almost no committed transactions.

A lifecycle hook on the terminating state of an Auto Scaling group intercepts the EC2 instance termination process, enabling a Lambda function to capture the instance's system log (console output) and upload it to an S3 bucket before the instance is destroyed. Because the Auto Scaling group has already marked the instance unhealthy via its health checks, the group will automatically launch a replacement instance after the lifecycle action completes, ensuring fully automated recovery. The hook's timeout and the ability to call complete-lifecycle-action guarantee that the log is securely stored, and the system log provides the diagnostic evidence needed for root cause analysis.

CloudWatch shows low CPU utilization, indicating the t3.large (or current size) is over-provisioned for the actual workload. Downsizing to t3.medium, which has the same vCPU count but half the memory (4 GiB vs 8 GiB), will reduce the on-demand hourly cost while still providing adequate compute for the observed load. Before resizing, confirm memory, network throughput, and application performance remain above the 95th percentile to avoid an undersized instance.

The Auto Scaling group detects the failed status check and marks the instance as unhealthy, then terminates it and launches a new instance to maintain the desired capacity. This replacement process involves a brief period during which the new instance is initializing and passing health checks, potentially causing temporary downtime. The behavior aligns with the Auto Scaling lifecycle for handling failed instances.

While the stack is in UPDATE_ROLLBACK_IN_PROGRESS, CloudFormation is automatically reverting resources to the last known good state. Any attempt to modify the stack—whether via delete, update, or change set execution—will be rejected because the stack is in a transient state. Once the rollback reaches UPDATE_ROLLBACK_COMPLETE, the Events tab in the AWS Console or describe-stack-events will show the exact failure reason (e.g., a parameter validation error or an EC2 resource failure). This diagnostic information is essential for correcting the template and retrying the update safely.

The Deny statement uses Action 's3:*' with a condition checked via aws:SecureTransport set to false, so any S3 API request sent over HTTP instead of HTTPS is denied. In IAM policy evaluation, an explicit Deny always overrides any Allow, meaning the earlier Allow for GetObject does not help when the request is not encrypted. This is exactly why non-HTTPS access is blocked for all S3 operations.

DynamoDB global tables replicate your table automatically and asynchronously across multiple AWS Regions, typically with sub-second latency, which easily satisfies a 5-minute RPO. Because every replica accepts reads and writes, you can fail over instantly by rerouting application traffic (e.g., via Route 53 health checks) to a healthy region, meeting the 1-hour RTO without needing to restore data. Global tables also handle conflict resolution using last-writer-wins, ensuring data consistency across regions and making them the correct managed solution for regional disaster recovery.

Deploying RDS in a Multi-AZ configuration with automatic failover gives the database a synchronous standby replica in a different Availability Zone, so an AZ outage triggers a failover to the standby with minimal downtime. Enabling cross-zone load balancing on the ALB distributes incoming traffic across EC2 instances in multiple AZs, ensuring that if one AZ fails, the ALB continues to route requests to healthy instances in the remaining AZ. Together these actions provide both application-tier and database-tier high availability, which is the core requirement for running the workload across AZs and surviving an AZ failure.

Data events capture object-level API operations for S3, such as GetObject, PutObject, and DeleteObject, as well as Lambda function invocations. Unlike management events, data events are not enabled by default; you must explicitly configure the trail to include them, which is essential for auditing access to sensitive content and detecting suspicious data read/write patterns. Without this explicit enablement, the audit will miss critical resource-level activity that management events do not cover.

Scaling activity history is the authoritative log of every scaling action the Auto Scaling group attempted or skipped. It records events such as policy executions, cooldown period blocks, and failures (e.g., insufficient instance capacity or unhealthy instances). If no scaling action was logged despite high CPU, that directly reveals whether the alarm-to-policy path was broken or a cooldown suppressed the action, making it the correct first place to diagnose why the group did not scale out.

ElastiCache provides a shared, cross-AZ in-memory session store. EFS provides a shared, cross-AZ file system. The Auto Scaling group launches instances in multiple AZs, and the ALB distributes traffic. This architecture survives an AZ failure.

A public subnet's route table must contain a default route (0.0.0.0/0) that targets an Internet Gateway (IGW) for outbound and inbound internet traffic to flow. Even with a public IP and permissive security group and NACL rules, if this route is missing or points to a misconfigured target, the instance cannot send or receive packets to/from the internet. Verifying the route table is the correct next step because it directly addresses the network path after you've already confirmed the stateful and stateless filtering layers.

Performance Insights provides a real-time database load dashboard that breaks down DB load by SQL, wait events, and dimensions such as hosts and users, allowing you to pinpoint the exact statements responsible for CPU spikes. It operates with minimal overhead by sampling internal diagnostic data continuously, making it the most direct tool for identifying the SQL causing high RDS CPU usage without requiring additional logging or manual query analysis.

A target tracking scaling policy based on average CPU utilisation automatically adjusts the desired capacity of the Auto Scaling group to maintain a predefined CPU target, such as 50%. This satisfies the requirement to handle a sudden traffic spike without downtime because the policy proactively adds EC2 instances as CPU load increases, preventing performance degradation before the application becomes overwhelmed.

A change set is generated from an updated template against the current stack, providing a detailed, resource-by-resource summary of whether CloudFormation will add, modify, or replace resources. Because changing an EC2 instance type typically requires replacement, the change set would explicitly flag a "Replace" action, letting the administrator assess the impact and even cancel before executing. Only after reviewing and confirming the change set is it executed, and the execution applies the exact changes that were previewed.

The AWS Config managed rule 's3-bucket-server-side-encryption-enabled' continuously evaluates whether S3 buckets have default encryption such as SSE-S3, SSE-KMS, or DSSE-KMS configured. When a bucket is marked NON_COMPLIANT during either a configuration change or a periodic evaluation, AWS Config can invoke an AWS Systems Manager Automation document, specifically the AWS-EnableS3BucketEncryption runbook, to automatically update the bucket's encryption setting and immediately reevaluate it. This approach provides a closed-loop, automated remediation workflow that satisfies the security team's requirement without custom code or manual intervention.

DB Load by Wait Events splits database load across wait categories, exposing which resource contention spiked. It satisfies the stem's need to pinpoint the root cause of a sudden load increase rather than merely confirming that load rose.

Configuring the S3 bucket policy to grant the OAI s3:GetObject permission is the critical step that makes the origin access control effective. The policy explicitly identifies the OAI as the only principal allowed to read objects, which permits CloudFront to fetch content on behalf of viewers while denying all direct S3 access requests. This is the recommended pattern because it combines the OAI identity with the necessary authorization, ensuring that the S3 bucket remains private and only CloudFront can serve content.

UltraWarm nodes in Amazon OpenSearch Service provide a warm storage tier that is dramatically cheaper per GiB than hot storage but still fully searchable, because it uses a combination of Amazon S3 and a small caching layer. By creating an Index State Management (ISM) policy that moves indices older than 30 days to UltraWarm, the company retains the ability to query compliance-related logs without paying for high-performance EBS-backed hot nodes. This meets both the cost-reduction and the 90-day compliance/retention requirements, since the data remains accessible and the policy can later delete or transition it as needed.

This option correctly addresses the requirement by enabling TLS at both ends of the connection: the listener uses HTTPS to encrypt traffic from clients to the ALB, and the target group is configured with the HTTPS protocol so the ALB re-encrypts traffic to the instances. The instances use a self-signed certificate because the ALB does not need to validate it against a public CA; it simply establishes an encrypted channel, and you can optionally configure the ALB to verify the certificate if desired.

When CodeDeploy deploys to an Auto Scaling group, it relies on the group's health check type to determine whether each instance is healthy and to maintain the minimum healthy instance count. If the health check type is left as EC2 (the default), an instance is considered healthy solely because it is in the 'running' state — even if the deployed web application is not responding on the Elastic Load Balancer. Setting the health check to ELB forces the Auto Scaling group to use the load balancer's target health checks, which validate the actual application response. This directly affects the 'insufficient healthy instances' error, so checking and correcting this setting is the correct first step.

An Internet Gateway (IGW) is the linchpin of public internet access in a VPC; it is a horizontally scaled, redundant, and highly available target for the 0.0.0.0/0 default route placed in public subnet route tables. It performs NAT for instances that have public IP addresses, enabling bidirectional traffic with the internet, and it is also required for a NAT Gateway in a public subnet to receive and send traffic. Because it connects the VPC directly to the internet, it is essential for any design where private subnets need egress.

CloudTrail trails operate on a regional scope unless explicitly created as multi-region. When a trail is active in only one AWS Region, it records S3 data events exclusively for buckets located in that same Region; bucket-level and object-level operations in other Regions never appear in the trail's delivered log files. To capture data events for all buckets, the trail must be configured as multi-region or separate trails must be created per Region. Thus, having buckets spread across Regions while the trail is single-Region explains why only some buckets are missing logs.

Specifying subnets in at least two Availability Zones within the Auto Scaling group causes Amazon EC2 Auto Scaling to launch instances across those zones, ensuring that if one Availability Zone fails, the remaining zones continue serving traffic. The Auto Scaling group also uses health checks to detect failed instances and automatically launches replacements in the other healthy Availability Zones, maintaining capacity and availability. This is the foundational design for a fault-tolerant, stateless web tier and directly addresses the requirement to survive an Availability Zone outage.

Taking manual DB snapshots every hour creates a discrete recovery point every 60 minutes, so in the worst case you lose at most one hour of data, satisfying the stated RPO. Restoring from a manual snapshot provisions a new DB instance from that exact point; the RTO includes the time to restore the snapshot and update connection strings, which can be several minutes but is often acceptable for a recovery plan. Manual snapshots are stored in S3 and persist until you delete them, giving you a reliable backup mechanism independent of automated backup retention settings.

This is the correct setup for a VPC with public and private subnets. The public subnet route table sends all outbound traffic (0.0.0.0/0) to the internet gateway, allowing resources like a bastion host or NAT gateway to reach the internet directly. The private subnet route table sends all outbound traffic to the NAT gateway, which resides in the public subnet and performs source network address translation (SNAT) to forward traffic to the internet while keeping instances in the private subnet unreachable from the internet. This preserves the security of private instances while still enabling them to download updates or access external services.

AWS Key Management Service (KMS) is a managed service for creating and controlling customer master keys (CMKs) that encrypt data at rest across AWS services, including Amazon RDS. When you enable encryption on an RDS instance, RDS uses a KMS CMK to encrypt the underlying EBS storage, automated backups, snapshots, and read replicas, with encryption handled transparently by the service. KMS is the only service among these options that natively integrates with RDS for at-rest encryption, making it the correct choice.

Configuring ALB health checks with a low threshold (e.g., 2 consecutive failures) and a short interval (e.g., 5 seconds) enables the load balancer to detect and deregister unhealthy instances within about 10 seconds, instead of the default ~60-90 seconds. This rapid detection prevents the ALB from continuing to route user traffic to instances whose database connections have been terminated during a failover. By quickly redirecting requests to healthy instances, the overall impact on users is minimized, and the application appears more resilient during RDS failover events.

The aws:MultiFactorAuthPresent condition key evaluates whether the principal authenticated with MFA during the current session. Attaching it with a Deny or Allow condition in IAM policies blocks non-MFA sessions from performing EC2 actions, enforcing the stated requirement.

AWS Config's 's3-bucket-public-read-prohibited' managed rule evaluates every S3 bucket against the defined parameter (blocking public read access) on a continuous basis. Because it is a managed rule, there is no custom code to write or maintain, and when coupled with automatic remediation (using an AWS Systems Manager Automation document that applies the 'block all public access' setting or removes bucket policies), noncompliant buckets are corrected within minutes. This is the only option that provides both automated detection and automated remediation using a pre-built, low-maintenance AWS service, meeting the five-minute requirement without manual intervention.

The composite alarm's rule expression 'ALARM(alarm1) OR ALARM(alarm2) OR ...' triggers when any child fires. By routing all notifications through the composite alarm's action and removing actions from the child alarms, exactly one notification is sent per incident. Child alarm states remain visible in the console for root cause analysis.

Amazon CloudWatch is the core AWS monitoring service that automatically collects and stores EC2 CPU utilization metrics at 5-minute intervals (or 1-minute with detailed monitoring) and provides dashboards, alarms, and API access to those time-series data points. It is the appropriate service for monitoring performance because it aggregates telemetry from AWS infrastructure and can extend to in-guest metrics when a signal is pushed back to it. Without CloudWatch, there would be no central repository or visualization for the CPU and memory data that the CloudWatch agent submits.

A 1-year Standard RI matches the 12-month stability horizon and delivers 30–40 percent savings versus On-Demand. All Upfront provides the deepest discount; Partial Upfront reduces the upfront cash requirement with a slightly lower overall saving. The 1-year commitment limits risk compared to a 3-year commitment for an uncertain future period.

Amazon RDS cross-Region read replicas use asynchronous replication to continuously copy data from the primary MySQL instance to a read-only instance in a second AWS Region. In a disaster, you can promote the replica to become a standalone primary, providing a low RPO and RTO without custom scripts or manual database dumps. This is the managed, native, and cost-effective mechanism for cross-Region disaster recovery of RDS.

CloudFormation natively supports sending stack lifecycle events (such as stack creation, update, and delete failures) directly to an Amazon SNS topic through the stack's notification options. When you create a stack, you can specify one or more SNS topic ARNs in the 'NotificationARNs' property, and CloudFormation publishes all stack events to those topics in real-time. For example, a 'CREATE_FAILED' or 'UPDATE_FAILED' event triggers a notification that is delivered to the SNS topic, and subscribers (such as email or Lambda) receive it immediately. This is the simplest, most direct, and most reliable way to get notified of stack failures, as it requires no additional services or custom scripting.

The health check grace period on the Auto Scaling group is too short. When a deployment launches new instances, the ASG considers an instance healthy only after the grace period expires; if the period is shorter than the time CodeDeploy needs to install the application and pass its own validation, the ASG will prematurely flag the instance as failing ELB health checks. Auto Scaling then terminates and replaces the instance mid-deployment, which CodeDeploy sees as a failed deployment ("too many individual instances"), and the cycle repeats for each new replacement. The correct fix is to increase the grace period to exceed the typical deployment duration.

Changing the launch template to t3.medium corrects the over-provisioning at the source: t3.medium provides the same 2 vCPU count but only 4 GiB of memory, halving the allocated RAM while remaining eligible for burstable CPU credits. For a workload with low average utilization and occasional spikes, t3 instances can burst using earned CPU credits, then settle back to a low baseline, making the smaller instance type adequate. This directly reduces the per-hour cost for every instance the Auto Scaling group launches, which is the most effective right-sizing action listed.

This is correct because logs are typically append-only and rarely accessed after the first 30 days, making S3 Glacier Deep Archive the lowest-cost storage class while satisfying the 3-year retention requirement. User uploads, however, are frequently accessed in the month after upload, so S3 Standard-IA after 30 days reduces cost without sacrificing retrieval performance; then transitioning to Glacier Deep Archive after 90 days aligns with the access drop-off and keeps lifecycle costs minimal.

CodeBuild is the ideal service for running automated tests in a controlled environment. It integrates natively with CodePipeline: if the CodeBuild build fails, the pipeline transitions to a failed state, stopping further execution and optionally sending notifications via Amazon SNS.

Amazon CloudWatch Alarms monitor a specified CloudWatch metric over a defined period and can trigger actions such as sending an SNS notification or performing an EC2 Auto Scaling action when a threshold is breached. To monitor RDS CPU utilization, you can create an alarm on the CPUUtilization metric with a threshold, comparison operator, and evaluation periods to alert when CPU usage exceeds a desired level. This directly fulfills the SysOps administrator's goal of being notified about CPU utilization.

A CloudWatch alarm on the StatusCheckFailed metric is the direct and accurate way to detect EC2 health issues because this metric aggregates both the system status check (for underlying hardware/network problems) and the instance status check (for OS/application-level issues). When the alarm enters ALARM state, it can trigger an SNS notification. This metric is available natively for every EC2 instance without extra configuration. Unlike event-driven logs or lifecycle hooks, it specifically measures the instance's operational health, making it the appropriate alert mechanism.

Increasing the memory allocation is the correct approach because Lambda allocates a proportional amount of virtual CPU (vCPU) based on the configured memory value, up to the maximum allowed. More memory translates to more compute power, which directly speeds up CPU-bound and memory-intensive code, thereby reducing execution duration. For example, a function with 1,769 MB receives a full vCPU, while higher values receive more, so raising memory is effectively scaling up the function's processing capacity.

Reviewing the change set in the CloudFormation console provides a human-readable summary of each resource action (add, modify, or delete) and whether a resource will be replaced. This step allows the administrator to spot potential risks like data loss from deletion or replacement before approving the change set. It is the required review step in a change management workflow, and it directly informs the decision to execute or reject the change set.

NACLs are stateless, so the outbound rule is evaluated independently of the inbound rule. Even if the inbound NACL rule allows SSH (port 22) from the client, the instance's response traffic goes to a random ephemeral port (typically 1024–65535) on the client. If the outbound NACL rule does not allow these ephemeral ports, the return packets are dropped, causing the SSH connection to hang or time out. This is the classic cause of asymmetric traffic failures when using stateless filtering.

If the Application Load Balancer is configured to forward traffic to the target group using HTTPS, the EC2 instance must have a valid SSL/TLS certificate installed to complete the TLS handshake. The instance presents this certificate to the ALB so that the session between them is encrypted, ensuring end-to-end protection from the client to the backend. Without a trusted, valid certificate matching the target's hostname, the ALB cannot establish the encrypted connection.

This is correct because the S3 bucket policy can include an explicit deny statement that applies to any principal other than the CloudFront service, effectively closing the direct access path. By using a condition such as `aws:SourceArn` or `aws:SourceAccount`, the policy can allow only CloudFront while denying all other IAM users, roles, and anonymous requests. This approach is the recommended companion to OAC because it ensures that the bucket is not publicly accessible, and any attempt to access the object via the S3 website or REST endpoint is rejected before returning content.

For VPC peering to function, each VPC's route table must contain a route to the CIDR block of the peered VPC, with the peering connection (e.g., pcx-xxxx) as the target. Without these routes, traffic destined for the other VPC is not directed to the peering connection and instead falls back to the local route, making the connection unreachable. This is the most common cause of failed peering connectivity and directly explains why the EC2 instance cannot reach the RDS database.

The script does not install PHP. The user data script likely installs and starts the Apache HTTP server, but it omits the installation of the PHP package (or the Apache PHP module). Without the PHP package, Apache cannot interpret and execute PHP files; it will either serve them as plain text or offer them for download, resulting in the PHP page not rendering correctly. The correct fix is to add a command that installs PHP, such as `yum install php` or `apt install php`, and then restart the Apache service so the module loads.

CodeDeploy's blue/green deployment on ECS creates a new 'green' task set running the proposed task definition while the existing 'blue' task set continues to serve full production traffic. This lets you run smoke tests, endpoint checks, or a Lambda-based validation hook against the green task set before shifting any traffic from the blue to the green target group using the ALB's weighted routing. Only after you explicitly confirm the new task definition works can you shift traffic (optionally incrementally), and if issues are detected, you can re-shift back to the original high-fidelity task set with minimal disruption. This pre-validation is exactly what prevents the misconfigured variable from ever affecting end users.

Creating a CloudTrail trail in the management account with organization-wide logging enabled automatically applies to every account and all regions in your AWS organization. This organization trail centralizes API activity logs into a single S3 bucket in the management account, ensuring you have a complete, consolidated audit record. It also includes new member accounts as they are added, eliminating the need to configure trails individually in each account.

The CloudWatch agent on EC2 uses the instance's IAM role to obtain temporary credentials via the instance metadata service. Without the CloudWatchAgentServerPolicy, which grants PutMetricData, the agent cannot publish custom metrics. This is the first thing to verify because it directly controls the agent's authorization to call CloudWatch.

Scheduling EBS snapshots hourly provides point-in-time recovery points no more than one hour apart, satisfying an RPO of up to one hour, and retaining 24 snapshots covers a full day of rollback options. Restoring is done by creating a new EBS volume from the desired snapshot and attaching it to the instance, which typically takes only minutes and meets the required RTO. EBS snapshots are incremental and stored in Amazon S3, making them a durable, low-cost backup mechanism.

A CloudWatch alarm evaluates the CPUUtilization metric against a 90% threshold over five consecutive one-minute periods, then publishes to an SNS topic whose email subscription delivers the notification. This is fully managed, requiring no agents or custom code, so operational overhead is lowest.

Enable RDS Performance Insights, which gives you a real-time and historical view of database load dimensioned by waits, SQL statements, and hosts. This is the correct first step because it lets you pinpoint whether the bottleneck is CPU, storage, lock waits, or an inefficient query pattern, rather than guessing. Only after identifying the specific load source should you consider changes like adding indexes, rewriting queries, or scaling the instance.

With a target tracking scaling policy, you first publish a custom metric to CloudWatch (for example, ActiveUserSessions) and then define the policy with a target value such as 1000 sessions per instance. Amazon EC2 Auto Scaling continuously computes the required capacity to keep the metric near that target, proactively adding or removing instances without static thresholds or manually tuned cooldowns. This makes it ideal for a dynamic, session-based workload where the relationship between load and capacity is stable and predictable.

TargetResponseTime is the ALB metric that tracks the time elapsed from when the load balancer receives a request to when it receives a response from a target. HealthyHostCount reports the number of healthy targets registered with the ALB. Together, a sustained increase in TargetResponseTime combined with a decreasing HealthyHostCount indicates that the application is degrading because fewer instances are available to handle traffic, making this the correct pair for a performance-based scaling alarm.

A bucket policy with an explicit Deny on s3:PutObject can inspect the s3:x-amz-server-side-encryption and s3:x-amz-server-side-encryption-aws-kms-key-id condition keys. If the request lacks the required SSE-KMS header or uses a different KMS key ID, S3 returns 403 AccessDenied before accepting the upload. This enforces encryption at write time, making it the only option that guarantees every upload is encrypted with your designated KMS key.

Amazon CloudWatch Events (now part of Amazon EventBridge) natively integrates with RDS event notifications, emitting a structured event whenever a DB instance experiences a failover. By creating a rule that matches the 'RDS DB Instance Event' source and the specific detail type for failover, you can route that event to an SNS topic in near-real time, enabling automated alerting, logging, and downstream remediation. This is the intended, low-overhead approach because RDS already publishes these lifecycle events, and no polling or custom detection logic is required.

Amazon CloudWatch Alarms monitor a CloudWatch metric, such as EC2 CPUUtilization, against a defined threshold over a specified number of consecutive evaluation periods. When the alarm transitions to ALARM, OK, or INSUFFICIENT_DATA, it can trigger actions like Auto Scaling policies or SNS notifications. This allows you to detect sustained high CPU usage and respond automatically, making it the correct choice for monitoring CPU utilization.

Spot Instances give the company the largest possible EC2 discount, up to 90% off On-Demand, and are ideal for fault-tolerant, interruptible workloads like the described batch job. Because the job uses checkpointing, it can safely stop after a two-minute Spot interruption notice and later resume from the last saved state, so cost savings are maximized without sacrificing data integrity or job completion.

This is the correct answer. The namespace is a container for metrics; if the application sends custom metrics using a different namespace than the one being viewed in the CloudWatch console (e.g., 'Custom/App' vs 'AWS/EC2'), the metrics will be stored under the namespace specified in the PutMetricData call. The console only displays metrics from the selected namespace, so a mismatched namespace makes the metrics appear 'missing.' The fix is to use a consistent namespace across the publishing and viewing steps.

This is correct because the ALB sends health check requests from its own network interfaces, using the ALB's security group as the source in the allowed inbound rule on each target. The target instance's security group must explicitly allow inbound TCP on the health check port (HTTP/80) from the ALB's security group ID (or from the VPC CIDR if the security group reference is not used). Without that rule, the OS receives the SYN packet but the security group silently drops it, so the health check times out and the target is marked unhealthy. This is the standard root cause for healthy-app-turned-unhealthy after an ALB change or when targets are in a different security group.

The AssumeRole API in AWS Security Token Service (STS) requires a RoleArn parameter, and the role ARN is the globally unique identifier that the external auditor's account must pass to request temporary credentials. The ARN encodes both the AWS account ID that owns the role and the role name, which allows STS to locate the role and apply its trust policy. Without this ARN, the auditor cannot invoke the role-assumption flow at all.

Enabling S3 Versioning preserves every version of an object, so a deletion request creates a delete marker instead of erasing the underlying data, allowing you to restore the object at any time. Adding MFA Delete requires a valid MFA code to permanently delete object versions or to suspend versioning, which prevents accidental or malicious purges even by the root user. Together, these features provide comprehensive, built-in protection against both overwrites and deletes, making them the correct choice for safeguarding critical data.

AWS Budgets is the purpose-built service for tracking spending and usage against predefined cost thresholds, allowing you to create budgets for monthly, quarterly, or annual periods. You can set multiple alerts—both for actual spend and forecasted spend—with custom thresholds and notification preferences (email, SNS) or even Lambda triggers. This directly satisfies the requirement to receive alerts when the monthly AWS spend exceeds a specific amount, making AWS Budgets the correct answer.

Amazon CloudWatch is the correct monitoring service because it publishes the SQS metric ApproximateNumberOfMessagesVisible from the queue, and you can create a CloudWatch alarm on that metric. When the alarm threshold is breached, it triggers an EC2 Auto Scaling policy that adds or removes instances based on the queue depth, directly matching the requirement to scale compute resources with message volume. CloudWatch also retains metric history for troubleshooting and can trigger multiple actions, but the core pairing here is metric-driven auto scaling.

S3 event notifications can be delivered to SQS, providing a durable buffer. Lambda polls the queue, so messages are not lost if the function is throttled or busy. SQS retains messages until processed, and Lambda event source mapping handles retries and batching. This decouples the upload rate from Lambda's invocation capacity.

The health check performed by Elastic Beanstalk is an HTTP request to the environment's health check path (typically / on port 80). If the custom AMI lacks a web server or the web server isn't configured to serve the application, the ELB health check receives a connection refused or non-2xx response, causing the instance to be marked unhealthy. Simply having a running EC2 instance is insufficient; the AMI must include the same web server and configuration as the standard Elastic Beanstalk platform AMI to serve traffic.

The immutable deployment policy launches a completely new set of instances with the new application version. Once healthy, the environment's CNAME is switched to the new instances, providing zero downtime and the ability to validate the new version before traffic is routed.

Security Groups are stateful virtual firewalls that operate at the ENI/instance level within a VPC. They evaluate all inbound and outbound traffic against a set of allow rules only—there is no explicit deny rule—and return traffic is automatically permitted regardless of the outbound rule configuration. For example, if you allow inbound HTTP from 0.0.0.0/0, the corresponding outbound response traffic is implicitly allowed, which simplifies security but requires careful rule design to avoid overly permissive configurations.

The AWS Config managed rule s3-bucket-encryption-enabled evaluates whether an S3 bucket has default encryption enabled, which is satisfied by configuring either SSE-S3 or SSE-KMS. This ensures new objects written to the bucket are automatically encrypted at rest, directly meeting the organization's encryption requirement. Without this rule, a bucket could store plaintext objects, making it the correct choice.

Enabling Multi-AZ on an RDS for MySQL instance provisions a standby replica in a separate Availability Zone and uses synchronous replication to keep it current. If the primary fails or its AZ becomes unavailable, Amazon RDS automatically flips the DNS endpoint to the standby, delivering failover in typically 60–120 seconds with no manual intervention and minimal data loss. This is the only option that provides automatic failover and meets the high availability requirement for a production database.

AWS CloudFormation is the native infrastructure-as-code service that lets you define the Lambda function, IAM role, and every related resource in a declarative JSON or YAML template. CloudFormation automatically handles resource dependencies, creation order, and rollback on failure, making it ideal for automating repeatable, consistent environments. It is the correct tool because you need to provision the resources themselves, not just deploy code to existing infrastructure.