Target tracking scaling for ECS based on the SQS Queue Backlog (MessagesPerInstance) metric is a managed, purpose-built solution. It automatically calculates the required number of tasks based on a target value for the backlog per task, and adjusts more dynamically than simple step scaling with alarms. It handles scaling in and out smoothly and is more responsive to sudden changes than manually tuned alarm/step policies with cooldowns. While reducing cooldowns (D) can help, it risks over-scaling and is less optimal than the managed target tracking approach.

This follows AWS best practices and the principle of least privilege. By creating a dedicated IAM role for the pipeline with an inline policy, you scope permissions precisely to the GetSecretValue action for the specific secret ARN needed. The pipeline assumes this role only during the relevant stage. Option B is insecure (plaintext secrets). Option C is unnecessarily complex for Secrets Manager integration and doesn’t use the service’s native features. Option D grants overly broad permissions (ReadWrite) to all secrets, violating least privilege.

NACLs are stateless and evaluate traffic in both directions. While the outbound request from the instance (on a port like 443) might be allowed by the outbound NACL rules, the return traffic from the third-party API will come back on a random ephemeral port (e.g., 1024-65535). If the inbound NACL rules for the private subnet do not explicitly allow traffic on these ephemeral ports from the internet (0.0.0.0/0), the return packets will be dropped, causing a timeout. NAT Gateways do not have Security Groups (C), and the public subnet route table (B) is typically correct for a NAT Gateway to have a route to an Internet Gateway.

Blue/Green deployment is specifically designed for fast rollbacks. It involves two identical environments (Blue: current, Green: new). Traffic is routed all at once from Blue to Green after the new version is deployed and validated on Green. If issues are found, rolling back is instantaneous by simply re-routing traffic back to the stable Blue environment. This minimizes downtime and complexity. Canary (B) and Linear (D) deployments slowly shift traffic to the new version *in the same environment*, making rollback more complex and slower. In-place rolling (C) updates existing instances, making rollback a separate, time-consuming deployment process.

For Kinesis and DynamoDB Streams, Lambda’s Bisect Batch feature is the correct solution. When a batch fails, Lambda splits the batch into two, retrying each half. This process continues recursively, isolating the problematic record into a single-record batch. Combined with a `Maximum Retry Attempts` setting, Lambda will eventually either process the record successfully (with the new error handling) or, if it continues to fail, discard it (or send it to a destination) after the retries are exhausted, allowing the shard to progress. Manually restarting (D) or deleting records (C) is not scalable or recommended. Increasing resources (B) does not address the logical failure.

When an RDS instance with automated backups is deleted, its final automated snapshot is retained (unless explicitly skipped). The fastest and most direct restoration method is to create a new RDS instance directly from that final snapshot. This creates a new instance with all data up to the time the snapshot was taken. PITR (A) is for restoring *within* the backup retention period of an *existing* instance, not for a deleted one. AWS Backup (C) is overkill if RDS native backups exist. Option D is not a standard RDS feature for recovery after deletion.

Patch Manager uses the concept of **Patch Groups** to associate specific baselines with instances. The correct workflow is: 1) Create the patch baseline. 2) Register the baseline for a user-defined patch group name (e.g., “Production”) using `RegisterPatchBaselineForPatchGroup`. 3) Tag the EC2 instances with the key `Patch Group` and the value matching the registered name (e.g., `Patch Group=Production`). This is the documented, native method for scoping baselines. Resource groups (A) are not used for baseline association in this way. Baselines themselves cannot have tag filters (B). Maintenance Windows (D) are for scheduling, not for defining which baseline applies to an instance.

For AZ resilience within a region, Aurora Multi-AZ is the core database solution. It maintains a synchronous standby replica in a different AZ. During an AZ failure, Aurora automatically fails over to the standby, promoting it to the new writer, with minimal downtime. The **Writer Endpoint** is a CNAME that always points to the current writer instance, so the application does not need configuration changes after a failover. Combining this with an Auto Scaling group for the application tier across AZs completes the architecture. Option B uses a read replica, which is asynchronous and not for automatic failover. Option C incorrectly uses the Reader Endpoint for write traffic. Option D is for cross-region disaster recovery, which is more complex and not required for AZ resilience.

The AWS Instance Scheduler is a purpose-built, low-cost solution for this exact pattern. By tagging instances (e.g., `Schedule=dev-hours`) and defining a schedule in EventBridge, you can automatically stop instances outside of business hours, eliminating compute costs for those periods (you only pay for storage). This yields greater savings than right-sizing (B) or buying RIs (C) for 24/7 usage. While an Auto Scaling group (D) could work, it is more complex to set up for existing, stateful instances and is better suited for stateless, horizontally scalable workloads. The Instance Scheduler is simpler for managing on/off times of existing instances.

Target tracking scaling for ECS based on the SQS Queue Backlog (MessagesPerInstance) metric is a managed, purpose-built solution. It automatically calculates the required number of tasks based on a target value for the backlog per task, and adjusts more dynamically than simple step scaling with alarms. It handles scaling in and out smoothly and is more responsive to sudden changes than manually tuned alarm/step policies with cooldowns. While reducing cooldowns (D) can help, it risks over-scaling and is less optimal than the managed target tracking approach.0