Hard Difficulty Questions

Use a Lambda function in the pipeline to check the branch name and fail if not allowed.

Why wrong: The Lambda function can be modified by anyone with pipeline edit permissions.

Add a manual approval step in the pipeline and rely on the approver to verify the branch.

Why wrong: Manual approval does not prevent a developer from approving their own change.

Tag the source artifacts with the branch name and use a condition in CodePipeline to allow only specific tags.

Why wrong: CodePipeline does not support conditions on artifact tags.

The EC2 instances in the prod account do not have an appropriate instance profile.

Why wrong: The pipeline does not run on EC2 instances.

The cross-account role's permissions boundary denies the deploy action.

Why wrong: Permissions boundary affects what the role can do after assuming it, not the assumption itself.

The pipeline's service role does not have permission to perform the deploy action in the prod account.

Why wrong: The error occurs when assuming the role, not during the deploy action itself.

Configure the pipeline to block subsequent stages if any build action fails.

Why wrong: Blocking would affect other microservices.

Configure a single build action that sequentially builds all microservices.

Why wrong: Sequential builds would block if one fails.

The RDS instance does not have a resource-based policy that grants access to 'DatabaseAccessRole'.

Why wrong: B is wrong because the error is about assuming the role, not about the RDS policy.

The security group for the EC2 instance does not allow outbound traffic to the RDS instance.

Why wrong: D is wrong because the error is an IAM permission error, not a network connectivity error.

The EC2 instance does not have the correct IAM instance profile attached.

Why wrong: C is wrong because the log shows the instance role is assumed (the user ARN is from that role).

Store the credentials in AWS Secrets Manager and retrieve them at application startup.

Why wrong: Retrieving from Secrets Manager requires credentials to access Secrets Manager, leading to a chicken-and-egg problem.

Use AWS Systems Manager Parameter Store to store the credentials and retrieve them using the EC2 instance's IAM role.

Why wrong: The instance role can access Parameter Store, but the credentials themselves are not automatically rotated.

Generate an access key and secret key for an IAM user and store them in a configuration file on the EC2 instance.

Why wrong: Access keys are long-term credentials and storing them on disk is insecure.

Create a scheduled job that runs every 30 days to update the secret in Secrets Manager with a new password.

Why wrong: This is manual and does not handle automatic rotation of the database password.

Store the credentials in AWS Systems Manager Parameter Store and configure automatic rotation using a Lambda function.

Why wrong: Parameter Store does not natively support rotation for RDS credentials.

Use the AWS RDS automatic password rotation feature, which automatically updates the password every 30 days.

Why wrong: RDS does not have an automatic password rotation feature without Secrets Manager.

Store the secret ARN in a Terraform variable and use 'var.secret_arn' in the resource.

Why wrong: The ARN is not sensitive, but the secret value still needs retrieval; this does not address state exposure.

Store the secret in AWS Systems Manager Parameter Store and reference it using 'data.aws_ssm_parameter'.

Why wrong: While this retrieves the secret, it can still appear in state if not handled properly; also, Secrets Manager is already in use.

Pass the secret as an environment variable to Terraform and reference it with 'var.secret_value'.

Why wrong: Environment variables can be captured in state if used in resources, leading to exposure.

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: Active-Active adds complexity; ElastiCache Global Datastore supports cross-region replication but not multi-region writes natively.

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: Manual scaling and promotion steps may exceed 30 minutes RTO.

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: Snapshot restore can take longer than 30 minutes and RPO may be up to 24 hours.

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

Why wrong: NodePort does not improve resilience; the underlying pod distribution remains unchanged.

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

Why wrong: More replicas on one node still fail if that node fails.

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

Why wrong: Autoscaling does not prevent downtime during a node failure; it only adds capacity based on metrics.

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

Why wrong: Without sticky sessions, subsequent requests may go to different instances, breaking session state.

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

Why wrong: This requires application changes to use ElastiCache, which is not minimal.

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

Why wrong: This requires application changes to use RDS for sessions, which is not minimal.

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

Why wrong: EFS replication is asynchronous and may not meet RPO of 1 second; it is also not for databases.

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

Why wrong: Auto Scaling groups are regional resources; you cannot span regions.

The X-Ray SDK cannot send traces to AWS X-Ray from Fargate tasks.

Why wrong: The X-Ray SDK sends traces to the daemon, which forwards them; the SDK does not directly call the X-Ray API.

ServiceLens does not support Amazon ECS with Fargate launch type.

Why wrong: ServiceLens supports ECS Fargate when properly configured.

The application is not sending metrics to CloudWatch Container Insights.

Why wrong: Missing metrics do not prevent traces from appearing in ServiceLens.

AWS CodeDeploy for deploying the SAM application.

Why wrong: SAM applications are deployed via CloudFormation, not CodeDeploy.

AWS CodeCommit to build the SAM application.

Why wrong: CodeCommit is a source control service, not a build service.

Check the Amazon Route 53 health checks for the ALB DNS name.

Why wrong: Route 53 health checks are for DNS resolution, not ALB target health.

Review the EC2 instances' CloudWatch metrics for CPU utilization and network traffic.

Why wrong: These metrics may show resource constraints but not directly the cause of 503 errors.

Inspect AWS CloudTrail logs for the ALB to see if there are any configuration changes.

Why wrong: CloudTrail logs API calls, not HTTP requests or target health.

The subnet ID in the template is already used by another stack in the same account.

Why wrong: The error is an authorization failure, not a conflict.

The subnet specified in the template does not exist in the selected AWS region.

Why wrong: The error is about authorization, not existence.

The CloudFormation template has a syntax error in the subnet definition.

Why wrong: The template was successfully used before, so syntax is likely fine.

The GPG key is not registered with the IAM user's profile.

Why wrong: While GPG key must be associated with the IAM user, the issue is that CodeCommit doesn't support pre-receive hooks.

The hook script has a syntax error.

Why wrong: Even if the script is correct, CodeCommit does not execute pre-receive hooks.

The repository is not configured to require signed commits.

Why wrong: CodeCommit does not have a built-in setting to require signed commits; the hook is the intended mechanism, but it's not supported.

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

Why wrong: Custom resolution adds complexity; global tables already have built-in LWW.

Switch to eventual consistency reads to reduce conflicts.

Why wrong: Eventual consistency does not resolve conflicts; it only relaxes read freshness.

Add a third global table region to increase redundancy.

Why wrong: Adding more regions does not resolve conflicts; it may introduce more.

Use eventually consistent reads for all queries.

Why wrong: Eventual consistency does not reduce throttling; it only reduces read costs.

Move the data to Amazon RDS with read replicas.

Why wrong: This is a significant architectural change and not necessary for solving throttling.

Switch DynamoDB to On-Demand capacity mode.

Why wrong: On-Demand mode can handle spikes but is more expensive; it may not be cost-effective.

Use JSON format for logs instead of plain text.

Why wrong: Incorrect: Format does not significantly affect CPU.

Set the agent's timezone to UTC.

Why wrong: Incorrect: Timezone setting does not affect CPU.

Change the log group retention policy to 7 days.

Why wrong: Incorrect: Retention does not affect agent CPU usage.

Replicate the canaries to US East (N. Virginia) and run them from there.

Why wrong: Incorrect: This changes the monitoring perspective and adds latency.

Set up a Lambda function in each region to push canary results to a central S3 bucket, then create a dashboard from S3.

Why wrong: Incorrect: This adds unnecessary complexity and cost.

Create a CloudWatch Logs Insights query across all regions and visualize results.

Why wrong: Incorrect: CloudWatch Logs Insights does not directly support dashboards.