Incident Overview
A fictional internal application named ledger-api is unavailable through its Kubernetes Service after a routine deployment. Direct application health observations supplied by the exercise indicate that three replacement Pods are Ready.
The deployment reports its intended replica count as available, yet requests through the Service fail. The fictional impact is confined to one internal workflow, with no evidence of data loss or wider cluster failure.The incident lead asks for the safest immediate action.
No manifest change is authorised during this triage stage. Success means establishing whether the Service currently selects the replacement Pods, identifying an evidence-supported recovery candidate, and preserving a clear boundary for escalation.
Investigation Options
Review the available operational moves and select the best immediate action.
Inspect the Service selector, Pod labels and endpoint objects using read-only queries; if the mismatch is confirmed, prepare a reviewed correction without applying it.
Restart the Ready Pods to force endpoint registration.
Investigate cluster networking before comparing selectors and labels.
Send traffic directly to Pod addresses as a temporary operational bypass.