EC2 CPU suddenly reaches 100% — how would you troubleshoot?

When a production EC2 instance hits 100% CPU, my priority is two-fold: stop customer impact immediately (mitigation) while capturing telemetry to pinpoint the exact culprit process (root cause analysis). Key Takeaway: Never reboot an instance blindly. Capture thread dumps and top process telemetry first so you don't lose the smoking gun, and ensure auto-scaling and CPU alarms prevent single-node exhaustion.

EC2 is running but SSH isn't working — what would you check?

When SSH fails while EC2 shows 'Running', the very first step is to observe the exact error message: 'Connection timed out' means a networking/firewall block, whereas 'Connection refused' or 'Permission denied' means you reached the OS but sshd or auth failed. Key Takeaway: Categorize the error immediately: 'Timed out' is AWS network/SG; 'Connection refused' is sshd/port; 'Permission denied' is key/username. Always have AWS SSM Session Manager enabled as a zero-SSH out-of-band management backdoor.

ALB starts returning 5xx errors — how would you identify the root cause?

When an ALB starts throwing 5xx errors, my immediate first goal is to differentiate between errors generated by the ALB itself versus errors generated by backend application targets. Key Takeaway: Always split ELB 5xx from Target 5xx in CloudWatch first. If it's ELB 502, check Keep-Alive timeout mismatches; if 503, check Target Group healthy host count; if 504, check target processing latency.

Application works internally but not from the internet — how would you troubleshoot?

Since the application works internally, the compute instance and software service are healthy. The failure is strictly along the ingress network path between the public internet and the AWS VPC. Key Takeaway: Trace outside-in: DNS -> Internet Gateway & Route Table -> Public Subnet ALB -> Security Group (80/443 from 0.0.0.0/0) -> NACLs (ephemeral return) -> WAF. Internal working proves compute is fine; focus purely on the AWS ingress pipeline.

Scenario: Your organization needs to migrate a large production workload from on-premises infrastructure to AWS/Azure with minimal downtime and no major service disruption. Explain your migration strategy, dependency mapping, networking, data replication, security, IaC, testing, cutover, rollback, and post-migration optimization.

Migrating enterprise workloads with near-zero downtime requires decoupling the migration into distinct phases: hybrid network foundation, continuous data synchronization with Change Data Capture (CDC), and a low-risk DNS/router cutover with an instant rollback mechanism. Key Takeaway: Near-zero downtime migration is achieved by pre-syncing data with AWS DMS CDC (Change Data Capture) over Direct Connect, lowering DNS TTL to 60s, and configuring reverse CDC back to on-prem as an instant safety rollback net.

131+ Production AWS & Cloud Architecture Interview Questions & Scenarios (2026 Edition)

Senior DevOps / SRE Compute & EC2

⚡ Scenario aws-ec2-cpu-100

EC2 CPU Suddenly Reaches 100% — Troubleshooting Runbook

Triage runbook for handling sudden 100% CPU utilization on production EC2 instances: telemetry triage, identifying culprit processes, handling legit vs maliciou...

#AWS #EC2 #CloudWatch

All AWS & Cloud Architecture Scenario Questions (131)