deployment

PDB governs voluntary disruptions only and does not gate rolling updates at all. Describing it as 'it keeps N pods alive' states the part it does not do, since it constrains voluntary eviction and not the machine that fails.

The opener in most DevOps interviews, and the one most people answer as a list of nouns. What earns the follow-up is saying what each stage is allowed to fail for and how long it takes.

Compare rollout capacity, traffic exposure and state compatibility, then work through a payments canary with too little evidence to promote.

Sequence a compatible column migration, reconcile concurrent writes, and identify when returning to the old application starts requiring data repair.

Deployment and release are two decisions, not one. Choose stable cohorts, test failure defaults and propagation, and retire temporary flags without breaking older application versions.

A deceptively deep question, because there are at least six places a version can get stuck and they span the pipeline, the cluster and the edge. Work the path in order.

Code rolled back and the database did not. The old version is now running against a schema it has never seen, and that is a worse incident than the one you were trying to end.

Comparing the canary against last week is how a Tuesday afternoon looks like a regression. Compare it against a baseline running the same traffic at the same moment, and decide with a threshold somebody can defend.

A model is an artifact with a lineage, an evaluation record and an owner, or it is a file somebody copied to a bucket. The registry exists so that the second one cannot reach production.