Hard Difficulty Questions

Reboot the instance.

Why wrong: Rebooting the instance performs a soft reset of the guest operating system but does not migrate the workload to a different physical host. If the underlying host has degraded hardware or lost network connectivity, the system status check will continue to fail after a reboot because the instance remains on the same problematic host. Reboot is appropriate for addressing OS-level hangs or software hangs, not for resolving AWS-detected infrastructure faults.

Restore the instance from the latest AMI.

Why wrong: Restoring from the latest AMI is a disaster-recovery action that replaces the entire instance with a fresh one built from a saved image, which is excessive and destructive for a running-instance hardware failure. It would lose all data on instance store volumes and any changes made after the snapshot, and it does not directly address the underlying host fault that is already in progress. This action should be reserved for scenarios like corruption or accidental deletion, not for troubleshooting a single degraded host.

Check the security group rules for the EC2 instance

Why wrong: Security groups control traffic but are not the first step for connectivity issues across Direct Connect.

Confirm that the Direct Connect virtual interface is associated with the correct VLAN

Why wrong: The virtual interface is up, so VLAN association is likely correct.

Verify the network ACL inbound and outbound rules for the VPC subnet

Why wrong: Network ACLs can affect traffic but routing is the more likely issue.

The targets are unhealthy; decrease the desired capacity to reduce load.

Why wrong: Unhealthy targets would typically be indicated by elevated HTTP 5xx responses or health check failures, not by a high SurgeQueueLength. Decreasing the desired capacity would reduce the number of available targets further, causing even more requests to queue and increasing the backlog rather than alleviating it.

The load balancer is accepting too many connections; increase the idle timeout.

Why wrong: The idle timeout setting controls how long a connection can remain open with no activity before the load balancer closes it; it does not affect how quickly requests are dequeued and forwarded to targets. Increasing the idle timeout would merely hold connections open longer, doing nothing to reduce the queue of pending requests that are waiting for an available target.

The load balancer is overloaded; replace it with a Network Load Balancer.

Why wrong: Replacing the Application Load Balancer with a Network Load Balancer would not solve a capacity problem at the target level, because an NLB operates at Layer 4 and simply forwards traffic without HTTP-aware load balancing. The bottleneck is the targets' inability to keep pace with the incoming request rate, so the load balancer type is irrelevant; you need more target capacity, not a different balancer.

Create a lifecycle policy to transition objects to S3 Glacier.

Why wrong: Transitioning objects to S3 Glacier changes only the storage class for cost savings; it does not establish any deletion safeguards, and the objects remain fully prunable via normal DELETE calls. In fact, if a lifecycle policy also includes an expiration action, objects moved to Glacier can be permanently removed automatically, creating a new accidental deletion risk. Thus, while Glacier is useful for archival, it contributes nothing to protecting against loss due to accidental user actions.

Enable server-side encryption on the bucket.

Why wrong: SSE encrypts objects at rest using keys managed by AWS or the customer, defending data confidentiality but leaving the object's lifecycle and deletion semantics completely unchanged. An accidental or malicious DELETE request will still immediately remove the encrypted object, and no encryption technique can compute or restore a deleted version. Therefore, enabling encryption is a security measure, not a data preservation measure, and cannot mitigate the risk of accidental destruction.

Use Amazon Route 53 with weighted routing to distribute traffic between the two regions. Use a global DynamoDB table for session data, and launch EC2 instances in the DR region only when a failure is detected using AWS CloudFormation StackSets.

Why wrong: Weighted routing in Route 53 distributes traffic based on weights and does not perform automatic health-based failover; when the primary region fails, you would need to manually adjust weights or DNS records to redirect traffic, which extends recovery time. Additionally, a global DynamoDB table replicates NoSQL data, but this application's session state resides in ElastiCache Redis, and DynamoDB does not provide the required Redis data replication, so session data would not be available in the DR region. Finally, using CloudFormation StackSets to launch EC2 instances only after a failure is detected introduces significant provisioning and instance boot time, which would almost certainly violate the 1-hour RTO because no pre-warmed capacity exists in the DR region.

Use an Amazon CloudFront distribution with multiple origins (primary and DR). Enable session stickiness at the CloudFront level. Use EC2 instances in both regions behind separate ALBs. No special data replication is needed because sessions are stored in Redis.

Why wrong: CloudFront does not provide cross-region failover for origins in the way Route 53 does. Session stickiness is not sufficient for DR because Redis data is not replicated across regions, so users would lose sessions after failover. RPO would be effectively longer than 15 minutes without replication.

Use EC2 instances with an Auto Scaling group in both regions. Schedule a Lambda function to take snapshots of the Redis cluster every 15 minutes and copy them to the DR region. Use Route 53 latency routing to direct users to the nearest region.

Why wrong: Snapshot-based replication every 15 minutes could meet the RPO, but copying snapshots and restoring them during a disaster would take more than 1 hour, exceeding the RTO. Latency routing does not provide automatic failover in a regional outage; it routes based on latency, which could still send traffic to the failed region.

Create a customer-managed KMS key to encrypt the digest files.

Why wrong: Creating a customer-managed KMS key for encryption is an optional security enhancement, not a prerequisite for log file integrity validation. The integrity validation mechanism uses SHA-256 hashing of log files and a signed digest file, which does not require any form of encryption to function. CloudTrail can encrypt logs and digests using SSE-S3 automatically, or you may add KMS encryption later without affecting the integrity validation chain.

Configure CloudTrail to deliver logs to CloudWatch Logs for real-time analysis.

Why wrong: Delivery to CloudWatch Logs provides real-time monitoring and alerting for CloudTrail events, but it is entirely orthogonal to log file integrity validation. The digest files that enable integrity validation are generated and stored in the S3 bucket, independent of any CloudWatch Logs log group. CloudWatch Logs integration does not produce, store, or validate digest files, so it is not one of the required steps for enabling integrity validation.

Create manual snapshots of the DB instance every hour and copy them to another AWS Region.

Why wrong: Manual snapshots are taken at intervals; copying to another Region adds delay. This approach cannot guarantee an RPO of 1 hour because the snapshot schedule may miss the window, and recovery requires creating a new instance from the snapshot which can take longer than 2 hours.

Enable automated backups with a retention period of 35 days and restore to a different Region when needed.

Why wrong: Automated backups are stored only in the same Region. You would need to copy them manually, and the RPO is at least the backup window (usually 24 hours for automated backups), exceeding the 1-hour RPO.

Use AWS Database Migration Service (DMS) to continuously replicate data to a DB instance in another Region.

Why wrong: AWS Database Migration Service (DMS) is not suitable for achieving the specified 2-hour RTO and 1-hour RPO for a critical database workload recovering from a regional outage. DMS introduces replication latency and requires significant manual intervention for failover, making it challenging to meet such strict recovery objectives reliably. This option is tempting as it offers continuous cross-Region data replication. However, DMS is primarily designed for database migrations, including heterogeneous ones, or for creating read replicas where the recovery time and point objectives are less stringent, offering flexibility across database engines.

Create an IAM policy that denies Amazon EC2 actions and attach it to all users and roles in non-production accounts.

Why wrong: While this could work, it requires deploying the policy in each account individually and attaching it to all principals, which is not centrally managed. It is also easy to miss new users. SCPs provide a centralized, organization-wide control.

Use AWS Config to create a rule that detects EC2 usage in non-production accounts and automatically terminates instances.

Why wrong: AWS Config is a detective service that evaluates resource configurations after they have been created. A Config rule can detect non-compliant EC2 usage and trigger a remediation action to terminate instances, but this happens after the resource exists, leaving a window where compute resources are already provisioned and incurring cost. It also requires per-account setup of rules unless you use aggregation, and it does not prevent any principal—including the root user—from launching EC2 instances in the first place. Therefore, it is reactive and not an effective preventive control like a service control policy.

Create a resource-based policy on each EC2 instance that denies access from non-production accounts.

Why wrong: EC2 instances do not support resource-based policies; these are only available for services like S3, SNS, SQS, and KMS that have a resource model allowing inline access policies. Even if an EC2 instance could have a resource policy, it would be evaluated only when a request is made to that specific instance, so it cannot block RunInstances requests or prevent new instances from being launched. Managing per-instance policies across many non-production accounts is also operationally unscalable and completely bypassed by IAM users, roles, or the root user that has permissions to modify or delete the policy. Thus, this approach is neither technically valid nor centrally controlled.

The target instance is taking too long to respond (e.g., more than the idle timeout).

Why wrong: Incorrect. If the target takes longer than the idle timeout to respond, the ALB returns a 504 Gateway Timeout, not a 502 Bad Gateway. A 502 results from an invalid or incomplete response, not timeout.

The target instance is configured to respond to a different URL path.

Why wrong: Incorrect. If the target is configured to respond to a different URL path, it may return a 404 Not Found or other error, but that is a valid HTTP response and does not cause a 502 error.

The target group has no healthy instances.

Why wrong: When every target in the target group fails health checks or no targets are registered, the ALB has no valid upstream to receive the request. Instead of waiting or queueing, the ALB immediately returns a 502 Bad Gateway to the client because the target group is capacity-constrained. This failure occurs at the fleet level, independent of the request path or HTTP method, and is indicative of a registration or health-monitoring problem rather than an application or network security issue.

The container image is corrupted.

Why wrong: Container image corruption is an unlikely cause because ECR stores images with a content-addressable digest and verifies integrity during pull; a corrupted image would raise a manifest or checksum mismatch error, not a network failure. The error message described in the scenario points to a connectivity issue (such as a timeout), not a data corruption issue. Since the image is present in ECR and permissions are confirmed, corruption does not explain the pull failure.

The ECR repository policy is not allowing the task role.

Why wrong: If the ECR repository policy did not allow the task role, the pull attempt would fail with an AccessDenied or Unauthorized error from the ECR API. The team explicitly verified task role permissions, so authentication and authorization are not the issue. Additionally, the error pattern typical of this scenario—like a connection timeout or 'no route to host'—indicates the task cannot reach ECR at the network level, not that it was denied access.

The ECS task definition has an incorrect memory allocation.

Why wrong: An incorrect memory allocation in the ECS task definition would only affect the container's runtime resource limits; the image pull occurs before the container is instantiated and is performed by the Fargate infrastructure, independent of the task's configured memory. If memory were too low, the container might be killed or fail to start after being pulled, but the error would be an OOM or a resource-limitation error, not an image-pull failure. Therefore, memory allocation is unrelated to the described symptom.

Amazon GuardDuty

Why wrong: GuardDuty is a threat detection service, not a logging service.

AWS Config

Why wrong: Config tracks resource configuration changes, not API calls.

VPC Flow Logs

Why wrong: Flow Logs capture IP traffic, not API calls.

Enable deletion protection on the RDS instance to prevent CloudFormation from deleting it

Why wrong: RDS deletion protection prevents accidental deletion through the API or console, and also causes CloudFormation delete-stack to fail for that resource. However, deletion protection does not prevent CloudFormation from replacing the instance (replacing creates a new instance and deletes the old one). A stack policy must be used to block the Replace action.

Use CloudFormation change sets to preview the update and manually reject any change set that includes a replacement

Why wrong: Change sets allow previewing before executing, which is good practice. However, if the operator forgets to review or a CI/CD pipeline applies the change set automatically, the replacement can still occur. A stack policy enforces the protection automatically without relying on human review.

Add a DeletionPolicy: Retain attribute to the RDS resource in the template

Why wrong: DeletionPolicy: Retain prevents CloudFormation from deleting the physical resource when the logical resource is removed from the stack or the stack is deleted. It does not prevent CloudFormation from replacing the resource due to a property change during a stack update — that is controlled by the UpdateReplacePolicy attribute (also Retain) and the stack policy.

Use AWS Systems Manager Automation to run a PowerShell script on an existing EC2 instance, then manually create an AMI each week.

Why wrong: Systems Manager Automation can certainly run PowerShell scripts via an SSM runbook, but the described workflow still inserts a manual step to create the AMI from the instance. While you could build a custom automation runbook to create an AMI, this solution neither natively orchestrates the full image build/test/distribute cycle nor offers a managed schedule without extra configuration. The manual touch weekly raises the risk of human error, configuration drift, and missed maintenance — problems Image Builder is designed to eliminate.

Use AWS CodePipeline with CodeBuild to run the PowerShell scripts and create an AMI using the AWS CLI, triggered by a weekly CloudWatch Events schedule.

Why wrong: CodeBuild is primarily designed for compiling code and building software artefacts in a containerised environment, not for provisioning and configuring an EC2 instance to create an AMI. While it can run AWS CLI commands, it lacks the native, managed workflow for instance-based software installation and AMI creation, which would increase operational overhead. CodePipeline with CodeBuild is excellent for CI/CD, such as building Docker images or deploying applications, and would be suitable if the goal was to build a software package for deployment rather than an immutable AMI.

Use Amazon EC2 Auto Scaling with a lifecycle hook to run the PowerShell script on instance launch, and schedule a weekly instance refresh.

Why wrong: Auto Scaling lifecycle hooks only let you run code during instance launch or termination; they do not generate a reusable AMI. Every scale-out event would reinstall software at boot, which increases launch time and makes instances mutable rather than using a pre-baked golden image. A weekly instance refresh can replace instances, but it is a deployment mechanism for already-built AMIs, not an image factory — it adds operational friction without ever producing an artifact you can reuse in other environments or accounts.

AWS CloudTrail with a metric filter and Amazon CloudWatch alarm to trigger a Lambda function.

Why wrong: CloudTrail logs API calls but does not evaluate the current state of resources. A metric filter could detect PutBucketEncryption events, but it would not catch buckets that were already non-compliant before the rule was set up. This approach is event-driven and not state-based, and it cannot cover existing buckets across all accounts easily.

AWS Trusted Advisor to check S3 bucket encryption and send notifications.

Why wrong: AWS Trusted Advisor offers a security check for S3 bucket encryption under its 'S3 Bucket Server-Side Encryption Enabled' category, but it is fundamentally a read-only assessment tool. It can notify you via weekly email reports or CloudWatch alarms, yet it provides no mechanism to modify the bucket configuration or automatically apply encryption. Moreover, Trusted Advisor checks are not natively aggregated across all accounts in an AWS Organization; you would need to separately access or collect results per account, and it does not support compliance-based remediation workflows the way AWS Config does.

Amazon Macie to discover sensitive data and then manually encrypt buckets.

Why wrong: Amazon Macie is designed for data security and data privacy, using machine learning to discover sensitive data such as PII, credentials, or proprietary information in S3 buckets. It does not evaluate or enforce bucket-level encryption settings; a bucket with sensitive content but no default encryption would not be flagged by Macie for encryption non-compliance. Manual encryption of buckets after Macie discovery is a potential operational step, but it is not automated, does not scale across multiple accounts, and leaves the core requirement of continuous, state-based compliance enforcement unmet.

Create an EFS file system with the One Zone storage class and mount it from all instances.

Why wrong: The One Zone storage class places file data in a single Availability Zone only, so if that AZ suffers an outage, the EFS file system becomes completely unavailable. This directly violates the requirement to remain available during an AZ failure, and it also risks permanent data loss if the AZ is destroyed. One Zone is intended for non-critical, reproducible workloads, not for critical applications requiring high availability.

Create an EFS file system with the Standard storage class, enable replication to another Region, and use DNS failover.

Why wrong: While enabling cross-Region replication provides disaster recovery across Regions, the stated requirement is to tolerate an Availability Zone failure within the same Region. A cross-Region replica would require DNS failover to a different Region, introducing significant cross-Region latency and a slower recovery time. It also adds unnecessary cost and complexity when the Standard storage class is already designed to replicate data across multiple AZs in the same Region.

Create an EFS file system with the Standard storage class, and enable Multi-AZ deployment.

Why wrong: Amazon EFS does not expose a configurable 'Multi-AZ deployment' option; instead, the Standard storage class inherently provides multi-AZ data replication across all Availability Zones in the Region. Enabling a non-existent setting is not possible and the premise is misleading. Any attempt to configure such an option would either fail or be redundant, providing no additional resilience beyond what Standard already delivers.

The VPC peering connection is not properly configured for TCP traffic

Why wrong: A VPC peering connection operates at the network layer and does not inspect or filter traffic by protocol; it simply provides connectivity between the two VPCs. If the peering connection were improperly configured, all IP traffic—including ICMP and TCP—would be affected, not just TCP on port 443. The fact that ICMP succeeds indicates the peering link itself is functional, and any TCP-only failure must be caused by a layer above the peering connection, such as routing, security groups, or NACLs.

The route tables in the VPCs do not contain a route for the other VPC's CIDR

Why wrong: Route tables in a VPC are protocol-agnostic—they direct packets based on destination CIDR, not on whether the payload is ICMP, TCP, or UDP. If the route tables in either VPC lacked the route for the other VPC's CIDR, the ICMP echo request or reply would also be dropped, since routing is required for all packet types. Because ICMP traffic is reaching the instance successfully, the route tables must contain the necessary peering routes for both directions. Therefore, missing routes cannot be the cause of a TCP-only connectivity problem.

The security group on the EC2 instance is blocking inbound TCP traffic on port 443

Why wrong: The question explicitly states that the security groups are configured to allow all inbound and outbound traffic, so a security group rule cannot be blocking inbound TCP on port 443. Even if the security group were more restrictive, security groups are stateful—return traffic for an allowed outbound connection is automatically permitted without an explicit inbound rule. Since the issue is specifically with return traffic on ephemeral ports, a stateful security group would not drop those packets, whereas a stateless NACL would. This option contradicts the given facts and the observed symptom.

Use Amazon RDS Performance Insights to analyze database load and set CloudWatch alarms on the DBLoad metric with static thresholds.

Why wrong: Amazon RDS Performance Insights is a diagnostic tool that visualizes database load in average active sessions (DBLoad), helping you spot bottlenecks after they occur. However, it does not perform automated baseline anomaly detection; you would need to pair it with CloudWatch alarms using static thresholds, which require manual tuning to known normal values and do not adapt to seasonal patterns or gradual workload changes. Performance Insights also has no built-in alerting, so it fails to meet the requirement for automatic notification when behavior deviates from an evolving baseline.

Enable Amazon CloudWatch Metrics Explorer to create a dashboard that visualizes the metrics and manually review for anomalies.

Why wrong: Amazon CloudWatch Metrics Explorer is a visualization feature that lets you query and graph multiple metrics interactively to explore trends and correlations across your resources. It does not provide any automated anomaly detection, baseline computation, or alerting mechanism; detecting an anomaly would require a human to watch the dashboard and manually spot deviations from expected patterns. Since the requirement explicitly calls for setting an alarm to notify on anomalies, this option lacks the necessary automated monitoring and proactive notification behavior.

Use AWS X-Ray to trace database queries and set alarms on trace segment durations.

Why wrong: AWS X-Ray is a distributed tracing service that samples and tracks requests as they flow through application components, producing trace segments and service maps to help debug latency and errors. It operates at the request/segment level, not on Amazon RDS instance-level telemetry such as connection counts, read latency, or write latency, so it cannot analyze or alarm on these metric anomalies. Even if you could trace database queries, X-Ray does not provide anomaly detection on metric time series, making it irrelevant to this monitoring scenario.

Attach an Elastic IP to the NAT gateway

Why wrong: An Elastic IP is a mandatory parameter at NAT gateway creation time; if the NAT gateway exists, it already has one attached to its public-facing interface, so attaching another is impossible and unnecessary. The EIP facilitates address translation for internet-bound traffic, but it does not affect routing from the public subnet to the internet gateway. The observed failure is a missing route from the public subnet to the IGW, not a missing EIP.

Enable DNS resolution in the VPC

Why wrong: Enabling DNS resolution (the enableDnsSupport attribute) only tells instances to use the VPC's Route 53 Resolver for DNS queries; it has no bearing on IP routing or connectivity to the NAT gateway. Even if DNS resolution were disabled, instances could still reach the internet by IP address, and the NAT gateway would still attempt to forward traffic. The actual issue is that the public subnet lacks a default route to the internet gateway, which prevents the NAT gateway from completing outbound communication, regardless of DNS settings.

Modify the network ACL of the private subnet to allow inbound ephemeral ports from the NAT gateway's private IP

Why wrong: Network ACLs are stateless and default to allowing all inbound and outbound traffic; unless someone added explicit deny rules for ephemeral ports, they are not the source of the problem. Even if the private subnet NACL were too restrictive, it would only affect traffic between the private instances and the NAT gateway's private IP, not the NAT gateway's ability to reach the IGW from the public subnet. The failure occurs in the public subnet's route table, so modifying the private subnet NACL is both unnecessary and ineffective.

Check CloudWatch RDS CPUUtilization and CloudTrail logs for RDS API calls.

Why wrong: CPUUtilization is not directly related to connection limits; CloudTrail logs API calls, not connection errors.

Review RDS error logs in CloudWatch Logs and check the EC2 instance's system log.

Why wrong: RDS error logs may show connection errors, but system logs are not helpful; VPC Flow Logs are needed for network issues.

Look at the EC2 instance's CloudWatch NetworkIn and NetworkOut metrics and RDS FreeableMemory metric.

Why wrong: Network metrics do not show connection refusals; FreeableMemory is not directly related to connection limits.

Configure the EFS file system for One Zone storage class and mount it using the file system ID.

Why wrong: The One Zone storage class stores EFS data redundantly only within a single Availability Zone, so an AZ outage causes both data loss and complete file system unavailability. Mounting via the file system ID still resolves to the same single-AZ mount target, offering no cross-AZ failover. A critical application requires the Standard storage class, which replicates across multiple AZs, to withstand AZ failures.

Configure EFS to use provisioned throughput and mount it using a mount target IP address.

Why wrong: Provisioned throughput adjusts the file system's throughput capacity independent of storage size, but it does not influence data durability or availability across zones. Using a mount target IP address bypasses DNS-based failover and pins the client to a mount target in a single AZ, so an outage in that AZ breaks connectivity. For resilience, you must rely on the regional DNS name to reach mount targets in other AZs, not a static IP.

Enable EFS lifecycle management to move files to Infrequent Access storage class.

Why wrong: Lifecycle management migrates files to the EFS Infrequent Access (IA) storage class based on a configured age threshold, lowering storage costs for cold data. It does not alter the underlying storage class redundancy: files remain on the same file system, and IA data in the Standard file system is still replicated across AZs, but for One Zone it remains single-AZ. Thus, lifecycle management is purely a cost optimization and has no effect on the file system's resilience to an AZ outage.