Operations and Maintenance practice questions

Modify the security group to allow all traffic temporarily

Why wrong: Opening security groups blindly reduces security and does not diagnose the issue.

Terminate the instance and let Auto Scaling launch a new one

Why wrong: Terminating without investigation does not identify root cause.

Attach an additional Elastic Network Interface (ENI) to the instance

Why wrong: Adding an ENI does not diagnose intermittent connectivity and may complicate the setup.

The CodeDeploy agent on the instances is outdated

Why wrong: Patch Manager uses SSM Agent, not CodeDeploy Agent.

The instances are not registered as managed instances with the SSM ManagedInstance role

Why wrong: If they are already managed, this error is not related to registration.

The instances do not have an IAM instance profile attached

Why wrong: If the instance were missing an IAM role, it would not appear in the managed instances list at all.

Use the AWS Management Console to modify the volume and enable encryption in place

Why wrong: EBS does not support enabling encryption on an existing unencrypted volume in place.

Take a snapshot of the volume, copy the snapshot with encryption enabled, then restore to a new volume and attach it to the instance

Why wrong: This works but requires an extra step (copy) compared to directly creating an encrypted snapshot.

Detach the volume, enable encryption using the ModifyVolume API, then reattach

Why wrong: The ModifyVolume API does not support changing encryption status.

Set up a CloudWatch alarm that triggers an SSM Run Command to restart the service

Why wrong: This adds extra components and latency compared to a simple systemd configuration.

Write a cron job that checks the service status every minute and restarts it if needed

Why wrong: Cron adds polling overhead and is not as responsive as systemd.

Use an AWS Lambda function that polls the service status and calls the EC2 reboot API

Why wrong: Lambda is not designed for this low-level system management and adds complexity.

The EC2 instance creation failed and then was cancelled

Why wrong: The events show the instance creation succeeded.

The EC2 instance had a DeletionPolicy of Retain, which prevented rollback

Why wrong: A Retain policy would keep the instance, but the error is about creation cancellation.

The EC2 instance depended on the EBS volume, and the dependency caused a timeout

Why wrong: Dependencies do not cause 'Resource creation cancelled' on a successful resource.

Use AWS Backup with a backup plan that takes cross-region backups every 15 minutes

Why wrong: AWS Backup supports cross-region but the minimum interval is typically 1 hour.

Use Amazon Machine Images (AMIs) backed by EBS snapshots, taken hourly

Why wrong: Hourly AMIs would result in an RPO of up to 1 hour, exceeding the 15-minute requirement.

Use EBS Multi-Attach volumes to allow the DR instance to access the same volumes

Why wrong: Multi-Attach is for low-latency clustering, not DR, and does not meet RPO/RTO.

Place the instances in a placement group to ensure high availability

Why wrong: Placement groups are for low latency, not high availability across AZs.

Use an Application Load Balancer to distribute traffic to the instances

Why wrong: ALB does not provide a static IP; it uses a DNS name.

Configure CloudTrail in the management account with an S3 bucket policy that grants access to all member accounts.

Why wrong: CloudTrail cross-account delivery is not supported natively.

Create a custom script using AWS CLI to enable CloudTrail in each account and region.

Why wrong: Scripts require maintenance and can miss drift.

Use AWS Service Catalog to publish a CloudTrail product and require each account to launch it.

Why wrong: Service Catalog does not enforce deployment; accounts may choose not to launch.

Examine the S3 server access logs for the bucket.

Why wrong: Server access logs do not include management API calls.

Review the configuration timeline in AWS Config for the S3 bucket.

Why wrong: Config shows the changes but not the user identity.

Use AWS Systems Manager Automation to run a script that checks CloudWatch Logs.

Why wrong: Inefficient and not the direct tool.

Use Amazon Inspector to scan for vulnerabilities and automatically apply patches.

Why wrong: Inspector only scans, it does not patch.

Terminate all instances and let the Auto Scaling group launch new instances from a patched AMI.

Why wrong: Causes downtime.

Create a custom AMI with latest patches and update the Auto Scaling group manually during a maintenance window.

Why wrong: Manual and not automated.

Log in to each account and view CloudWatch metrics individually.

Why wrong: Not scalable or centralized.

Use CloudWatch cross-region metrics to aggregate metrics in a single account.

Why wrong: Cross-region metrics only work within the same account.

Configure each account to publish metrics to an S3 bucket and use Athena to query.

Why wrong: Delayed and requires additional processing.

The SQS visibility timeout is too short; increase it.

Why wrong: Visibility timeout affects retries, not throttling.

The Lambda function's dead-letter queue (DLQ) is not configured; set up a DLQ.

Why wrong: DLQ handles failed messages, not throttling.

The SQS queue's redrive policy is too aggressive; reduce the maxReceiveCount.

Why wrong: Not related to throttling.

Create an AMI from a running instance and share it with the secondary region.

Why wrong: Requires manual action and does not ensure data consistency.

Use Route53 health checks to automatically failover traffic to a standby environment.

Why wrong: Does not protect database data.

Review VPC Flow Logs to identify if traffic is reaching the ALB.

Why wrong: Flow logs show network-level traffic, not application-level errors.

Use a lifecycle hook to delay instance registration until a script completes.

Why wrong: Lifecycle hooks add complexity and may not integrate with ALB health checks effectively.

Increase the health check interval on the ALB to reduce rapid replacements.

Why wrong: Longer interval may delay detection but doesn't prevent errors from cold instances.

Increase the desired capacity of the Auto Scaling group to absorb failures.

Why wrong: More capacity doesn't address the root cause of errors during warm-up.

Manually delete the DynamoDB table and then retry the stack update.

Why wrong: Manual deletion may cause data loss and does not resolve the rollback state.

Delete the stack and recreate it from the template.

Why wrong: Deleting the stack removes all resources, including the DynamoDB table with data.

Update the stack again with a different change set to bypass the failed resource.

Why wrong: Updating again is not possible while the stack is in UPDATE_ROLLBACK_FAILED state.

CloudFrontFullAccess

Why wrong: This policy is for CloudFront distributions, not S3 bucket operations.

AdministratorAccess

Why wrong: Overly permissive and not a best practice.

AmazonS3ReadOnlyAccess

Why wrong: This policy only allows read access, not write.

Use AWS Config rules to detect untagged buckets and trigger a Lambda function to add tags.

Why wrong: Reactive approach; buckets exist untagged for a period.

Configure each account's S3 bucket creation process to include tagging.

Why wrong: Requires manual effort in each account and may be missed.

Use AWS CloudTrail to monitor bucket creation and send alerts to the security team.

Why wrong: Only alerts; does not enforce tagging.

Enable automated backups with a short retention period.

Why wrong: Backups are unrelated to failover connection handling.

Increase the TTL of the RDS DNS record to 300 seconds.

Why wrong: Higher TTL means clients cache old IP longer, increasing downtime.

Place a Network Load Balancer in front of the RDS instance.

Why wrong: NLB does not support RDS directly; adds unnecessary complexity.

AWS Lambda

Why wrong: Could be used but is not required; EventBridge can directly invoke SNS.

AWS Config

Why wrong: Config evaluates resource configurations, not real-time API calls.

Amazon GuardDuty

Why wrong: GuardDuty is for threat detection, not custom API monitoring.