ownership

Managed Kubernetes offers several responsibility models. Application availability remains yours even when the provider also manages nodes and networking, and the interview tests whether you know where that line sits.

Routing rots because orgs change faster than configs. The senior answer treats ownership as data resolved from a catalog at fire time, with drift detection on the routing itself.

A catalogue nobody updates is worse than no catalogue, because people trust it once and get burned. Derive everything you can from systems that are already true, and make the rest a gate rather than a request.

Central teams optimise well and get ignored; federated teams own outcomes and drown in tooling. The mature answer is a hub-and-spoke split by decision type, and the interview tests whether you can say exactly who decides what.

The expensive part of these incidents is almost never the fix. It is the twenty minutes spent deciding whose incident it is.

Saying yes without a contribution contract produces features the platform team did not design and now supports forever, on call, at 3am.

Every capability a platform accepts is a permanent operational commitment. Teams that cannot say no end up operating six things badly instead of two things well.

An incident answer needs your actual decisions, the evidence behind them and the effect on users. A wrong turn belongs in the story only if it happened.

Prepare an accountable account of a technical mistake: disclosure, recovery decisions, a tested prevention measure and the residual risk.

Explain an AI feature failure through its promised outcome, observed quality gap, bounded recovery and the evidence needed for another release.