JUMP TO SECTIONChoose a lesson section
What you'll be able to explain.
- 01Build a defensible change plan with impact, rollback, owner and verification criteria.
- 02Separate patch compliance from actual service availability after a restart.
- 03Gather safe Linux diagnostics before restarting or reconfiguring a failed service.
- 04Apply pause/go decisions when migration, capacity or approval evidence is incomplete.
A patch can be correct—and still be mistimed.
A security or reliability update may be necessary, but its impact depends on timing, dependencies, service owner approval and a tested return path.
Scope and ownership
Identify exactly which hosts, VMs, services, users and dependencies are affected. Validate versions, compatibility matrices and known issues against vendor documentation.
Approval and window
Document the approver, maintenance window, outage expectations and communication plan. High-impact work can be appropriate once those requirements are met.
Rollback and stop conditions
Define rollback feasibility, configuration backups, available restoration points and the signals that will make the team stop or defer.
Operational takeawayChange management is not a prohibition on risk. It is a way to authorize necessary risks while making consequences and recovery explicit.
Know the starting condition.
A good preflight separates existing faults from problems introduced by a change.
Baseline
Capture host and guest versions, service status, current alerts, disk/storage capacity, relevant error logs and end-to-end user workflow results.
Dependency chain
Check available migration destinations, storage access, backups, hypervisor and driver/firmware compatibility, service order and network maintenance dependencies.
Ring or pilot
Where practical, validate the update against a representative test workload or first ring before updating every production host.
Owner approval: confirmed
Impact and dependencies: mapped
Backup/configuration recovery: checked
Rollback and stop criteria: documented
Post-change verification owner: assignedOperational takeawayDo not call a window 'green' just because a maintenance calendar says it started.
Diagnose before you restart.
A failed service on a Linux server is an opportunity to learn systemd and journal evidence. A restart might be the correct fix—but only once its risks are understood.
Service state
systemctl status displays service state and recent log context. systemctl is-enabled shows the configured boot-time enablement; 'active' and 'enabled' answer different questions.
Logs and dependencies
journalctl -u SERVICE --since '30 min ago' narrows service logs; journalctl -b relates entries to the current boot. A unit may fail because its filesystem, certificate, socket or network dependency is unavailable.
System health
df -h, free -h, uptime and ss -lnt can help scope storage, memory, load and listener state. Use read-only observations before modifying configuration or restarting production services.
systemctl status nginx --no-pager
journalctl -u nginx --since '30 min ago' --no-pager
df -h
ss -lnt # listening TCP socketsOperational takeawayCheck the service owner, blast radius and maintenance requirements. Never assume restarting a stateful service is harmless.
Execute one controlled change at a time.
Patch by documented sequence; record what actually happened, not only what the automation dashboard reported.
VMs and hosts
For ESXi hosts, confirm evacuation or approved guest shutdown and maintenance mode before remediation. For standalone hosts, arrange downtime instead of assuming vMotion exists.
OS updates
Check package/update applicability, dependencies and reboot requirements for the actual workload. Stage sensitive or high-availability systems in a supported order.
Observability
Track start and end time, change record, errors, service state, storage capacity, VM placements and any divergence from the approved procedure.
Operational takeawayIf a precondition fails, record the blocker and stop. Quietly bypassing an approval, an unavailable migration destination or a missing recovery plan creates a second incident.
A successful reboot is not a recovered service.
Post-change proof requires checking the original business workflow and the technical dependencies beneath it.
Technical verification
Confirm installed versions, host alerts, network/storage paths, service startup, scheduled tasks, logs, and appropriate backup or monitoring signals.
User-level acceptance
Validate an actual transaction: can a user authenticate, open files, complete the business action and see expected data?
Closeout
Record pass/fail outcomes, deviations, rollback or follow-up work, owner sign-off and post-change monitoring arrangements.
Ticket: Urgent host patch, missing approval
- Host patch fixes a relevant vulnerability; change window is open
- Production finance VM has not been migrated or approved for shutdown
- Owner approval is still pending and the on-call escalation path is available
Escalate for approval and resolve migration or downtime requirements before applying the patch. If those cannot be completed safely, defer and document compensating risk handling with the owner.
Correct urgency does not eliminate blast radius, needed authorization or a validated recovery path.
Can you defend the decision?
Try answering from memory before expanding each explanation. These checks support learning; they are not an exam-readiness score.
01The approved maintenance window has started but no one approved shutting down a remaining finance VM. Can host remediation proceed?+
Not safely on those facts. Confirm whether it can be migrated; if downtime is required, obtain the appropriate owner authorization or pause and reschedule.
02A Linux service shows 'failed' immediately after a package update. What are useful first read-only checks?+
Inspect systemctl status, relevant journalctl service and boot logs, resource capacity, dependencies and the actual failure timestamp before deciding whether a restart, rollback or configuration change is justified.
03Why is 'patch installed, host rebooted' insufficient evidence to close a change?+
It doesn't establish storage/network health, service dependencies, application transactions or user access. Verification needs the agreed technical and business acceptance tests.
Read from the source.
Vendor procedures depend on product version, hardware compatibility, and the environment's approved change controls. Verify the current documentation for any production task.