Resilient Cloud Solutions practice questions

Implement a custom conflict resolution using DynamoDB Streams and AWS Lambda.

Why wrong: DynamoDB global tables already provide last-writer-wins (LWW) conflict resolution per item, so adding a custom Streams + Lambda resolver introduces unnecessary complexity. A custom resolver must handle duplicate event delivery, ordering, and potential write-backs that trigger the Stream again, creating loops. It also adds latency and cost, and it does not address the fact that concurrent writes to the same item still need a deterministic policy—built-in LWW is the default and is adequate for typical workloads.

Switch to eventual consistency reads to reduce conflicts.

Why wrong: Eventual consistency reads control how fresh a read result is, not how conflicting writes are resolved. In global tables, replication is asynchronous, and conflicts are resolved at write time using LWW based on the replica timestamp, independent of the read consistency setting. Switching from strongly consistent to eventually consistent reads only risks returning stale data, but it does not prevent or reconcile conflicting updates to the same item.

Add a third global table region to increase redundancy.

Why wrong: Adding a third global table region increases replication paths and creates more endpoints where concurrent writes can originate, potentially increasing the frequency of write-write conflicts. Redundancy improves availability and durability across regions, but it does not alter the underlying LWW conflict resolution mechanism—every conflict is still resolved by the same timestamp-based rule. More regions mean more replication latency and more chances for different writers to race, not a reduction in conflicts.

Use a larger instance type to handle more traffic.

Why wrong: Scaling up to a larger instance type increases the CPU, memory, and network capacity available to handle higher traffic, but it does not change the fact that the instance is pinned to a single Availability Zone. If that AZ experiences an outage, the instance remains inaccessible regardless of its size. This is a capacity optimization strategy, not a high-availability strategy, so it fails to address the application's resilience to AZ failure.

Enable EC2 Auto Recovery to automatically restart the instance if it fails.

Why wrong: EC2 Auto Recovery detects an impaired instance due to underlying hardware failure and automatically restarts it on a new healthy host, but that host is still within the same Availability Zone. The recovery process preserves the instance ID, private IP, and Elastic IPs, but it cannot migrate the instance to a different AZ. Therefore, if the entire AZ fails, Auto Recovery provides no benefit because the instance is still isolated in the failed AZ.

Place the instance in a placement group to ensure low latency.

Why wrong: A placement group is designed to reduce network latency and maximize throughput by placing instances in the same rack or within a single Availability Zone. This actually concentrates all instances in one failure domain, so an AZ outage would take down every instance in the placement group. Placement groups target performance optimization for tightly coupled workloads, not resilience, making them irrelevant for protecting against AZ failure.

Enable MFA Delete and set a lifecycle policy to transition to S3 Glacier after 30 days.

Why wrong: Enabling MFA Delete requires every permanently destructive operation (such as deleting an object version or suspending versioning) to be authenticated with a second factor, but it does not prevent an authorized user from deleting the current version of an object—it only adds an extra authentication step, which is impractical to automate and does not provide a retention guarantee. Additionally, transitioning to S3 Glacier (Standard) after 30 days does nothing to protect the object from being deleted during that 30-day window or even after the transition, since lifecycle policies only move data between storage classes and never grant immutability.

Enable versioning and set a lifecycle policy to expire noncurrent versions after 365 days.

Why wrong: Versioning preserves every object version, but the protection is only against overwriting the current version; a user with Versioned Delete permission can still permanently delete both the current and all noncurrent versions. The lifecycle rule that expires noncurrent versions after 365 days automates cleanup of old versions but does not in any way protect the current version, which remains fully deletable at any time. Moreover, if a delete marker is created, the object is effectively 'deleted' even though the underlying version remains until lifecycle expiry, so versioning alone cannot stop a malicious actor from removing the live copy of your backup data.

Enable cross-Region replication to a bucket with versioning enabled.

Why wrong: Cross-Region Replication (CRR) asynchronously copies objects to a destination bucket, but the source bucket remains a standard, mutable S3 bucket—any user with s3:DeleteObject permission can delete the object from the source, and with versioned bucket configuration also delete or add delete markers to versions. The destination bucket, even if versioning is enabled, is still an ordinary bucket; a user with permissions there can permanently purge both source-replicated copies and any version history. Finally, CRR does not apply any retention or governance controls, so it offers no protection against accidental, malicious, or ransomware-based deletion—it is simply a data availability feature, not a data protection feature.

Add more AZs and configure the NLB with cross-zone load balancing.

Why wrong: Adding more Availability Zones and enabling cross-zone load balancing on the NLB improves distribution and fault tolerance, but it does nothing to preserve session affinity. Because the NLB operates at Layer 4 and has no concept of HTTP cookies, consecutive requests from the same client can be routed to different EC2 instances, causing the local session state to be lost. This option fails to address the core problem of session continuity.

Replace the NLB with an ALB and use ElastiCache for session storage.

Why wrong: Replacing the NLB with an ALB and offloading session state to ElastiCache would technically provide shared, durable sessions across instances, but it forces the application to be rewritten to read and write session data from an external cache. This is not a minimal infrastructure-only change, and it introduces additional operational complexity and a new dependency that must be managed. Since the question asks for the least disruptive solution, this option is incorrect.

Use a Multi-AZ RDS instance to store session state.

Why wrong: Using a Multi-AZ RDS instance to store session state requires modifying the application to persist session data in a relational database, which adds significant latency and overhead for high-frequency session read/write operations. This approach not only demands substantial code changes but also couples session lifecycle management to database scalability and cost. Such a solution is neither minimal nor the simplest way to address the existing session affinity problem.

Use backup and restore with daily snapshots stored in S3 and cross-Region replication.

Why wrong: Daily snapshots copied to S3 with cross-Region replication provide a restore point only every 24 hours, making the RPO at least 24 hours and thus failing the 1-hour RPO requirement. Moreover, restoring from a snapshot requires recreating EBS volumes or an RDS instance from the snapshot, a process that typically takes 30–60 minutes or more for large databases, so it cannot meet the 15-minute RTO. Cross-Region replication of snapshots is asynchronous and only copies completed snapshots, further delaying data availability in the DR Region.

Use a warm standby strategy with a scaled-down copy of the production environment in the DR Region, and replicate data using RDS Multi-AZ with synchronous replication.

Why wrong: RDS Multi-AZ is a high-availability feature that synchronously replicates data to a standby instance in a different Availability Zone within the same AWS Region; it does not replicate any data to a separate DR Region. Therefore, this configuration provides no data durability or recoverability in another Region, leaving the application completely unprotected against a Region-wide outage. Even though the warm standby environment itself is pre-provisioned, the database remains single-Region, so the RPO and RTO targets cannot be satisfied for a true disaster recovery scenario.

Use a pilot light strategy with EC2 instances stopped and RDS snapshots copied to the DR Region.

Why wrong: The pilot light approach with snapshots requires starting EC2 instances and restoring RDS from a snapshot, which typically takes longer than 15 minutes. The RPO depends on snapshot frequency, which must be at least hourly to meet the 1-hour RPO, but the RTO is not met.

Increase the CPU and memory limits for the ECS task definition.

Why wrong: Increasing the CPU and memory limits only changes the individual task's resource footprint; it does not add additional task instances, so there is no capacity to absorb a spike in order traffic and no redundancy to survive an Availability Zone failure. In fact, larger tasks can reduce deployment density across the cluster and make it harder for the ECS placement algorithms to distribute tasks evenly across AZs. Vertical scaling also does nothing to protect the RDS database, which remains a single point of failure. The correct approach for sudden load is horizontal scaling via ECS Service Auto Scaling and for AZ failure is multi-AZ task placement and a Multi-AZ database.

Place an Amazon CloudFront distribution in front of the order service.

Why wrong: Amazon CloudFront is an edge caching service that primarily accelerates distribution of static content and can cache some dynamic responses, but an order service receives non-idempotent transactional writes that must reach the backend in real time; a CDN cannot absorb write traffic or provide a failover for the ECS tasks or RDS instance. CloudFront does not perform health checks against the order service to reroute traffic, and even if an origin group were configured, the order service itself and the database would still need to be deployed redundantly across Availability Zones. Using CloudFront here would only add latency for uncached POST requests and create a misleading sense of resilience.

Use RDS Proxy to manage database connections.

Why wrong: RDS Proxy is a connection-pooling layer that sits between the application and the database, improving scalability and reducing database CPU/memory overhead by reusing connections, but it does not replicate data or provide a standby database. If the RDS instance is in a single Availability Zone and that AZ fails, the proxy has no healthy database to route to; RDS Proxy is itself highly available but cannot rescue a single-AZ database. It can complement a Multi-AZ deployment by keeping connection churn low during failover, but it should never be used as a substitute for Multi-AZ.

Use eventually consistent reads for all queries.

Why wrong: Eventually consistent reads reduce read capacity unit consumption by half because DynamoDB doesn't need to wait for replication to all AZs, but throttling occurs when your consumed capacity exceeds the provisioned table's capacity. Throttling is a function of the capacity limit, not the consistency mode; changing consistency simply changes how many RCUs each request costs, not the overall throughput ceiling. If the workload is already exceeding provisioned read capacity, eventual consistency may help marginally but won't solve systematic throttling, and it's not a scalable or guaranteed fix.

Move the data to Amazon RDS with read replicas.

Why wrong: Migrating to Amazon RDS with read replicas abandons DynamoDB's low-latency, fully managed NoSQL access patterns and operational simplicity. Read replicas address read scaling in relational databases, but they require schema redesign, connection management, and eventual consistency caveats, plus you'd need to handle write scaling separately. This is a disproportionate architectural overhaul when DynamoDB has built-in native mechanisms—like DAX or Auto Scaling—that solve the throttling problem without changing the data store or application data model.

Switch DynamoDB to On-Demand capacity mode.

Why wrong: On-Demand capacity mode eliminates the need to provision capacity; DynamoDB instantly accommodates workload spikes and you pay per request, so it does avoid throttling. However, On-Demand pricing typically costs more than well-rightsized provisioned capacity—particularly for steady or predictable workloads—because you're paying a premium for the flexibility of unlimited capacity. While it's a valid mitigation, the question likely expects a more cost-effective solution that doesn't unnecessarily inflate your bill, especially when the read-heavy pattern can be addressed with DAX or Auto Scaling.

Use an Auto Scaling policy for EC2 based on RDS connection count and implement a read replica for the primary.

Why wrong: Scaling EC2 instances based on RDS connection count is problematic because the metric reflects total database sessions, not a per-instance threshold, and adding more app servers without connection pooling simply opens more connections to the same primary, worsening the very problem. While adding a read replica can offload SELECT queries, it does nothing to protect the primary from connection storms during failover, because read replicas cannot serve write traffic or reduce the number of connections required by the application. This approach treats the symptom (load) rather than the structural issue (connection management).

Configure Multi-AZ RDS with a synchronous standby and use Amazon RDS for MySQL with enhanced monitoring.

Why wrong: Multi-AZ RDS already provisions a synchronous standby replica and automatic failover, so configuring it again does not change the connection behavior that causes the outage. Enhanced monitoring provides OS-level metrics like memory, CPU, and disk utilization to help diagnose bottlenecks, but it is a visibility tool, not a control-plane solution for connection exhaustion. The failure mode here is too many connections to the primary, not a lack of high availability or insufficient observability.

Increase the instance size of the RDS primary and enable Performance Insights to identify slow queries.

Why wrong: Scaling up the primary instance adds CPU, memory, and I/O capacity, but connection exhaustion is constrained by the max_connections parameter and per-connection memory overhead, not just raw instance size; under a connection storm, a larger instance may still run out of connection slots or thread capacity. Performance Insights can expose slow queries and locking, which helps after-the-fact tuning, but it cannot prevent the app from opening thousands of connections during failover. This reactive, expensive approach does not implement connection pooling or reduce read traffic, so the original trigger remains.

Place all EC2 instances in a single AZ and use an Amazon Route 53 health check to reroute traffic to a standby environment in another AZ.

Why wrong: Concentrating all EC2 instances in a single Availability Zone eliminates AZ-level redundancy for the application tier; if that AZ fails, the web tier becomes unavailable until Route 53 health checks fail and clients honor the DNS TTL, which can take minutes. This approach also does not address the RDS failover problem: even if the standby environment has its own database, existing application connections to the failed primary cannot be transparently re-established, so the application will experience connection errors and downtime during the switchover.

Deploy the RDS instance as a Single-AZ instance in the same AZ as the primary EC2 instances, and use read replicas for failover.

Why wrong: A Single-AZ RDS instance provides no automatic failover; if the instance or its AZ fails, the database becomes unavailable until you manually restore from a snapshot or promote a read replica. Promoting a read replica is not a failover mechanism: it takes several minutes, requires an endpoint change, and replication lag means you could lose recent writes. Read replicas also have their own storage and compute separate from the primary, and they do not automatically assume the primary role, so this design does not meet the availability requirement.

Configure an Application Load Balancer in front of the RDS instance to distribute connections across AZs.

Why wrong: An Application Load Balancer operates at Layer 7 and only handles HTTP/HTTPS traffic, which is incompatible with the native wire protocol of RDS MySQL, PostgreSQL, or Aurora. Database connections are long-lived, stateful sessions that must reach the single writer endpoint; an ALB cannot pool connections, enforce transaction consistency, or understand database health checks. Attempting to distribute database connections across AZs with an ALB would either fail to connect or route traffic to read replicas that cannot accept writes, breaking the application.

Deploy an Active-Active configuration across two AWS regions using Route 53 latency routing. Use ElastiCache for Redis Global Datastore with multi-region writes.

Why wrong: This option wrongly assumes ElastiCache Global Datastore can accept writes from both regions. In reality, Global Datastore implements a primary-secondary model where only the primary cluster accepts writes, and the secondary replicates from it; there is no native multi-region write support. Route 53 latency routing optimizes for minimum network latency, not for automated failover based on health, so it does not provide the deterministic health-check-driven recovery required to meet a 30-minute RTO. Active-Active also demands application-level conflict resolution that would add significant complexity.

Deploy a Pilot Light environment in us-west-2 with a scaled-down ECS service and Redis cluster. Use Route 53 DNS failover. On disaster, scale up the ECS service and promote the Redis cluster.

Why wrong: A pilot light keeps the core data plane (Redis) and minimal compute running, but the scaled-down ECS service and Redis cluster are not ready to serve full production traffic instantly. The described plan requires human intervention to scale up the ECS service and to promote or reconfigure the Redis cluster, and those manual actions can easily exceed the 30-minute RTO. Additionally, if the Redis cluster is scaled down or not continuously receiving writes, the promotion step may involve data recovery rather than a quick switch. Route 53 DNS failover can send traffic, but it cannot complete the infrastructure scale-up.

Use Amazon ECS with Fargate in us-east-1 only, and schedule daily snapshots of ElastiCache for Redis. In case of disaster, restore the snapshot in a new region and update DNS.

Why wrong: This is a backup-and-restore strategy, not a live DR site. Daily snapshots mean the RPO is up to 24 hours because changes made after the last snapshot are lost, and if the snapshot is taken during the day the window may be even less deterministic. Restoring an ElastiCache snapshot in a new region and rebuilding the ECS environment can take longer than 30 minutes, particularly when loading large datasets from Amazon S3. The lack of any running infrastructure in a second region also means DNS cutover happens only after all restoration, so the RTO is already blown.

Use a launch template with multiple instance types to ensure diversity across the fleet.

Why wrong: Using a launch template with multiple instance types diversifies the underlying hardware and can improve capacity acquisition for Spot Instances, but it does not address Availability Zone failure. If all instances are launched in a single AZ, a failure of that AZ will take down every instance regardless of instance type. Instance type diversity is a cost and scaling strategy, not an availability or fault-tolerance mechanism for AZ-level outages.

Use a single AZ but configure EC2 Auto Scaling to replace unhealthy instances automatically.

Why wrong: Configuring Auto Scaling to replace unhealthy instances within a single Availability Zone can handle individual instance failures, such as hardware faults or crashes, by terminating and relaunching them. However, it cannot protect against an Availability Zone failure, because the replacement instances are launched in the same AZ and will likely be affected by the same outage, such as a network partition or power loss. Moreover, the ASG itself may be unable to launch new instances if the AZ's capacity is impaired, leaving the application completely unavailable.

Launch all EC2 instances in the same AZ to minimize latency, and configure the Auto Scaling group to maintain a minimum of two instances.

Why wrong: Launching all instances in the same Availability Zone and maintaining a minimum of two instances provides instance-level redundancy, so the application can continue if one instance fails and is replaced. But this design remains a single point of failure: if the entire AZ becomes unavailable—for example, due to a natural disaster or regional network issue—both instances are unreachable and the ASG cannot restore service elsewhere. High availability requires distributing instances across multiple geographically isolated AZs, not just having multiple instances in one location.

Change the service type from ClusterIP to NodePort and configure an external load balancer.

Why wrong: Converting the Service from ClusterIP to NodePort and placing an external load balancer in front only changes the ingress path; it does not alter the Deployment's replica count, scheduling, or failure-domain spread. The load balancer still forwards traffic to whatever endpoints the Service discovers, so if all Pods are colocated and the node (or availability zone) hosting them fails, the Service will have no healthy endpoints and the load balancer returns 503s. It also provides no protection against voluntary disruptions like a node drain.

Increase the number of replicas to 10 and use a node selector to schedule all pods on the largest instance type.

Why wrong: Adding replicas to 10 is redundant, and a node selector that forces every Pod onto the largest instance type actually creates a tighter coupling to a single infrastructure dependency. If the cluster only has one node matching that label, or the scheduler packs all replicas onto one big node, that node becoming unhealthy takes the entire application down in one event. Without pod anti-affinity or topology-spread constraints, the scheduler is free to place all replicas in the same failure domain, and the extra replicas provide no additional resilience.

Enable HorizontalPodAutoscaler with a target CPU utilization of 50% to automatically scale the Deployment.

Why wrong: The HorizontalPodAutoscaler only scales replica count in response to CPU metrics; it has no awareness of node health, Pod placement, or failure domains. If all current replicas reside on a single node and that node fails, the HPA will eventually trigger replacements, but there will be downtime while new Pods are scheduled, and the replacement Pods could again land on the same surviving node because no spread mechanism exists. It also does nothing to prevent violation of a PDB during a drain, so it cannot provide a high-availability guarantee.

Use Amazon EFS Replication to replicate application data across regions with a recovery point objective (RPO) of 1 second.

Why wrong: Amazon EFS Replication does replicate file data asynchronously to a destination Region, but it does not guarantee a 1-second RPO—backup replication lag is typically minutes, not seconds. More importantly, EFS is for file storage, not relational databases, so it cannot replicate the application's RDS database content or transactions. This option would leave the database without cross-Region replication, so it fails the core DR requirement.

Extend the existing Auto Scaling group to launch instances in two regions by specifying a second region in the launch template.

Why wrong: An Auto Scaling group is a Regional resource—it can only launch instances in the subnets and Availability Zones of the single AWS Region in which the group exists. A launch template can only specify one Region's AMI and network settings; you cannot specify a second Region. To run compute in another Region, you must create a separate Auto Scaling group in that Region and then coordinate failover through DNS, so this option is not technically implementable as stated.

Replace the ALB with a Network Load Balancer (NLB) to reduce latency, and use an Auto Scaling group with a step scaling policy based on Redis CPU utilization.

Why wrong: Replacing the ALB with an NLB only optimizes Layer 4 load balancing and does nothing to relieve CPU pressure on the ElastiCache node, which is the actual bottleneck. Moreover, Auto Scaling step policies cannot use Redis CPU utilization as a native CloudWatch metric because ElastiCache publishes cache metrics (e.g., CPUUtilization) only at the cache-cluster level, and the policy would scale application instances rather than the cache itself, leaving the overworked Redis primary untouched.

Increase the instance size of the ElastiCache for Redis node and the size of the Aurora writer instance. Also, increase the cooldown period for the Auto Scaling group to allow new instances to warm up.

Why wrong: Vertically scaling the ElastiCache node and Aurora writer may temporarily mask the CPU saturation, but it does not remove the single point of failure and hits hard instance-size ceilings, especially for Redis with synchronous writes. Increasing the Auto Scaling cooldown period slows down the addition of web/app capacity during traffic spikes, which can worsen latency and undermine the very elasticity needed to handle the production load, so this approach both fails to address root cause and degrades responsiveness.

Implement Amazon RDS Proxy in front of the Aurora cluster to reduce database connection overhead, and increase the size of the Redis instance to handle more connections.

Why wrong: RDS Proxy reduces connection churn and overhead for the Aurora database, but the reported bottleneck is Redis CPU saturation, not database connection limits. Increasing the Redis instance size provides more memory and possibly vCPUs, but a single large node still cannot shard data or spread read load, so CPU remains pinned during peak traffic and the cache remains a single point of failure—this option optimizes the wrong tier entirely.

Deploy an Auto Scaling group with a dynamic scaling policy that adds instances in the remaining AZs.

Why wrong: Auto Scaling groups are designed to maintain desired capacity by launching or terminating instances based on scaling policies, but they operate at the infrastructure level and have no awareness of user session state. A dynamic scaling policy that adds instances in the remaining Availability Zones compensates for lost capacity and helps distribute new requests, but sessions that were pinned to the terminated instances' local memory are gone forever, causing users to be logged out or lose in-progress work. This option ignores the fundamental requirement for a persistent, shared session store; scaling out capacity does not provide data redundancy or failover for session data.

Configure the application to use a custom DNS name with a low TTL pointing to the ElastiCache cluster endpoint.

Why wrong: A custom DNS record with a low TTL affects how quickly clients or resolvers refresh the mapping from a friendly name to the ElastiCache cluster endpoint, but it does nothing to preserve session data that already exists on the underlying Redis nodes. If the primary ElastiCache node fails, the DNS record alone cannot redirect traffic to a node that has the same session data — ElastiCache endpoint DNS is managed by AWS and already takes advantage of its own failover mechanisms. Lowering TTL merely reduces the window of stale DNS resolution; it does not add replication, sharding, or automatic failover, so it offers negligible benefit for session state resilience. The real solution must involve ElastiCache's native replication and clustering features, not the application's DNS configuration.

Enable Multi-AZ for the ElastiCache cluster to automatically fail over to a replica in another AZ.

Why wrong: While ElastiCache for Redis does support Multi-AZ with automatic failover for replication groups (non-cluster mode), this option is incorrect because it provides only a single replica and does not shard data across multiple nodes. In the scenario, the application uses a shared cluster, implying a need for distributed session storage. Option C (cluster mode with replicas in different AZs) offers better resilience by spreading data across multiple shards and replicas, ensuring session data remains available during an AZ failure without performance degradation.

The bucket has a default encryption policy that overrides the IAM policy.

Why wrong: Default encryption is a bucket-level setting invoked when no encryption headers are supplied, but it operates after authorization. IAM policy evaluation is the first step: the Allow grants the action, and the Deny's condition is false because the header is absent, so the request is permitted before default encryption is considered. Default encryption does not 'override' IAM; it only determines how an already-authorized object is stored, and it cannot satisfy a condition that requires a specific request header.

The Lambda function is using a KMS key instead of SSE-S3.

Why wrong: Choosing SSE-KMS instead of SSE-S3 does not explain the missing header. If the Lambda function were using a KMS key, the PutObject request should include x-amz-server-side-encryption: aws:kms, and because that value differs from AES256, the Deny's StringNotEquals condition would actually match and block the request. Since the described behavior is an allowed PutObject with no encryption header, the function is not sending any SSE header at all, so this option cannot be the root cause.

The Lambda function is specifying a different encryption algorithm, such as aws:kms.

Why wrong: If the function were specifying a different algorithm such as aws:kms, the header would be present and its value would satisfy the Deny condition (StringNotEquals AES256), causing the call to be rejected. The reported problem is the opposite—the PutObject succeeds—which only happens when the encryption header is absent. Mentioning an alternative algorithm is a variant of the header-present scenario and does not match the symptom of a successful unencrypted write.

Configure the Auto Scaling group to launch instances in a single Availability Zone with a desired capacity of 6.

Why wrong: If that Availability Zone fails, all six instances become unavailable, causing a complete outage of the stateless web application. The Auto Scaling group cannot launch replacement instances in other zones because it is confined to a single AZ, so there is no automatic failover. Even with a desired capacity of six, every instance shares the same failure domain, so the additional capacity does not improve resilience.

Configure the Auto Scaling group to launch instances in two Availability Zones with a desired capacity of 4.

Why wrong: With a desired capacity of four spread across two Availability Zones, each AZ typically runs two instances, so a single AZ failure removes 50% of your serving capacity. The remaining AZ may not have spare capacity to launch replacements, and the ASG's rebalancing could be delayed or fail if that AZ is constrained. A three-AZ design with one instance per AZ would preserve two-thirds of capacity, making this two-AZ setup unnecessarily risky for production traffic.

Configure the Auto Scaling group to launch instances in two Availability Zones with a desired capacity of 6, all in one AZ.

Why wrong: Placing all instances in one Availability Zone, even while specifying two AZs in the ASG configuration, completely defeats the purpose of multi-AZ deployment because a failure of that single AZ takes down the entire fleet. This situation often results from a misconfiguration, such as a launch template that only references subnets from one AZ, or from not redistributing instances across the configured zones. Regardless of the desired capacity of six, the architecture remains a single point of failure and cannot provide the promised resilience.

Review Agent Logs → Check CodeDeploy Console → Validate AppSpec File → Verify Instance Configuration → Redeploy

Why wrong: Beginning with agent logs is inefficient and often misleading because the CodeDeploy console aggregates deployment-level status and provides lifecycle event details that can immediately direct you to the specific instance and phase where the failure occurred. Agent logs are instance-local, require direct SSH/SSM access, and may not even exist if the deployment failed during bundle validation or before the agent was invoked. The console should be the first stop to obtain a high-level error code and identify which instances are in a failed state, after which log review becomes targeted and productive.

Validate AppSpec File → Check CodeDeploy Console → Review Agent Logs → Verify Instance Configuration → Redeploy

Why wrong: Validating the AppSpec file before consulting the console is premature because the console reveals whether the failure is actually AppSpec-related (e.g., an InvalidAppSpecFile error) versus a hook script failure, a permissions problem, or an instance connectivity issue. Static validation of AppSpec YAML syntax or file paths will not surface runtime errors such as a missing script executable or an incompatible shell command. The correct approach is to let the console's deployment lifecycle and error message drive which artifact to inspect, so you do not waste time correcting a file that was never the root cause.

Redeploy → Check CodeDeploy Console → Review Agent Logs → Validate AppSpec File → Verify Instance Configuration

Why wrong: Redeploying immediately without any diagnosis almost guarantees the same failure and can be actively harmful if the deployment triggers rollback or if the application is left in a partially updated state. CodeDeploy may even reject redeployment while the original deployment is still in a terminated or failed state with an in-progress lifecycle event, or the same misconfigured bundle will simply fail again. Troubleshooting must occur before any redeploy attempt so that the fix is verified and the deployment group is in a clean, known state; redeploy is the final verification step, not the initial action.

Lower TTL, then configure health checks, then promote RDS, then update DNS, then verify

Why wrong: Lowering the TTL before health checks are configured is backwards: health checks must be the first step so Route 53 can reliably evaluate endpoint status and govern DNS failover. If you reduce TTL first, edge resolvers will cache the current primary record more briefly, but there is no health-based routing logic yet to act on that faster expiration during an outage. A premature TTL change also causes unnecessary DNS request amplification before your routing policy is ready, and any subsequent health check misconfiguration could still send traffic to an unhealthy endpoint.

Configure health checks, then promote RDS, then lower TTL, then update DNS, then verify

Why wrong: Promoting the RDS replica before lowering the TTL means the DNS record still points to the (now standby) old primary with a long TTL; clients with cached DNS will keep hammering the old primary, which is no longer writable or may be mid-promotion. In a fast-failover scenario you must shrink the TTL first so the eventual DNS update propagates quickly, otherwise you create an extended window of mixed routing where some clients hit the read-only old primary and others hit the new primary before DNS converges. This ordering also violates the principle of making the control-plane changes in dependency order: monitoring and propagation settings must precede the actual promotion cutover.

Configure health checks, then update DNS, then lower TTL, then promote RDS, then verify

Why wrong: Updating DNS before promoting RDS is dangerous because Route 53 would point at the secondary RDS instance while it is still a read replica, so application writes fail with read-only errors and you risk data loss if the promotion is not completed cleanly. The DNS change must come after the promotion so that the record set only starts resolving to an instance that is already the writable primary. Additionally, updating DNS while the old primary is still serving traffic can cause split-brain writes between the old primary and the new primary during the final replication handoff, which is a classic data-integrity failure in disaster recovery runbooks.

Stack Set: A JSON or YAML text file that describes the infrastructure

Why wrong: This option incorrectly describes a Template. In CloudFormation, a Stack Set is actually an administrative entity that stores the template and configuration used to create, update, or delete stacks across multiple accounts and AWS regions, known as stack instances. The text "JSON or YAML text file that describes the infrastructure" fits a Template, which is a declarative document listing resources and properties, not the manager of multi-account deployments.

Template: Allows you to create, update, or delete stacks across multiple accounts and regions

Why wrong: This option incorrectly describes a Stack Set. A Template is a declarative JSON or YAML document that describes the AWS resources to be created and their properties, parameters, and other configuration. It does not perform actions; instead, CloudFormation interprets the template to create a stack, and it is the Stack Set (not the template) that enables managing identical stacks across multiple accounts and regions through stack instances.