Hard Difficulty Questions

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Configure the Auto Scaling group to launch instances across multiple Availability Zones and configure the ALB to route traffic to healthy targets.

Why it fails: Spreading instances across Availability Zones within one Region does not survive a regional outage; all zones fail together. It is tempting because multi-AZ Auto Scaling is the standard resilience pattern, and it would be correct for an Availability Zone failure rather than the regional failure described.

Increase the desired capacity of the Auto Scaling group and use larger instance types to absorb the load during failover.

Why it fails: Larger instances and higher desired capacity remain in the affected Region, so a regional outage still takes them offline; capacity does not address regional failure. It is tempting because scaling absorbs load spikes, and it would be correct for demand surges rather than infrastructure loss.

Use AWS Lambda to periodically check the health of instances and automatically relaunch failed instances in another region.

Why it fails: Lambda health checks and relaunching instances in another Region require the workload, AMI, and networking to already exist there, and polling adds detection delay; it is not automatic recovery. It is tempting because cross-Region failover is a genuine DR pattern, but it needs pre-provisioned infrastructure.

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 it fails: 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 it fails: 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 it fails: 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 manual snapshots of the DB instance every hour and copy them to another AWS Region.

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Configure multiple origins for failover.

Why it fails: Configuring multiple origins for failover creates an origin group where CloudFront automatically switches to a backup origin when the primary returns an error. This mechanism exists solely to provide high availability and resilience against origin failures; it does not cache or consolidate requests in any way. In fact, if the primary origin is down, traffic reroutes to the secondary origin, so the total request load is unchanged or even duplicated, failing to reduce the number of requests to any single origin.

Enable CloudFront Web Application Firewall (WAF) integration.

Why it fails: Enabling CloudFront WAF integration adds a set of security rules that inspect incoming HTTP(S) requests for common attack patterns, such as SQL injection or cross-site scripting, and can block them at the edge. However, WAF operates on the application layer and is not a caching mechanism; it neither stores content nor aggregates requests from different edge locations. While it can reduce some malicious traffic, legitimate user requests still pass through to the origin on cache misses, so it does not meaningfully lower the volume of requests that reach the origin.

Increase the cache TTL for CloudFront distributions.

Why it fails: Increasing the cache TTL extends the duration that CloudFront retains an object at edge locations before checking the origin for a newer version, which can improve the edge cache hit ratio and reduce origin traffic for that object. However, this only affects object freshness at the edge and does not provide a centralized aggregation layer; if multiple edges miss simultaneously, each still fetches from the origin independently. Origin Shield is a more comprehensive solution because it creates a single regional cache that all edges share, thereby reducing redundant origin fetches across the entire distribution, whereas simply raising TTL offers limited and less predictable origin offload.

Burstable Performance Instances (T3)

Why it fails: T3 instances rely on CPU credits to handle bursts of activity, but when the credit balance is exhausted, CPU performance is hard-limited to the baseline rate, which can cause severe throttling for a critical application requiring sustained CPU. Because your workload uses a fleet of instances with consistent high utilization, burstable instances will frequently run out of credits, leading to unpredictable latency and degraded throughput. This makes T3 instances unsuitable for production workloads that demand steady, dependable compute performance.

Spot Instances

Why it fails: Spot Instances offer large cost savings by letting AWS reclaim the capacity at any time with a brief two-minute warning when AWS needs it back for on-demand or reserved workloads. This interruption risk means a Spot Instance can be terminated mid-transaction, causing application crashes or data loss, which is unacceptable for a critical application. While Spot is economical for fault-tolerant or flexible workloads, it does not provide the reliability needed for a mission-critical service.

Reserved Instances

Why it fails: Reserved Instances are primarily a billing discount applied to your accounts, not a reservation of physical capacity or a guarantee of performance isolation. Your instances still share underlying hosts with other customers, so the 'noisy neighbor' effect remains possible and can degrade performance. Choosing RI will save on usage costs, but it does nothing to mitigate contention or provide the dedicated hardware that this critical workload requires.

Use AWS Transit Gateway to connect all VPCs and the Direct Connect gateway, then configure route tables to isolate traffic.

Why it fails: AWS Transit Gateway operates at Layer 3 and does not provide 802.1Q VLAN tagging or the ability to multiplex multiple private VIFs over a single Direct Connect connection. To use Transit Gateway with Direct Connect, you would instead create a single transit VIF to the Direct Connect gateway and attach the gateway to the Transit Gateway, which then requires VPC attachments and route table configuration. This approach does not satisfy the requirement of using VLAN-tagged private virtual interfaces for per-VPC isolation, and it adds unnecessary complexity while still consuming only one VIF on the connection.

Provision multiple Direct Connect connections, one for each VPC, and use a different VLAN on each connection.

Why it fails: Provisioning a separate Direct Connect connection for each VPC multiplies the cost of physical ports, cross-connects, and monthly port hours without any technical benefit, because a single connection can carry multiple private VIFs. Additionally, VLAN tagging is meaningful only when multiple VIFs share one physical connection; using a different VLAN on separate connections does not improve isolation or performance, as each connection is already independent. This over-provisioning contradicts the principle of maximizing bandwidth utilization and is unnecessary for connecting multiple VPCs.

Establish a single Direct Connect connection and use IPsec VPN tunnels over it to connect to each VPC.

Why it fails: Using IPsec VPN tunnels over a single Direct Connect connection would introduce encryption overhead, thereby reducing the effective bandwidth available and failing to maximise bandwidth utilisation as required by the scenario. This approach is typically employed when an organisation has strict compliance requirements for end-to-end encryption of all traffic, even over a dedicated private link, prioritising data confidentiality over raw throughput. It provides an additional layer of security for sensitive data in transit.

Recover the EC2 instance using EC2 instance recovery.

Why it fails: EC2 instance recovery is a special action that is only available for StatusCheckFailed_System alarms, not CPU utilization alarms. The recovery action stops and starts the instance on a new physical host to address underlying hardware issues, but CPUUtilization is a performance metric, not a status check. Furthermore, the alarm output described would need to explicitly include an 'arn:aws:automate' recover action, which is absent in this case. Therefore, this alarm cannot initiate instance recovery.

Launch a new EC2 instance in an Auto Scaling group.

Why it fails: Launching a new instance in an Auto Scaling group requires the CPU utilization alarm to be attached to a scaling policy, such as a target tracking or step scaling policy. The CloudWatch alarm itself does not directly launch instances; it only triggers the scaling policy if the alarm's AlarmActions references a policy ARN. The problem statement does not indicate any such scaling policy association, so the alarm's action is limited to its configured SNS topic, not infrastructure provisioning.

Reboot the EC2 instance.

Why it fails: Rebooting an EC2 instance is not an automatic consequence of a CPU utilization alarm unless an explicit EC2 action or a custom automation (e.g., AWS Lambda or Systems Manager) is assigned in the alarm's actions. However, the described alarm output does not show any EC2 reboot action; it only includes an SNS notification. Even if a reboot could be configured as an EC2 action on some metrics, it is not present here, and a simple CPU alarm without additional automation will never reboot the instance on its own.

Use the DependsOn attribute on the RDS instance to wait for the Auto Scaling group.

Why it fails: Placing DependsOn on the RDS instance to wait for the Auto Scaling group inverts the required dependency. CloudFormation would create the ASG first, then the database, but the ASG's instances need the database to exist and be reachable at launch. The RDS instance itself has no dependency on compute resources, so this ordering guarantees a broken application deployment.

Use the DependsOn attribute on the Auto Scaling group to wait for the RDS instance, and also use cfn-signal on the Auto Scaling group to wait for the database.

Why it fails: While the DependsOn correctly orders the ASG after the RDS instance, the use of cfn-signal on the Auto Scaling group is misplaced. cfn-signal is an agent that runs inside EC2 instances to notify CloudFormation of their own readiness; it cannot poll a separate RDS database for availability. Here, you'd be waiting for instances in the ASG to signal, not for the database, so the stack could proceed even if the database is still initializing.

Use the DeletionPolicy attribute on the Auto Scaling group to ensure it is not deleted.

Why it fails: DeletionPolicy is a stack resource attribute that governs the behavior when a stack is deleted, such as retaining or taking a snapshot of the resource. It has no influence on creation order or on waiting for dependencies. Applying it to the Auto Scaling group would only affect what happens to the ASG during stack deletion, so it does nothing to ensure the RDS instance is available first.

Use all Spot Instances with a simple scaling policy.

Why it fails: All Spot Instances are too risky for a production web application because Spot capacity can be reclaimed with only a two-minute warning when EC2 needs the capacity back. A simple scaling policy only responds to a single CloudWatch alarm with a cooldown period, so it lacks the smooth, proportional response of target tracking when a sudden spike begins. This combination cannot guarantee either availability or rapid scale during unpredictable load.

Use all On-Demand Instances with a scheduled scaling policy.

Why it fails: A scheduled scaling policy is designed for traffic that follows a known pattern, such as higher load during business hours, not for unpredictable spikes that could occur at any time. Using exclusively On-Demand instances also means paying the highest per-hour price with no discount, so you lose the cost benefit of Reserved Instances or Savings Plans. Without a dynamic scaling policy, the group would not automatically adjust to abrupt changes, leaving the application either under-provisioned or expensive.

Use only Reserved Instances with a manual scaling policy.

Why it fails: Purchasing only Reserved Instances for all workload capacity is wasteful because spikes may not occur often enough to justify the always-on, prepaid cost, and if the spike exceeds the reserved count, the excess demand cannot be met without adding capacity. Manual scaling requires an administrator to observe the load and change the desired capacity by hand, which is too slow for sudden traffic bursts and can be forgotten during off-hours. Additionally, RIs are a flexible billing discount but still lock you into a specific instance family and region, exposing you to over-provisioning or under-provisioning.

The security group on the private instances blocks outbound HTTPS traffic.

Why it fails: Security groups are stateful and allow return traffic for permitted outbound connections, so outbound HTTPS is normally permitted by default. It is tempting because security group rules are a frequent cause of connectivity failures, and would be correct if the group had been hardened to remove the default outbound allow rule.

The internet gateway is not attached to the NAT Gateway.

Why it fails: Internet gateways attach to VPCs, not to NAT gateways; NAT gateways sit in a public subnet whose route table already targets the IGW. It is tempting because the IGW is genuinely required for NAT gateway internet access, but the attachment is to the VPC, so this cannot be the described misconfiguration.

The NAT Gateway's security group is blocking inbound traffic from the private subnet.

Why it fails: NAT gateways have no security groups; they are managed appliances whose traffic filtering is handled by the subnet's network ACLs and the instances' own security groups. It is tempting because security groups commonly block traffic, but the correct check is the private subnet's NACL and the NAT gateway's public subnet route.

The SQS queue is configured to use a single AZ for message storage.

Why it fails: This option misunderstands the SQS storage model. Amazon SQS is a regional, highly available service that automatically replicates every message across multiple Availability Zones within the region; there is no configuration option to store messages in a single AZ. Therefore, the queue itself cannot be 'configured for a single AZ' and this cannot be the reason for the latency spike during the AZ outage.

The application is not configured to process messages from multiple AZs.

Why it fails: This confuses the compute layer with the queue service. SQS exposes a single regional queue URL, and SQS internally manages message distribution across Availability Zones; the application simply calls ReceiveMessage against that endpoint and does not need any AZ-specific processing logic. An EC2 instance in one AZ can receive messages that are physically stored in another AZ, so a lack of 'multi-AZ processing' in the application is not a valid explanation for the latency increase.

The Auto Scaling group's minimum size is too low to handle the load after the AZ failure.

Why it fails: The Auto Scaling group spanning three AZs already provides compute capacity, and the stated symptoms point to message retrieval latency rather than resource exhaustion. Even if the Auto Scaling group's minimum size were low, it would manifest as high CPU utilization, failed instance health checks, or an inability to add instances — not as a temporary latency spike in SQS retrieval. The scenario's bottleneck is SQS message availability during AZ recovery, not an undersized compute fleet.

Store all data in S3 Standard for the first year, then delete.

Why it fails: Storing all data in S3 Standard for a full year before deleting it violates the requirement to retain backups and logs for the entire retention period; deletion after one year makes the data unrecoverable if retention is longer. Additionally, S3 Standard is the most expensive storage class, with no lifecyle optimization, so you would pay premium prices for data that is rarely accessed. This approach ignores the cost-saving opportunities of tiering to lower-cost storage classes and risks compliance failures if the retention policy mandates data availability for several years.

Use S3 Glacier Flexible Retrieval to allow data retrieval in minutes.

Why it fails: S3 Glacier Flexible Retrieval (formerly Glacier) offers retrieval times of minutes to hours, but its storage price is higher than Glacier Deep Archive and the requirement here is only to keep backups and logs—there is no stated need for rapid access. Choosing Flexible Retrieval would incur unnecessary costs for the same retention duration, because Deep Archive is purpose-built for long-term archival where retrieval is rare and minutes-to-hours latency is acceptable. The phrase 'allow data retrieval in minutes' is a red herring: if the business does not actually need fast retrieval, you should prioritize the lowest-cost archival tier.

The custom AMI ID is specified in the environment properties instead of the launch configuration.

Why it fails: Elastic Beanstalk environment properties are arbitrary key/value pairs exposed to your application through the process environment, such as database URLs or feature flags; they are not consumed by the Elastic Beanstalk control plane to select an Amazon Machine Image. The custom AMI ID must be set in the launch configuration under 'Instances' or via the aws:autoscaling:launchconfiguration namespace. Specifying an AMI ID as an environment property is simply ignored for instance provisioning, so the Auto Scaling group will continue to use the default AMI for that platform branch, exactly as you observed.

The custom AMI is encrypted, and the instance profile does not have permissions to decrypt it.

Why it fails: A custom AMI that uses encrypted EBS snapshots requires the instance role attached to your environment to have kms:Decrypt and kms:GenerateDataKey permissions on the KMS key that encrypted the snapshots. If those permissions are missing, the Auto Scaling group cannot launch any instance from that AMI, and the environment will move to a 'Severe' state with launch failures—Elastic Beanstalk does not fall back to the default AMI. The instance's root volume would fail to attach during the launch cycle, which is a hard error rather than a silent substitution.

The Elastic Beanstalk platform version is incompatible with the custom AMI.

Why it fails: Elastic Beanstalk custom AMIs must be derived from the exact platform version (e.g., a specific Amazon Linux 2 Ruby branch) that the environment is using; if you rebuild the AMI from a different platform version or operating system, the instance may not boot or may fail the environment's health checks after launch. The service, however, does not validate the AMI's compatibility at configuration time or swap in a default AMI when a mismatch is detected. Instead, the Auto Scaling group will try to launch with the incompatible AMI, causing repeated launch failures until you correct the AMI or platform configuration.