Resilient Cloud Solutions practice questions

Increase the instance size to handle higher load.

Why it fails: Larger instances still have a fixed capacity and may still become overwhelmed; also cost-inefficient.

Configure step scaling policies based on CPU utilization.

Why it fails: Step scaling reacts after the threshold is breached, which may be too slow to prevent downtime.

Set a higher CPU threshold for health checks.

Why it fails: Raising the threshold only masks the problem; instances may still become unresponsive.

Switch to eventual consistency reads to reduce conflicts.

Why it fails: 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 it fails: 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 conditional writes with a version number attribute to ensure updates are applied only to the latest version.

Why it fails: By including a version number attribute in a conditional write (e.g., `SET version = version + 1 ... WHERE version = :expected`), the application uses optimistic locking to guarantee that an update is applied only when the client's expected version matches the current item version. If the condition fails, the client can re-read the latest item, merge or retry the update, and thus avoid overwriting concurrent changes. This approach aligns with DynamoDB's LWW because the version check ensures a deterministic, ordered update sequence, preventing stale writes from triumphing solely due to last-writer timestamp.

An Application Load Balancer (ALB) deployed in one Region.

Why it fails: A single-Region ALB cannot survive the loss of that Region, so it fails the cross-Region resilience requirement. It is the natural component for distributing traffic across multiple Availability Zones within one Region, and would be correct if the requirement were only Availability Zone fault tolerance rather than whole-Region failure.

Amazon EC2 instances in a single Region.

Why it fails: EC2 instances confined to one Region are lost if that Region fails, so they cannot satisfy cross-Region resilience. Single-Region EC2 fleets are the standard building block for Availability Zone-level high availability, and would be correct if the stem required only resilience to an Availability Zone outage.

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

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

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

aws s3 sync: Deploys a CloudFormation stack

Why it fails: Mapping aws s3 sync to CloudFormation stack deployment is incorrect because the command's entire purpose is object-level data transfer: it synchronizes files between a local filesystem and S3, or S3-to-S3, using size and modified-time heuristics. It has no concept of templates, stacks, change sets, rollback triggers, or IAM capabilities. If you ran it with a CloudFormation template, the template would simply be uploaded as an S3 object; no stack would be created, and the subsequent resource provisioning would not occur.

aws cloudformation deploy: Syncs files to an S3 bucket

Why it fails: The aws cloudformation deploy command does not sync files to a bucket; it takes a CloudFormation template as input and provisions or updates the stack's logical resources through the CloudFormation service. While it might upload the template to an internal or user-supplied S3 bucket to satisfy the service's template-size limit, that is incidental staging, not a generic file synchronization operation with --delete semantics or incremental content comparison. Its outputs are stack IDs, outputs, and events, not object transfer results.

Enable DynamoDB global tables or use a Multi-AZ deployment for the table.

Why it fails: DynamoDB tables are always stored on multiple underlying storage nodes across multiple Availability Zones within a region, so a 'Multi-AZ deployment' is already inherent and cannot be toggled as an additional feature. Global tables replicate data across AWS regions for disaster recovery and low-latency global access, but they do not increase the write capacity of a single table in the primary region. Neither approach addresses the burst-capacity limits or per-partition throttling that occurs during traffic spikes.

Add a read replica to the DynamoDB table.

Why it fails: DynamoDB does not support traditional read replicas like a relational database; the equivalent for read scaling is DAX (DynamoDB Accelerator) or global tables for multi-region reads. More importantly, session state writes are the dominant workload, and a read replica—even if one existed—would only offload read queries, not reduce write throttling. Since the reported symptom is throttling and session timeouts, which are caused by write request limits, this option fails to target the actual cause.

Increase the EC2 instance sizes to handle more traffic.

Why it fails: Increasing EC2 instance sizes only scales the compute capacity of the web servers, leaving the session state store untouched. If DynamoDB is throttling write requests for session state, larger instances will actually generate even more write traffic, potentially worsening the throttling and timeouts. The bottleneck resides in the database layer, not the application layer, so vertical scaling of EC2 does not increase DynamoDB's write capacity or partition throughput.

Add additional health checks for the same endpoint.

Why it fails: Adding more health checks for the same endpoint does not accelerate failure detection because each check is independent and still enforces its own interval (minimum 10 seconds) and consecutive-failure requirement (by default 3). Route 53 does not aggregate or compare duplicate checks; failover only evaluates the health state of the specific check associated with the resource, so extra checks don't reduce the time to mark an endpoint unhealthy. The only way to combine checks for speed is a calculated health check.

Reduce the health check interval to 5 seconds.

Why it fails: Route 53 does not permit a 5-second health check interval; the fastest configurable interval is 10 seconds, and the standard interval is 30 seconds. Even with a 10-second interval, the default failure threshold of three consecutive failed health checks means the endpoint is marked unhealthy after roughly 30 seconds, and reducing the interval further is impossible. Simply trying to set 5 seconds would be rejected by the API.

Change the routing policy to latency based.

Why it fails: Latency-based routing selects the endpoint with the lowest network latency for the requesting client, not the endpoint with the fastest health-check failure detection. Even if you associate health checks with a latency policy, it does not provide the active/passive failover behavior of failover routing—it just filters out unhealthy endpoints from the latency ranking. Switching to latency-based routing would not shorten detection time and could actually route traffic to a healthy high-latency endpoint rather than failing over to a designated secondary.

AWS Snowball Edge

Why it fails: AWS Snowball Edge is a physical, offline data transfer appliance designed to move large volumes of data in batches, not to support continuous, real-time replication. Shipping a device to AWS and then restoring data in the DR region would introduce hours to days of delay, making it impossible to meet typical RPO and RTO targets for disaster recovery.

Amazon S3 with versioning

Why it fails: Amazon S3 with versioning protects individual object versions against accidental deletion or overwrite, but it is an object storage service, not a database replication engine. It has no awareness of database transactions or schemas, so it cannot replay or synchronize changes from a source database, and using it alone would leave the database unrecoverable at the required RPO/RTO.

AWS Storage Gateway with cached volumes

Why it fails: AWS Storage Gateway with cached volumes extends on-premises storage to AWS by caching frequently accessed data locally while storing the full dataset in S3. It operates at the block/volume level and does not understand database semantics, so it cannot provide a consistent database replica or replay transactions; it is not a database replication or DR service.

The policy does not include the ec2:DescribeRegions action, which is required to describe instances in other regions.

Why it fails: DescribeRegions is a separate EC2 endpoint action used to list the regions available to the account; it is not a prerequisite for calling DescribeInstances. EC2 DescribeInstances is a regional action invoked against a region endpoint (e.g., ec2.eu-west-1.amazonaws.com), and IAM evaluation checks only whether the principal is allowed to perform the ec2:DescribeInstances action on the resource. A policy lacking DescribeRegions does not prevent a user from describing instances in another region, because the DescribeInstances call itself does not require that capability; instance metadata and ARNs already convey region information. Therefore, this omission cannot explain the reported issue.

The Allow statement's Resource is set to '*' which only matches instances in the caller's region.

Why it fails: In IAM policies, the Resource element of '*' matches all resource ARNs across every region, not just the caller's region; EC2 instance ARNs include region but wildcards are not region-scoped. Because ec2:DescribeInstances is a list-type operation that does not support resource-level restrictions for specific instance IDs, AWS requires or accepts Resource '*' as the only meaningful scope, and it applies globally. Without a Condition block on ec2:Region, an Allow on ec2:DescribeInstances with Resource '*' grants the action from any region endpoint the caller chooses. Thus, the allow statement is not limited to the caller's region and cannot be the cause of cross-region describe failures.

The Deny statement for TerminateInstances implicitly denies all other EC2 actions in regions other than us-east-1.

Why it fails: An explicit Deny in IAM applies only to the actions named in its Action element and to the resource condition specified; it does not suppress or deny any other EC2 action. In this policy, the Deny statement targets TerminateInstances specifically, so DescribeInstances is evaluated independently and may still be granted by an Allow statement. The only way a user would be denied DescribeInstances in regions other than us-east-1 is if a separate policy/condition explicitly denies it, or if no Allow exists for that action (an implicit deny), neither of which is produced by the TerminateInstances Deny. Confusing an action-specific Deny with a blanket region-based denial is a common misunderstanding of IAM evaluation logic.

Add a step scaling policy to scale out more gradually.

Why it fails: A step scaling policy (or any dynamic scaling policy) adjusts the desired capacity of the Auto Scaling group based on CloudWatch alarms and metrics such as CPU utilization or request count. It has no bearing on how the ASG determines the health of individual instances; that is governed by the HealthCheckType and the associated ELB health check settings. Since the underlying problem is that instances are being considered ready before the application is fully operational, adding a scaling policy would not change the health check result—it would only affect the group's size in response to load.

Increase the HealthCheckGracePeriod to 600 seconds.

Why it fails: Increasing HealthCheckGracePeriod from the default (e.g., 300 seconds) to 600 seconds only postpones the initial health check evaluation after an instance enters service. It does not alter the health check type or the checks themselves—with EC2 health checks, the instance is still marked healthy as long as it passes the underlying EC2 status checks, regardless of whether the application is listening on the ELB. Once the grace period expires, the same unhealthy condition will still be detected, so this merely delays the inevitable replacement or re-evaluation without ensuring application readiness.

Increase the MaxSize to 10.

Why it fails: Raising the Auto Scaling group's MaxSize from 5 to 10 changes the maximum number of instances the group can launch, but it has no effect on how instance health is evaluated. Health checks are performed per-instance based on the configured HealthCheckType, and MaxSize only constrains the group's total capacity. If the current instances are failing the application-level health check, increasing MaxSize simply allows more unhealthy or unready instances to be launched, exacerbating the problem rather than resolving it.

Use AWS Step Functions with a task that invokes the ECS task, and configure a retry policy in the state machine

Why it fails: Step Functions can orchestrate an ECS task by calling the RunTask API and a retry policy on the state can re-invoke the task, so this solution is functionally possible. However, it requires you to manually model job submission, handle ECS task status polling, and manage the state machine execution history — AWS Batch already provides all of that as a managed service. The retry policy in Step Functions is generic (with backoff rate, max attempts), but you must also configure ECS task definitions and IAM for each call, making this a heavier, less streamlined solution than using AWS Batch.

Use an Amazon ECS service with a desired count of 1 and enable automatic task replacement

Why it fails: An ECS service with desired count 1 will continuously maintain one running task, but it is designed for long-running services, not for executing a batch job to completion. If the task fails or exits, the service restarts it, which is a restart, not a job-level retry: the job is not marked as failed, and there is no accounting of attempts or job state. Additionally, if the job is critical and you need exactly-once or retry-after-failure semantics, the service model will not stop restarting or notify a downstream system of job completion.

Use AWS Lambda with a dead-letter queue and reprocess events

Why it fails: AWS Lambda functions have a maximum execution timeout of 15 minutes, and a critical batch processing job is likely to run much longer, so this option is fundamentally constrained. While a dead-letter queue can capture failed events, an event that arrives in the DLQ does not automatically re-run the batch job; you would need a separate consumer to reprocess it, and that consumer must also handle the job's idempotency and ordering. Moreover, Lambda is optimized for short-duration, event-driven workloads, not for managing large jobs, so it would require significant custom orchestration to achieve even basic retry semantics.

Use an AWS Step Function to orchestrate the deployment with retry logic

Why it fails: An AWS Step Functions orchestration observes and coordinates the deployment, but CodePipeline already has native retry for failed actions. Adding Step Functions merely complicates the architecture by introducing an extra state machine, custom Lambda integrations, and additional cost. It does not solve the immediate need to retry a transiently failing deploy action with a simple pipeline-level setting.

Modify the CloudFormation stack to include a retry policy

Why it fails: CloudFormation templates do not accept a retry policy on resources; stack operations are either attempted or they fail, with no template-level retry property. While CloudFormation may internally retry certain API calls, customers cannot set a retry count for resource creation or update within the template itself. Therefore, modifying the stack definition cannot achieve the desired automatic retry of the deployment action in CodePipeline.

Configure the pipeline to retry the entire pipeline execution on failure

Why it fails: Retrying the entire pipeline execution restarts the source, build, and test stages as well as the failed deploy, causing redundant work and possible side effects such as rebuilding artifacts or re-publishing. It also loses the successful outputs of prior stages and increases time-to-recovery for transient deployment errors. The correct approach is to retry only the specific deploy action, preserving already-completed stage results and minimizing unnecessary pipeline activity.

Configure the Auto Scaling group to use a launch template that attaches the same EBS volume to new instances

Why it fails: Configuring the Auto Scaling group to use a launch template that attaches the same EBS volume to new instances is invalid because an EBS volume is a block-device resource bound to a single instance within one Availability Zone. A launch template's block device mappings can specify a snapshot or a new volume, not a previously existing volume ID; even if manually attached, the volume could serve only one instance at a time, creating an unavailability window and preventing scale-out beyond a single node. Thus this approach cannot provide a shared, persistent cache across the ASG.

Take periodic EBS snapshots and create a new volume from the snapshot for the replacement instance

Why it fails: Taking periodic EBS snapshots and creating a new volume for the replacement instance suffers from the inherent staleness of snapshot-based recovery. A snapshot captures the volume state at a single upstream point, so any cache entries written after the last snapshot are permanently lost, leading to cache misses and potential inconsistencies. Moreover, provisioning a new volume from a snapshot is a heavyweight operation that does not scale to multiple instances and defeats the purpose of an instantly available shared cache.

Use an EBS Multi-Attach volume and attach it to all instances in the Auto Scaling group

Why it fails: Using an EBS Multi-Attach volume for all instances in the Auto Scaling group is unsuitable because Multi-Attach is limited to Provisioned IOPS volumes (io1/io2) and can only attach to up to 16 instances in the same Availability Zone. An Auto Scaling group commonly spans multiple AZs for high availability, and Multi-Attach volumes reside in a single AZ, making the cache a single-affinity failure domain. Additionally, without a cluster-aware file system, multiple instances writing to the same raw block device would corrupt data.

Take manual snapshots of the RDS instance every 30 seconds and copy them to the secondary Region

Why it fails: Manual snapshots of RDS are point-in-time backups, but they are asynchronous and cannot be taken at a 30-second cadence; the snapshot process itself takes time to complete. Even if you could initiate a snapshot every 30 seconds, copying each snapshot to the secondary Region introduces additional delay and would require frequent deletion of old snapshots, making this approach operationally impossible and failing to meet an RPO under one minute. Snapshots are intended for periodic backup, not for continuous replication.

Enable Multi-AZ in the primary Region

Why it fails: Multi-AZ for RDS provides high availability within a single Region by maintaining a synchronous standby replica in a different Availability Zone of the same Region. If the primary fails, Amazon RDS automatically fails over to the standby, but this does not help if the entire Region becomes unavailable, since both AZs are in that same geographical Region. Therefore, Multi-AZ alone cannot meet cross-Region disaster recovery requirements, and it must be combined with a cross-Region mechanism like a read replica.

Enable automated backups with cross-Region copy enabled to the secondary Region

Why it fails: Enabling RDS automated backups with cross-Region copy does provide a backup copy offsite, but automated snapshots are taken only once per day (or at a configurable interval, still not continuously), and the cross-Region copy runs asynchronously after that. This means you can only recover to the last snapshot time, which could be up to 24 hours old, and the copied snapshot may lag even further, so the RPO would be hours, not under one minute. This option is a valid backup retention strategy but fails the required recovery point objective.

Switch the Lambda runtime from Python to Node.js for faster execution

Why it fails: The 15-minute maximum execution timeout is a hard, service-level limit that applies identically to every Lambda runtime, including Python and Node.js. Switching from Python to Node.js may change startup time or raw execution speed for certain workloads, but it has no effect on the timeout duration. If the function cannot finish processing the file within 15 minutes, it will be terminated regardless of the runtime.

Increase the Lambda function memory to 10,240 MB to improve CPU performance

Why it fails: While increasing Lambda memory does proportionally increase CPU allocation, the maximum configurable memory is 10,240 MB, and the execution timeout remains capped at 15 minutes. Boosting memory to the maximum might make the function process data faster, but if the total time still exceeds the timeout, the invocation will fail. Memory and timeout are independent limits: memory cannot buy more wall-clock time.

Modify the function to read the file in streaming chunks from S3

Why it fails: Streaming the file in chunks from S3 reduces memory usage because you don't load the entire object into RAM, but it does not reduce the total time required to read and process all bytes. The Lambda function still has to finish every chunk within the same 15-minute hard timeout; if the aggregate processing time of the whole object exceeds that, the function is killed mid-stream. Streaming only changes how data is delivered to the code, not the fundamental time limit.

Create a cross-Region Read Replica and promote it during failure

Why it fails: Promoting a cross-Region Read Replica requires a manual 'Promote Read Replica' operation via the AWS Management Console, CLI, or API; this process is asynchronous and can take several minutes, depending on replication lag and the size of the database, directly extending RTO. Because cross-Region replication is asynchronous, the replica may lack transactions committed shortly before the failure, risking data loss (RPO > 0). Even after promotion, the application's writer endpoint must be manually updated or redirected, adding further operational complexity and delay compared to the automatic DNS-based failover of a Multi-AZ DB cluster.

Increase the DB instance class size to improve I/O performance

Why it fails: Increasing the DB instance class size (e.g., from db.r6g.large to db.r6g.xlarge) improves compute and I/O capacity, which can reduce performance bottlenecks under load, but it does not alter the high-availability architecture or failover mechanism. Failover time is primarily determined by database health detection, replication state, and DNS propagation, not by instance class. In fact, a larger instance may take longer to start up and warm its buffer pool during promotion, potentially increasing failover duration rather than reducing it.

Remove Multi-AZ and use a single instance with increased backup frequency

Why it fails: Removing Multi-AZ and relying on a single instance with increased backup frequency eliminates automatic failover entirely; if the instance encounters an infrastructure or Availability Zone failure, the database becomes unavailable until you manually restore from a snapshot or perform point-in-time recovery. Increasing backup frequency—such as setting the backup retention period and interval—improves the recovery point objective (RPO) by reducing potential data loss, but it does not improve the recovery time objective (RTO); restoring a large database from a backup can take significant time, whereas Multi-AZ automatic failover typically completes in seconds.

Set the deployment circuit breaker to rollback on deployment failure and disable rollback

Why it fails: Enabling the ECS deployment circuit breaker and setting it to rollback will indeed revert to the last successful task set when the new deployment is unhealthy, but it only reacts after the failure has already occurred; it does not prevent the health checks from failing or the service from briefly serving unhealthy tasks. Additionally, the prompt asks for a configuration that prevents the issue, and disabling rollback would actually force an unrecoverable failed deployment rather than restoring service. Because the circuit breaker is a recovery mechanism, not a preventive safeguard against misconfigured health checks, it leaves the root cause untouched.

Change the deployment controller from ECS to CodeDeploy for blue/green deployments

Why it fails: Switching the ECS deployment controller to CodeDeploy blue/green replaces the rolling update with a parallel blue/green flow where the entire new task set is created before any traffic is shifted. While this isolates the old environment during the health check window, the new green task set will still run the same misconfigured health check and likely fail the deployment, and CodeDeploy will not automatically correct an application-level health check flaw. Moreover, this approach changes the deployment topology rather than tuning how task survival and health check assessment behave, so it does not address the underlying cause of the health check failure.

Set the deployment minimum healthy percent to 0 and maximum percent to 200

Why it fails: Setting min healthy percent to 0 and max percent to 200 tells ECS it may stop all old tasks before the new tasks are fully healthy, so a health check failure in the new task definition will tear down the entire service with nothing left to serve traffic. Even with max percent 200, the controller can place replacement tasks at 200% momentarily, but it is also free to scale the old task count to zero before the new tasks become stable if the deployment algorithm deems it necessary. This configuration maximizes availability risk and invalidates the safety of an automatic rollback, as no healthy tasks remain to form a fallback task set.

Store temporary data on instance store volumes instead of EBS

Why it fails: Instance store is ephemeral and data is lost on failure.

Use an EBS snapshot and create a new volume from the snapshot for the new instance

Why it fails: Snapshots have restore time and may not be up-to-date.

Use an EBS Multi-Attach volume attached to all instances in the Auto Scaling group

Why it fails: Multi-Attach allows shared block storage across instances in the same AZ.

Configure the application to use the Aurora reader endpoint for all queries

Why it fails: The reader endpoint is a load-balanced DNS name that routes connections across all available Aurora Replicas, but those replicas operate strictly in read-only mode. Any INSERT, UPDATE, or DELETE issued against this endpoint will be rejected with an error, causing the application to fail for write operations. Even if the application is configured for failover or retries, the reader endpoint will never accept writes, so it cannot be used as the sole database connection target.

Create a cross-Region read replica and configure the application to retry on failure

Why it fails: A cross-Region read replica is an Aurora Replica that asynchronously copies data from the primary cluster to another AWS Region, and it is always read-only. While you can manually promote it to a standalone primary cluster in a disaster recovery runbook, promotion is a deliberate action and does not happen automatically or transparently to the application. Simply adding retry logic to the application does not change the fact that the replica cannot accept writes, and the original cluster endpoint would still point to the failed writer unless you take extra steps to redirect traffic, so this option does not solve the high-availability requirement for write traffic.

Use Amazon RDS Proxy with IAM authentication to handle connection pooling

Why it fails: Amazon RDS Proxy is a fully managed connection pooling service that sits between the application and the database, and it supports IAM authentication for credentials management and rotation. However, RDS Proxy is not an alternative to using the cluster endpoint; it still must be configured to connect to a specific DB endpoint, and if you point it to the reader endpoint, write operations will still fail. Using RDS Proxy with IAM authentication alone does not address the need to target the current writer instance, so it is not the correct solution for ensuring successful writes during failover.