Describe an incident or outage you handled in a cloud environment.

Give a timeline and separate stabilising from diagnosing.

• Detection. Which alarm, what metric, and how long after the actual start. If a customer told you first, say so — the gap is a finding in itself.
• Stabilise before you understand. Rolling back a deployment, scaling out, failing over to another availability zone, or shedding load. Interviewers want to see that you restore service rather than debugging while users are down.
• Diagnosis. CloudWatch metrics and logs, X-Ray traces to find which downstream call was slow, CloudTrail to see what changed and who changed it, and the AWS Health Dashboard to rule out a platform-side event.
• The permanent fix. Usually structural: a missing health check, no retry with exponential backoff and jitter, a single-AZ dependency, a connection pool exhausted under load, or a hard service quota nobody knew about.

Note: Service quotas are an excellent detail — hitting a Lambda concurrency limit or an API rate limit during a traffic spike is a very common cloud outage cause and one many candidates have never considered. Mentioning that you now monitor quota utilisation shows genuine operational experience.