Memory hook: Configure the dependency chain, then verify the service.
Must remember
Package tasks depend on usable repositories, trust/signing configuration and network access. Use the appropriate package/repository module and an explicit intended state. latest means potentially changing on future runs; present ensures installation without promising the newest package. Follow the requirement rather than applying one state everywhere.
Service state and boot enablement are separate. A service can be running now but disabled for the next boot. Firewall configuration similarly distinguishes runtime and persistent changes in relevant modules. Verify the listening application, local firewall and external reachability instead of stopping at a successful service task.
Storage automation follows devices, partitions, volume groups/logical volumes, filesystems and mounts in the correct order. Discover/validate the target device before any destructive operation. Creating a filesystem on the wrong device destroys data; shrinking is not equivalent to extending, and filesystem support differs. Use a disposable practice environment for storage exercises.
Persistent mounts need correct filesystem identity, mount path, options and boot behavior. A directory existing does not prove the filesystem is mounted. Verify with appropriate read-only system tools and after reboot. SELinux contexts and firewall permissions can still prevent a correctly mounted service directory from being usable.
Use supported system roles or network modules for repeatable network configuration, understanding connection disruption. Template only the required configuration and validate before replacing it. Archive/unarchive tasks distinguish source location and destination behavior. Scheduled jobs need the correct user, environment and idempotent entry identity.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Run a service now and after reboot | Set both started and enabled state. |
| Persist a new filesystem mount | Create prerequisites and manage the persistent mount definition. |
| Deploy a repeated scheduled task | A supported scheduling module with stable identity and correct user. |
Traps
- Running now does not mean enabled at boot.
- A successful storage task can still target the wrong device if discovery was wrong.
Active recall
1. present versus latest?
Ensure installed versus seek the newest available version under repository constraints.
2. Why validate storage identity?
A mistaken device choice can destroy unrelated data.
3. Why inspect runtime and permanent firewall state?
They can diverge and behave differently after reload/reboot.
4. What confirms a mount?
Actual mounted filesystem/source/options, not just the existence of a directory.
5. Why test the whole dependency chain?
Package, configuration, service, storage, firewall and security policy must all agree.
Sources
- collections · ansible · builtin · dnf_module.html
- collections · ansible · builtin · systemd_service_module.html
- collections · ansible · posix · firewalld_module.html
- collections · ansible · posix · mount_module.html
- collections · community · general · lvol_module.html
- collections · ansible · builtin · cron_module.html