Incident and Event Response practice questions

Check the SNS topic that the scaling policy publishes to for notifications.

Why wrong: SNS notifications only indicate that scaling occurred, not why.

Use AWS CloudTrail to review API calls that modified the scaling policy.

Why wrong: CloudTrail logs API calls but does not show application-level metrics or deployment issues.

Temporarily disable the scaling policy and manually increase the desired capacity to handle the load.

Why wrong: This is a reactive fix that does not help determine the root cause of the spike.

Increase the task definition CPU to 1024 units and memory to 2048 MiB.

Why wrong: More CPU is unnecessary if the issue is memory, and cost increases more.

Configure the ECS service to use a rolling update with a longer health check grace period.

Why wrong: This does not fix the underlying memory issue.

Decrease the task definition memory to 512 MiB to force garbage collection more frequently.

Why wrong: Reducing memory would likely increase OutOfMemoryErrors.

Review the CloudWatch metrics for CPU utilization and network throughput.

Why wrong: Metrics may not show the cause of unreachability if instance is healthy.

Reboot the instance to reset the network interface.

Why wrong: Rebooting is unnecessary if the instance is running and healthy.

Stop and start the instance to move it to new underlying hardware.

Why wrong: Stopping/starting is invasive and not first step.

Modify the S3 bucket event notification configuration to use a prefix filter that excludes duplicate objects.

Why wrong: Prefix filters do not prevent duplicate event delivery.

Set the Lambda function's ReservedConcurrency to 1 to prevent concurrent executions.

Why wrong: This limits concurrency but does not prevent duplicate invocations for the same object.

Use an Amazon SQS FIFO queue as the event source and enable content-based deduplication.

Why wrong: SQS FIFO can deduplicate messages but S3 events are delivered directly to Lambda, not SQS.

Create a new stack from the same template and migrate resources.

Why wrong: This is complex and may not be necessary.

Manually correct the resource configuration that caused the failure, then perform a stack update.

Why wrong: Manual changes outside CloudFormation are not recommended.

Delete the stack and then recreate it from the same template.

Why wrong: Deleting the stack might fail or cause data loss.

The security group for the RDS instance has changed during failover.

Why wrong: Security groups remain the same.

The DNS record for the RDS endpoint has not propagated to the application's DNS resolver.

Why wrong: RDS DNS updates quickly and is not usually the issue.

The database instance is still in the process of failover and is not yet accepting connections.

Why wrong: The status is Available, so failover is complete.

Check the ALB target group health check settings and ensure instances are healthy.

Why wrong: ALB logs show 200, so targets are responding.

Examine the request headers in CloudFront logs to identify unusual patterns.

Why wrong: Request headers are unlikely to cause 504 errors.

Review the CloudFront cache hit ratio and optimize caching strategies.

Why wrong: Cache hit ratio does not cause 504 errors.

Create a CloudWatch alarm on the SecurityGroupEvent metric to notify the security team.

Why wrong: Alarms only notify, they do not revoke changes.

Apply a Service Control Policy (SCP) that denies changes to security groups in the production account.

Why wrong: SCPs cannot block specific rule modifications; they apply to the entire account.

Set up a CloudTrail trail that logs security group modifications and use Amazon Detective to analyze the changes.

Why wrong: This is detective, not corrective.

Enable AWS Shield Advanced on the ALB for additional DDoS protection.

Why wrong: Shield Advanced requires subscription and is not an immediate action.

Scale up the EC2 instances by increasing their instance size.

Why wrong: Scaling up may not mitigate the attack and could increase costs.

Place an Amazon CloudFront distribution in front of the ALB to cache content.

Why wrong: CloudFront can help but not a quick fix; it also requires DNS changes.

Increase the read and write capacity units manually before the sale.

Why wrong: Manual adjustment is not dynamic and may over-provision.

Switch from on-demand to provisioned capacity with auto scaling.

Why wrong: On-demand is better for unpredictable spikes; provisioned may throttle.

Enable DynamoDB Streams and replicate data to a read replica.

Why wrong: DynamoDB does not have read replicas; streams are for change capture.

Create a read replica and promote it to primary.

Why wrong: This does not increase storage on the original instance.

Delete old automated snapshots to free up storage.

Why wrong: Automated snapshots do not consume the instance's allocated storage.

Scale up the DB instance to a larger instance class.

Why wrong: Instance class does not affect storage.

The EC2 instances are running out of memory and the application is crashing.

Why wrong: Health check would likely fail if the application is crashing.

The ALB is misconfigured and routing requests to the wrong target group.

Why wrong: ALB misconfiguration would affect health checks too.

The EC2 instances are not passing health checks and are being deregistered from the target group.

Why wrong: Health checks return 200, so instances are healthy.

The role does not have permission to describe instances, so the condition cannot be evaluated.

Why wrong: DescribeInstances works, so the condition is evaluated.

The policy's Resource element is set to '*' and must be restricted to specific instance ARNs.

Why wrong: Resource '*' is acceptable for these actions.

The policy does not include the ec2:RebootInstances action.

Why wrong: Missing actions are not the issue; the allowed actions fail.

The scaling policy is not properly configured; recreate it with a lower target value.

Why wrong: The policy is configured and the metric is above target, but scaling is blocked by the max.

The CloudWatch metric is not being emitted correctly; check the metric namespace.

Why wrong: The metric is showing, so it is being emitted.

The ECS service is using Fargate, which does not support target tracking scaling policies.

Why wrong: Fargate supports target tracking scaling policies.

Use Amazon GuardDuty to automatically modify the security group membership of the instance.

Why wrong: GuardDuty detects threats but does not perform remediation; it can trigger EventBridge to invoke a Lambda, but the option does not mention that.

Use AWS Shield Advanced to automatically apply the quarantine security group to the instance.

Why wrong: Shield Advanced provides DDoS protection, not instance isolation.

Use AWS Lambda functions triggered by Amazon EventBridge to remove the instance from the security group and attach the quarantine group.

Why wrong: Lambda can modify security groups, but the question asks for a combination; this option omits the triggering mechanism beyond EventBridge, which is not specific to compliance.

Configure the CloudWatch Agent to collect memory and system logs and publish them to CloudWatch Logs.

Why wrong: CloudWatch Agent collects metrics and logs, but not memory dumps.

Use AWS Systems Manager Run Command to execute a script on the instance that collects diagnostics before it is terminated.

Why wrong: Run Command requires the instance to be running and communicating; the instance may fail before the command executes.

Enable EC2 instance metadata service (IMDS) to capture diagnostic data that persists after termination.

Why wrong: Instance metadata is lost when the instance is terminated.

Use CloudFormation StackSets to manage the production stack across multiple accounts.

Why wrong: StackSets are for deployment across accounts, not for change review.

Use AWS Service Catalog to create a product for the stack and require approval for any portfolio changes.

Why wrong: Service Catalog manages product portfolios, not direct stack updates.

Use AWS CodePipeline to deploy the stack and require manual approval at the deploy stage.

Why wrong: CodePipeline can include a manual approval step, but CloudFormation Change Sets provide a more native review of actual changes.

Use the AWS Management Console to view memory metrics from the EC2 monitoring tab.

Why wrong: The console shows only default CloudWatch metrics; memory is not included.

Use EC2Rescue to generate a memory dump and analyze it.

Why wrong: EC2Rescue is for one-time diagnostics, not ongoing metric collection.

Enable CloudWatch detailed monitoring on the instance.

Why wrong: Detailed monitoring increases metric frequency but does not add memory metrics.

The S3 event notification is configured to send to an SNS topic that is not subscribed to the Lambda function.

Why wrong: This would result in an undeliverable notification error.

The S3 bucket policy does not allow the Lambda function to be invoked.

Why wrong: This would cause an error when S3 tries to invoke the function, logged in CloudTrail.

The Lambda function has a timeout that is too short.

Why wrong: A timeout would result in an error logged in CloudWatch.

The RDS CNAME record was not updated by AWS after the failover.

Why wrong: AWS automatically updates the CNAME to point to the new primary.

The application is using the read replica endpoint instead of the primary endpoint.

Why wrong: Read replica endpoints are separate and not affected by failover.

The application is using a Route 53 health check that failed and redirected traffic away from the endpoint.

Why wrong: Route 53 health checks are not automatically configured for RDS endpoints.