LEARN. PRACTICE. GROW.Concept and mechanism
A service update can proceed through batches of tasks and stop on failures according to configured policy. Pause, completion, and rollback are different states. Reverting service configuration does not automatically undo a SQL migration, a sent message, or a written file. The change plan needs to account for those effects. Also distinguish local Compose workflows from docker stack deploy: the stack uses its compatible legacy format and ignores build. Images must already be built and reachable by nodes. Delivery-command success proves only part of the result; validate tasks, effective configuration, dependencies, and a representative business operation.
Guided application
In a fictional Kubernetes project, a ConfigMap change does not update environment variables in existing processes. Plan controlled Pod replacement when consumption is environment-based. Do not transfer that rule without analysis to projected files, which have different update behavior. Readiness determines whether an instance is ready for traffic through corresponding endpoints; it is not a restart instruction. Liveness can restart containers and should avoid indiscriminate dependence on slow external services. During an incident, establish which probe failed before increasing replicas. The technical manager should require acceptance criteria covering service behavior, data compatibility, and rehearsed reversal.
Image rollback completed, column removed: data compatibility still needs resolution.
Common pitfalls
Stack as build; rollback as universal recovery; readiness as liveness; ConfigMap as live environment.
Related topics: Swarm: desired state, placement, and quorum · Reproducible images and registries · Daemon, logs, and recovery
Define what each mechanism changes and validate the business result.
Reference: Swarm services · DCA Study Guide v1.5 (January2025); current exam listing checked2026-09-30