After a failed upgrade, municipal ops must recover API object state from a previously taken etcd snapshot. What does a successful etcd restore primarily recover?
Select an answer to reveal the explanation.
Short Explanation
Restoring etcd is like rolling the cluster’s memory back to the last good save point—Pods, Services, RBAC, the whole API picture that lived in that database. It doesn’t magically rebuild every node’s local disk junk, but it brings back the control plane’s truth. That’s why the snapshot from before the bad upgrade matters.
Full Explanation
After a failed upgrade, municipal ops restoring a previously taken etcd snapshot primarily recover the Kubernetes API objects and cluster state stored in etcd at snapshot time—Pods, Services, RBAC, and the rest of the API picture. Restoring etcd rolls the cluster’s memory back to the last good save point for control-plane truth. Restore does not primarily recover only container images cached on workers; those are node-local artifacts. CNI host routes alone are not what etcd restore returns; Deployments and Services come back as API objects from the datastore. Restore is not limited to kubelet files under /var/lib/kubelet while excluding Secrets and ConfigMaps—those API objects live in etcd. Exam caveat: Follow kubeadm/etcd restore procedures so all apiservers agree on the restored data directory. Operational check: Stop affected control-plane components per procedure, restore the snapshot to the etcd data dir, restart, and verify critical municipal objects exist with kubectl get across key namespaces. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services.