Design Resilient Architectures practice questions

Implement a lifecycle hook that places launching instances into a pending state, and manually resume instances after checking their log files.

Why it fails: Manual intervention via lifecycle hooks defeats the purpose of fully automated scaling during unpredictable traffic spikes. Administrative delays in resuming instances would lead to poor user experience and slow system response times during critical traffic surges.

Set the termination policy to OldestInstance and configure a health check grace period that matches the average application startup time.

Why it fails: The health check grace period instructs the Auto Scaling group to ignore health check results from newly launched instances for a specified duration, giving resource-intensive applications enough time to complete initialization without being terminated prematurely.

Change the health check type from ELB to EC2, and rely solely on underlying hypervisor status checks to determine instance health.

Why it fails: Relying only on EC2 status checks means the Auto Scaling group will not detect software-level failures, hung application servers, or broken web service endpoints that are still running at the hypervisor level, significantly degrading application availability.

Increase the desired capacity of the Auto Scaling group and configure target tracking scaling policies based on CPU utilization metrics.

Why it fails: Increasing desired capacity and adding target tracking policies controls scaling out based on load, but it does not address the core issue of instances failing ELB health checks prematurely during their resource-intensive initialization phase.

The `aws:SourceVpce` condition key is only supported on AWS IAM user policies and cannot be evaluated within Amazon S3 resource-based bucket policies.

Why it fails: The `aws:SourceVpce` condition key is fully supported in Amazon S3 bucket policies to restrict access to specific VPC endpoints, making it a standard and valid mechanism for securing data access paths.

Requests originating from within the authorized VPC endpoint also require a matching `aws:SourceVpc` condition key to validate the parent Virtual Private Cloud.

Why it fails: Validating `aws:SourceVpc` alongside `aws:SourceVpce` is redundant because a VPC endpoint uniquely belongs to a single VPC, and adding it would not resolve the evaluation failures caused by missing service context.

Certain AWS service actions and management operations do not carry the VPC endpoint context, causing the `StringNotEquals` check to evaluate as true and trigger the Deny rule.

Why it fails: Management actions and internal service calls hitting S3 do not always include the VPC endpoint identifier, causing the negative condition to match and resulting in an unintended blanket denial of essential operations.

Amazon RDS for PostgreSQL with Provisioned IOPS.

Why it fails: Standard Amazon RDS instances require you to select a specific instance size and provisioned storage. They do not automatically shut down when not in use, and scaling typically involves downtime or manual intervention to change instance classes. This leads to higher costs and more management effort for unpredictable, intermittent traffic patterns.

Amazon DynamoDB with Provisioned Capacity.

Why it fails: While DynamoDB is serverless, Provisioned Capacity requires you to specify the number of reads and writes per second. If traffic is unpredictable, you may either over-provision and waste money or under-provision and experience throttling. While DynamoDB On-Demand exists, it is a NoSQL solution and may not fit if a relational database is required.

Amazon Redshift Spectrum.

Why it fails: Amazon Redshift Spectrum is a feature of Redshift used for running queries against large amounts of unstructured data in Amazon S3. It is a data warehousing tool designed for analytical workloads rather than serving as a transactional database for a web application. It does not offer the auto-scaling and pause features required.

An Internet Gateway attached to the VPC.

Why it fails: While an Internet Gateway is required for the VPC to communicate with the internet, it is the NAT Gateway that allows private instances to initiate outbound traffic without being exposed to inbound connections. The Internet Gateway alone does not provide the NAT translation required for instances in private subnets to reach the internet.

An Egress-Only Internet Gateway.

Why it fails: Egress-Only Internet Gateways are specifically used for IPv6 traffic to allow outbound communication while blocking inbound connections. If the application is using IPv4, which is common for legacy and many modern systems, an Egress-Only IGW will not work. NAT Gateways are the correct choice for providing outbound-only access for IPv4 traffic.

A Customer Gateway for VPN connectivity.

Why it fails: A Customer Gateway is a physical or software appliance on the on-premises side of a Site-to-Site VPN connection. It is used for connecting an on-premises network to an AWS VPC, not for providing outbound internet access to instances within the VPC. This component is unrelated to the requirement of resilient internet access.

It allows all requests as long as they are encrypted at rest.

Why it fails: The policy does not mention encryption at rest, which would be handled by keys like 's3:x-amz-server-side-encryption'. 'aws:SecureTransport' refers specifically to the encryption of the communication channel (encryption in transit). A request could have encryption at rest enabled but still be sent over an insecure HTTP channel, which this policy would deny.

It prevents users from deleting objects unless they use MFA.

Why it fails: To require MFA for deletions, the policy would need to use the 'aws:MultiFactorAuthPresent' condition key. This policy only evaluates the transport protocol used for the request. It applies to all actions ('s3:*'), not just deletions, and does not interact with the multi-factor authentication status of the user making the request.

It restricts access to the bucket to only internal AWS services.

Why it fails: Restricting access to internal services would typically involve 'aws:SourceVpc' or 'aws:PrincipalArn' conditions. This policy applies to all principals ('*') regardless of whether they are internal or external. As long as the principal uses HTTPS, the 'Deny' statement will not be triggered, allowing the request if other permissions are in place.

Instance i-333 because it has the earliest launch time overall.

Why it fails: Although i-333 is the oldest instance across the entire ASG, the first step in the termination process is always to balance the Availability Zones. Since 'us-east-1b' only has one instance and 'us-east-1a' has two, the ASG must terminate an instance from 'us-east-1a' first to keep the application distributed evenly across the zones.

Instance i-222 because the 'Default' policy is evaluated first.

Why it fails: Termination policies are evaluated in the order they are listed in the configuration. 'OldestInstance' is listed before 'Default', so it will be the primary logic used after the AZ balance is determined. Even if 'Default' were used, it also prioritizes AZ balance first, but would look for instances closest to the next billing hour rather than the oldest.

The ASG will randomly select an instance to terminate.

Why it fails: Auto Scaling does not terminate instances randomly. It follows a very specific, deterministic set of rules to ensure high availability and cost-efficiency. Random selection would risk unbalancing the Availability Zones or terminating instances that are critical for specific workloads, which goes against the goal of maintaining a resilient and predictable architecture.

Use a single large instance in each AZ instead of multiple small ones.

Why it fails: Using fewer, larger instances reduces the granularity of scaling and increases the impact of a single instance failure. Smaller, more numerous instances are better for resilience because they allow the load to be distributed more effectively and ensure that the loss of one instance has a minor impact.

Configure the ALB to ignore unhealthy instances in the isolated AZ.

Why it fails: The ALB does this automatically via health checks. The concern for the architect is not the ALB's behavior, but ensuring that the Auto Scaling group replaces the lost capacity to maintain the application's overall performance target after the failure occurs, which requires proper capacity planning beyond ALB settings.

Switch to a single-AZ deployment with a standby instance in another region.

Why it fails: Switching to a single-AZ deployment creates a single point of failure within the region, which is the opposite of the desired resiliency. Relying on a cross-region standby adds significant complexity and latency, failing to address the local availability requirements for the application during a zone-specific network isolation.

Amazon EC2.

Why it fails: EC2 instances are Zonal resources. A single instance does not provide high availability by itself. To achieve high availability, the architect must manually deploy instances across multiple AZs and place them behind a load balancer. It is not inherently highly available without explicit user-defined architectural configuration.

Amazon EBS.

Why it fails: EBS volumes are restricted to a single Availability Zone. They are not highly available by default. To make data on an EBS volume highly available, users must implement manual snapshots and copy them to other AZs or use file-level replication, as the volume itself remains bound to its original AZ.

Migrate the PostgreSQL database to an Amazon DynamoDB global table with strongly consistent reads.

Why it fails: Migrating a relational financial ledger requiring complex joins and transactions to DynamoDB requires massive application rewrites. DynamoDB is a NoSQL database and does not natively support relational foreign keys or complex ACID transactions without careful schema design.

Configure Amazon Route 53 DNS failover with a very short TTL pointing directly to the RDS read replica endpoint.

Why it fails: Using Route 53 DNS failover for RDS does not work well because RDS read replicas are asynchronous and read-only. Promoting a read replica requires manual or automated promotion logic, and short TTLs do not solve immediate connection pooling failures.

Place instances in a single Auto Scaling group with a minimum size of zero.

Why it fails: A minimum size of zero risks application downtime if the scaling policy fails to trigger or if instance launches are delayed during an outage. Setting a minimum size greater than zero across multiple Availability Zones is critical for maintaining consistent capacity and ensuring the application remains responsive during sudden traffic increases.

Use a Network Load Balancer with static IP addresses in each zone.

Why it fails: While a Network Load Balancer provides low latency and high throughput, it does not provide the advanced layer 7 routing features inherent to an ALB. For web-based applications, the ALB is preferred for its ability to route based on path and host headers, which is essential for modern, resilient microservices architectures.

Configure Route 53 with a latency-based routing policy to the ALB.

Why it fails: Latency-based routing directs users to the region with the lowest latency but does not inherently manage load distribution across Availability Zones within a single region. Managing cross-zone traffic is a function of the load balancer configuration, and relying solely on DNS-level routing does not provide the same granularity as load balancer integration.

The policy is missing the s3:ListBucket permission.

Why it fails: Many AWS SDKs and CLI tools perform a 'ListBucket' call to verify the destination exists before executing a 'PutObject' request. Without this permission, the application may fail to initiate the upload process entirely, leading to service disruption even though the actual write action is explicitly allowed in the policy document.

The policy is missing a Deny statement to prevent unauthorized access.

Why it fails: An explicit Deny is not required for a policy to function unless there is a conflicting Allow statement elsewhere. IAM policies are additive by default, and a simple Allow statement is sufficient to grant access. The absence of a Deny statement does not cause an Allow statement to be ignored.

The action s3:PutObject is not supported for S3 buckets.

Why it fails: The 's3:PutObject' action is a standard and widely used S3 permission for uploading files to a bucket. It is fully supported by the S3 API and is the correct action to use when defining policies for write operations. Therefore, the action itself is not the source of the configuration error.

Enable RAID 0 across multiple EBS volumes.

Why it fails: RAID 0 improves performance by striping data across volumes, but it actually decreases resilience. If any single volume in a RAID 0 array fails, the entire data set is lost. This is the opposite of a resilient architecture and does not provide protection against Availability Zone failures at the data layer.

Use Amazon EFS instead of EBS for all applications.

Why it fails: Amazon EFS is designed for shared file storage, not as a direct replacement for block-level storage performance required by many databases and applications. While EFS is multi-AZ, suggesting it for all applications ignores the specific performance and compatibility requirements that EBS fulfills, making it an inappropriate blanket recommendation for resilience.

Attach a single EBS volume to multiple EC2 instances.

Why it fails: Standard EBS volumes cannot be attached to multiple EC2 instances simultaneously (except for Multi-Attach on specific io1/io2 volumes). Regardless, attaching a volume to multiple instances does not protect against AZ failure, as the volume remains in the same zone. This does not address the fundamental need for cross-zone data availability.

Implement a local database to store messages before queuing.

Why it fails: Introducing a local database for message storage creates a new, unmanaged single point of failure. It adds unnecessary complexity and management overhead. SQS is already designed for high durability and availability, so building a custom queuing layer on top of a database is less resilient and less efficient than using native SQS features.

Use an in-memory Redis cluster for message storage.

Why it fails: While Redis is fast, in-memory storage is not inherently persistent unless configured with complex persistence settings. Using an in-memory cluster for message queueing is less resilient than using a purpose-built, managed service like SQS, which is specifically designed for message durability and is highly available without the manual management required for Redis.

Only process messages during off-peak hours.

Why it fails: Restricting message processing to off-peak hours does not address the need for resilience. If the queue service were to fail, limiting processing time would not protect the data. The application needs to handle messages as they arrive, and the underlying infrastructure must be resilient enough to support continuous operation without relying on manual scheduling.

Enable S3 Transfer Acceleration on the bucket.

Why it fails: S3 Transfer Acceleration uses AWS edge locations to speed up uploads to S3, reducing latency for clients uploading content. This is beneficial for applications where users upload assets that must be served globally. It improves the efficiency of data movement and contributes to a more resilient architecture by optimizing the ingestion of static content.

Host static files on the same EC2 instance as the application.

Why it fails: Hosting static files on the same EC2 instance as the application code creates a bottleneck and couples the performance of the assets with the compute resources. If the application server fails, the static assets become unavailable. This is an inefficient and non-resilient design, especially compared to using S3 and CloudFront.

Use an RDS database to store all static image files.

Why it fails: Storing image files in a database is an anti-pattern. Databases are designed for structured data and are inefficient at storing large binary objects like images. This approach leads to poor performance, increased database costs, and significantly reduced scalability, and does not improve the resilience or performance of static asset delivery.

Configure the bucket for S3 Cross-Region Replication.

Why it fails: Cross-Region Replication improves availability and satisfies disaster recovery requirements by copying data to a different geography. However, it does not natively prevent accidental deletion in the source bucket; the deletion marker is also replicated, which can lead to data loss in both locations.

Use S3 Object Lock in compliance mode for all objects.

Why it fails: Object Lock in compliance mode prevents any user from deleting objects for a specified retention period. While this protects against deletion, it is an extreme measure that may interfere with legitimate backup rotation policies. It is a governance tool rather than a standard availability feature.

Apply a bucket policy that denies s3:DeleteObject to all IAM users.

Why it fails: Denying delete permissions globally prevents any user, including administrators, from managing the bucket. This lacks the flexibility required for maintenance, such as clearing old backups. Versioning and MFA provide a more manageable and granular approach to protecting data while still allowing necessary administrative tasks.

Configure an Application Load Balancer in a single Region with EC2 instances distributed across multiple Availability Zones, and back the application with a standard Aurora MySQL database instance.

Why it fails: A single Region architecture creates a single point of failure if the entire AWS Region suffers an outage. Standard Aurora databases lack cross-region replication capabilities required for high availability across geographical boundaries during catastrophic regional failures.

Use Amazon Route 53 with weighted routing policies to distribute traffic between two AWS Regions, and configure standard cross-region database replication using Amazon RDS snapshots taken every hour.

Why it fails: Weighted routing does not perform automated health checks to reroute traffic away from a failed Region instantly. Hourly RDS snapshots introduce a high RPO and manual intervention is required to restore databases, which violates critical resiliency requirements.

Set up an AWS Global Accelerator standard accelerator with endpoint groups in two AWS Regions, and use Amazon DynamoDB global tables with local secondary indexes for data storage.

Why it fails: While AWS Global Accelerator and DynamoDB global tables offer high availability, the scenario specifies an Amazon Aurora relational database tier rather than DynamoDB, making this architecture incompatible with the existing relational database requirements of the application.

Configure Amazon S3 Intelligent-Tiering to automatically move infrequently accessed video assets to lower-cost storage tiers.

Why it fails: S3 Intelligent-Tiering optimizes storage costs by moving objects between access tiers based on access patterns, but it does not provide data protection mechanisms against accidental deletion, malicious overwrites, or complete regional service interruptions.

Attach a resource-based bucket policy that explicitly denies all delete object requests from any IAM user except the root account.

Why it fails: Denying delete requests via bucket policy prevents standard data maintenance and lifecycle operations, and relying solely on root account privileges violates AWS security best practices regarding least privilege access control for daily operational tasks.

Enable S3 Object Lock in governance mode with a fixed retention period of 30 days for all uploaded video files.

Why it fails: S3 Object Lock governance mode prevents users from changing or deleting object versions, but it can be bypassed by users with specific administrative permissions unless compliance mode is used, and it does not provide multi-region disaster recovery capabilities.

Configure the Application Load Balancer to use source IP stickiness.

Why it fails: Source IP stickiness ties a client to a specific backend instance. If that instance fails or the Auto Scaling group terminates it, the session state is lost. This approach creates a dependency on individual instance health, violating the principle of designing stateless, resilient application tiers.

Use Amazon EBS multi-attach to share session files across instances.

Why it fails: EBS volumes can only be attached to instances within the same Availability Zone. If the AZ fails, the data becomes inaccessible, creating a single point of failure. Furthermore, file-based locking mechanisms are inefficient and prone to corruption in high-concurrency environments compared to dedicated caching services.

Replicate session files using a cron job across all web instances.

Why it fails: Replicating files via cron jobs introduces significant latency and synchronization challenges. As the number of instances grows, the overhead of maintaining consistency becomes unmanageable and error-prone. This design lacks the robustness and sub-millisecond performance required for modern, scalable, and resilient cloud-native web applications.

Configure RDS Read Replicas and manually promote them during an outage.

Why it fails: Read Replicas are designed for scaling read traffic rather than providing high availability. Promoting a replica manually requires human intervention and configuration changes, which increases the recovery time objective. Additionally, because replication is asynchronous, there is a risk of data loss if the primary instance fails before data is synchronized to the replica.

Deploy a Single-AZ RDS instance and use AWS Backup for hourly snapshots.

Why it fails: Single-AZ deployments are susceptible to outages if the specific Availability Zone fails. While snapshots provide a way to restore data, the restoration process is manual and time-consuming, leading to high downtime. This approach does not meet the requirement for automatic failover and high availability during maintenance or infrastructure failures.

Host a MySQL database on an Amazon EC2 instance with an EBS volume.

Why it fails: Running a database on a single EC2 instance introduces a single point of failure. Achieving high availability would require the architect to manually configure complex clustering software, replication, and failover scripts. This approach represents a high operational burden and does not leverage the managed high availability features provided by Amazon RDS.

Simple routing policy.

Why it fails: Simple routing is designed for a single resource that performs a specific function for your domain. It does not support health checks or complex logic like latency-based steering. Using simple routing would not allow the application to automatically fail over to a different region if the primary infrastructure becomes unavailable or performance degrades.

Failover routing policy.

Why it fails: Failover routing is used specifically for active-passive configurations where you want all traffic to go to a primary site and only switch to a secondary site if the primary fails. While it handles resilience, it does not account for user latency, which was a specific requirement for the global performance of the application.

Weighted routing policy.

Why it fails: Weighted routing distributes traffic across multiple resources in proportions that you specify. While it can be used for load balancing or blue/green deployments, it does not automatically route based on network latency. It would require manual adjustments or complex external automation to achieve the performance goals of directing users to the closest healthy region.