Technology practice questions

Increase the cooldown period for the dynamic scaling policy.

Why wrong: Increasing cooldown delays scaling actions, making it worse.

Decrease the cooldown period for the dynamic scaling policy.

Why wrong: Decreasing cooldown helps react faster but does not proactively prepare for the spike.

Disable scale-in to prevent the Auto Scaling group from terminating instances during the sale.

Why wrong: Disabling scale-in does not help with scaling out more quickly.

The NLB does not support source IP stickiness; use a Classic Load Balancer instead.

Why wrong: NLB does support source IP stickiness for TCP listeners.

The NLB has cross-zone load balancing enabled, which distributes traffic across instances in different Availability Zones.

Why wrong: Cross-zone load balancing does not affect stickiness based on source IP.

The idle timeout of the NLB is too low, causing the NLB to close connections prematurely.

Why wrong: Idle timeout would terminate the connection, not route to a different instance.

A single-AZ deployment with cross-Region automated backups.

Why wrong: Cross-Region backups have higher RPO and RTO.

A single-AZ deployment with a standby instance manually promoted.

Why wrong: Manual promotion would exceed the 1-minute RTO.

A Multi-AZ deployment with a Read Replica in a different Region.

Why wrong: Read Replicas are not used for automatic failover.

Set a stack policy that allows updates to RDS resources only.

Why wrong: Stack policies are applied per resource, not per service.

Set a stack policy that denies all updates.

Why wrong: This would block the intended update.

Set a stack policy that allows all updates.

Why wrong: This would allow updates to any resource, not just the RDS instance.

Use a step scaling policy instead of a simple scaling policy.

Why wrong: Step scaling does not affect session preservation.

Increase the cooldown period for the Auto Scaling group.

Why wrong: Cooldown delays scaling but does not preserve sessions.

Use a launch configuration that enables termination protection.

Why wrong: Termination protection prevents termination but does not help preserve sessions when scale-in is needed.

Attach an Internet Gateway to the VPC and configure route tables for the private subnets.

Why wrong: An Internet Gateway provides internet access, not needed for internal communication.

Place the Fargate tasks in public subnets to allow them to communicate with each other through the internet gateway.

Why wrong: Public subnets and internet gateway expose services to the internet.

Use AWS Cloud Map for service discovery and register a public DNS name for each service.

Why wrong: Public DNS would make services accessible from the internet.

Disable auto scaling and set a fixed provisioned capacity to avoid cost spikes.

Why wrong: Fixed capacity may lead to throttling or over-provisioning.

Increase the write capacity units to handle peak loads and reduce latency.

Why wrong: Increasing write capacity increases cost; it's not an optimization.

The policy does not allow the s3:PutObject action.

Why wrong: The policy explicitly allows s3:PutObject.

The resource ARN is incorrect; it should be arn:aws:s3:::my-bucket without the asterisk.

Why wrong: The ARN with asterisk matches all objects in the bucket.

The policy is missing a Deny statement for other IP addresses.

Why wrong: A Deny statement is not required; the Allow statement is conditioned on the IP.

Restart the web server instances to reset the database connection.

Why wrong: Restarting does not fix the root cause of the database connection timeout.

Modify the application's health check endpoint to return a 200 OK status even when the database is unavailable.

Why wrong: Masking the failure would cause traffic to be sent to unhealthy instances.

Increase the health check interval to allow more time for the database to respond.

Why wrong: Increasing the interval does not fix the underlying database connectivity issue.

Configure slow start on the target group

Why wrong: Slow start ramps up traffic to new instances gradually, but does not affect the distribution of existing traffic across instances.

Increase the deregistration delay on the target group

Why wrong: Deregistration delay controls how long in-flight requests are allowed to complete before an instance is deregistered. It does not affect traffic distribution.

Enable sticky sessions (session affinity) on the target group

Why wrong: Stickiness ties a user's session to a specific instance, which can actually cause uneven load if one instance gets more sticky sessions. It does not help balance distribution.

Configure the ECS task definition to assign a public IP address to the tasks and ensure the tasks have a route to the internet via a NAT gateway

Why wrong: Assigning public IPs and using a NAT gateway is unnecessary for private subnet communication within the same VPC and could introduce security risks.

Place both the ECS tasks and the RDS instance in the same public subnet to ensure network connectivity

Why wrong: Placing resources in public subnets is not a best practice and may not be allowed due to security policies. Also, the issue is likely not about public vs private.

Modify the RDS security group inbound rule to allow traffic from the CIDR block of the ECS tasks’ private subnets instead of the security group ID

Why wrong: While this would work, it is less secure than using security group references and is not the best practice. The existing rule using the security group ID should already work if properly configured.

Classic Load Balancer for both tiers

Why wrong: Classic Load Balancer is legacy and does not support advanced features like path-based routing or target group health checks required for modern architectures.

Network Load Balancer for the web tier and Application Load Balancer for the application tier

Why wrong: NLB is not ideal for HTTP/HTTPS traffic because it does not support path-based routing or HTTP header inspection. ALB is better for the web tier.

Amazon API Gateway for the web tier and Application Load Balancer for the application tier

Why wrong: API Gateway is designed for API endpoints, not for serving web pages. It is not a replacement for a load balancer in a web tier.

Migrate the database to Amazon Aurora with PostgreSQL compatibility using the AWS Database Migration Service (DMS)

Why wrong: Aurora PostgreSQL is a different database engine; stored procedures may need to be rewritten, increasing code changes.

Store the data in Amazon S3 and use Athena for querying

Why wrong: S3 and Athena are suitable for analytics, not for transactional OLTP workloads with stored procedures.

Refactor the application to use Amazon DynamoDB as the database

Why wrong: DynamoDB is NoSQL and requires significant application changes, which contradicts the requirement to minimize code changes.

Change the scaling policy to a simple scaling policy instead of dynamic scaling

Why wrong: Simple scaling does not prevent session loss; the core issue is that session state is stored in memory on the instance.

Enable sticky sessions (session affinity) on the Application Load Balancer

Why wrong: Stickiness routes users to the same instance, but if that instance is terminated due to scaling in, the session is still lost.

Increase the cooldown period for the Auto Scaling group

Why wrong: Cooldown period only affects when new scaling activities can start; it does not preserve session data.

Use Amazon EBS snapshots of the EC2 instances and copy them to the secondary Region every minute

Why wrong: EBS snapshots are not designed for minute-level frequency and cannot achieve an RPO of 1 minute.

Migrate the database to Amazon Aurora MySQL and configure an Aurora Global Database

Why wrong: Aurora Global Database is a different service; the company uses RDS MySQL, and migrating would be more complex.

Enable cross-Region automated backups for the RDS Multi-AZ DB instance

Why wrong: Automated backups are for point-in-time recovery, not for low RPO replication; they are typically scheduled every 5 minutes.

Set the Lambda function timeout to the maximum value of 15 minutes

Why wrong: Increasing timeout does not help with scaling; it only allows functions to run longer. It may even lead to higher costs.

Configure DynamoDB auto scaling with a minimum capacity of 10 read and 10 write capacity units

Why wrong: Auto scaling adjusts capacity based on utilization but can lag behind sudden spikes. On-demand is better for unpredictable traffic.

Implement ElastiCache Redis cluster to cache query results and reduce DB load.

Why wrong: Caching adds complexity and cost; for this scenario, a read replica directly addresses the DB CPU spike.

Enable RDS Performance Insights and create a CloudWatch alarm to reboot the DB instance on high CPU.

Why wrong: Rebooting does not resolve the root cause of high CPU and causes downtime.

Switch the DB instance to a larger instance type to handle the load.

Why wrong: Scaling up increases cost; the workload is read-heavy, so a read replica is more cost-effective.

Use AWS Config rules to detect noncompliant buckets and send notifications.

Why wrong: This is detective, not preventive; buckets can still be created without encryption.

Create an IAM policy in each account that denies s3:PutBucketEncryption unless the correct KMS key is specified.

Why wrong: IAM policies are per-account and do not prevent root user actions or actions by other services.

Use AWS CloudFormation StackSets to deploy a template that creates all buckets with the required encryption.

Why wrong: This does not prevent users from creating buckets outside of CloudFormation.

Amazon S3 Transfer Acceleration to upload the database dump, then restore to RDS.

Why wrong: This requires taking the source offline to create a dump, causing downtime.

AWS Storage Gateway to replicate the database files to Amazon S3, then restore to RDS.

Why wrong: Storage Gateway is not designed for database migration; it replicates files, not database transactions.

AWS Snowball Edge to ship the data physically, then import to RDS.

Why wrong: Snowball is for large data volumes over slow networks, but it does not support ongoing replication and adds latency.

In the EC2 security group, allow inbound HTTPS traffic from 0.0.0.0/0.

Why wrong: This would allow any source to access the instances via HTTPS, violating the requirement that only the ALB can access them.

Enable encryption at rest on the EC2 instances using EBS encryption.

Why wrong: This encrypts data at rest, not in transit between ALB and EC2.

Configure the ALB with an HTTPS listener and upload the SSL/TLS certificate.

Why wrong: This encrypts client-to-ALB traffic but not necessarily ALB-to-EC2; the target group protocol must also be HTTPS.