Service Configuration practice questions

An administrator wants to ensure that a custom service (myapp.service) starts only after the network is available and the PostgreSQL database service is running. Which systemd unit file directive should be used?

Trap 1: Requires=network.target postgresql.service

Requires= creates a dependency but does not guarantee start order; After= is needed.

Trap 2: Wants=network.target postgresql.service

Wants= is a weaker dependency, but still no ordering.

Trap 3: BindsTo=network.target postgresql.service

BindsTo= binds the service lifecycle to the listed units, but does not specify ordering.

A
Requires=network.target postgresql.service
Why it fails: Requires= creates a dependency but does not guarantee start order; After= is needed.
B
Wants=network.target postgresql.service
Why it fails: Wants= is a weaker dependency, but still no ordering.
C
BindsTo=network.target postgresql.service
Why it fails: BindsTo= binds the service lifecycle to the listed units, but does not specify ordering.
D
After=network.target postgresql.service
`After=` establishes ordering only, so myapp.service waits until both network.target and postgresql.service have activated before starting. This satisfies the stem's requirement that the custom service start only once the network is available and PostgreSQL is running, without implying a dependency that would pull those units in.

Question 2mediummulti select

Which TWO statements are true about systemd service unit files? (Choose two.)

Trap 1: Environment variables can be loaded using EnvFile= directive.

The correct directive is EnvironmentFile=.

Trap 2: The default service type is 'forking'.

The default type is 'simple'.

Trap 3: The [Service] section must appear before the [Unit] section.

The [Unit] section should be first; order does not matter, but convention is [Unit] first.

A
Environment variables can be loaded using EnvFile= directive.
Why it fails: The correct directive is EnvironmentFile=.
B
The default service type is 'forking'.
Why it fails: The default type is 'simple'.
C
The [Service] section is mandatory for a service unit file.
A service unit must have a [Service] section to define the process.
D
The [Install] section is used by systemctl enable to create symlinks.
The [Install] section defines WantedBy, RequiredBy, and Alias directives that systemctl enable reads to create the appropriate symlinks under /etc/systemd/system, wiring the unit into target dependencies. This satisfies the stem's requirement for a true statement about unit file structure and enablement behaviour.
E
The [Service] section must appear before the [Unit] section.
Why it fails: The [Unit] section should be first; order does not matter, but convention is [Unit] first.

Study the full Python automation breakdown →

Question 3hardmultiple choice

A system administrator is configuring a custom systemd service that runs a Python script. The script logs output to stdout. The administrator wants to ensure that the service restarts automatically if it crashes, but only after a 10-second delay. Which directive should be added to the [Service] section of the unit file?

Trap 1: Restart=on-success RestartSec=10

Restarts on successful exit, not on failure.

Trap 2: Restart=always RestartSec=10

Restarts always, even on successful exit, which may not be desired.

Trap 3: RestartSec=10

Sets the delay but does not enable restarting on failure.

A
Restart=on-success RestartSec=10
Why it fails: Restarts on successful exit, not on failure.
B
Restart=on-failure RestartSec=10
Restart=on-failure triggers a restart only when the Python script exits non-zero or is killed by a signal, matching the crash condition, while RestartSec=10 enforces the required 10-second delay before each restart attempt. Together they satisfy both constraints without restarting on clean exits.
C
Restart=always RestartSec=10
Why it fails: Restarts always, even on successful exit, which may not be desired.
D
RestartSec=10
Why it fails: Sets the delay but does not enable restarting on failure.

Question 4hardmultiple choice

A company runs a critical web application on a Linux server. The application is managed by a systemd service called 'myapp.service'. Recently, after a scheduled maintenance reboot, the service failed to start automatically. The administrator manually started it with 'systemctl start myapp' and it ran fine. The unit file is located at /etc/systemd/system/myapp.service and contains: [Unit] Description=MyApp After=network.target [Service] ExecStart=/usr/local/bin/myapp Restart=on-failure [Install] WantedBy=multi-user.target. The administrator wants to ensure the service starts automatically after future reboots. However, after running 'systemctl enable myapp', the service still didn't start after the next reboot. What is the most likely cause?

Trap 1: The 'systemctl enable' command only creates symlinks; a separate…

Enable is for boot start, not immediate start; but the service should start at boot.

Trap 2: The 'systemctl enable' command was not run as root.

Even if not root, it would have given an error; but the command succeeded as stated.

Trap 3: The unit file has a syntax error that prevents systemd from parsing…

If there were a syntax error, manual start would also fail.

A
The 'systemctl enable' command only creates symlinks; a separate 'systemctl start' must be run after enable.
Why it fails: Enable is for boot start, not immediate start; but the service should start at boot.
B
The service depends on a target that is not reached before the service starts, and 'Restart=on-failure' does not retry the start if the condition is not met.
With After=network.target, the service may start before network is fully ready; on-failure only restarts if the service exits with non-zero, but if the start fails due to a condition (e.g., network not ready), the service may not be restarted. Using 'Restart=always' or 'RestartSec' can help.
C
The 'systemctl enable' command was not run as root.
Why it fails: Even if not root, it would have given an error; but the command succeeded as stated.
D
The unit file has a syntax error that prevents systemd from parsing it.
Why it fails: If there were a syntax error, manual start would also fail.

Question 5mediummatching

Match each Linux process signal to its numeric value.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Trap 1: SIGKILL: 15

Incorrect — SIGKILL is 9, not 15. SIGTERM is signal 15.

Trap 2: SIGCONT: 25

Incorrect — SIGCONT is signal 18, not 25. Signal 25 is SIGXFSZ.

Trap 3: SIGINT: 9

Incorrect — SIGINT is signal 2, not 9. SIGKILL is signal 9.

A
SIGKILL: 9
SIGKILL is signal 9, which immediately terminates a process and cannot be caught or ignored.
B
SIGTERM: 15
SIGTERM is signal 15, the default termination signal that can be caught or ignored.
C
SIGSTOP: 19
SIGSTOP is signal 19, which pauses a process and cannot be caught or ignored.
D
SIGKILL: 15
Why it fails: Incorrect — SIGKILL is 9, not 15. SIGTERM is signal 15.
E
SIGCONT: 25
Why it fails: Incorrect — SIGCONT is signal 18, not 25. Signal 25 is SIGXFSZ.
F
SIGINT: 9
Why it fails: Incorrect — SIGINT is signal 2, not 9. SIGKILL is signal 9.

Question 6mediummultiple choice

A system administrator wants to limit the CPU usage of a service. Which systemd resource control directive should be used?

Trap 1: CPUShares

Controls relative weight, not absolute limit.

Trap 2: CPUQuota

Alone it is ignored; CPUAccounting must be enabled.

Trap 3: CPULimit

Not a valid systemd directive.

A
CPUShares
Why it fails: Controls relative weight, not absolute limit.
B
CPUQuota
Why it fails: Alone it is ignored; CPUAccounting must be enabled.
C
CPUAccounting=yes and CPUQuota
CPUAccounting enables accounting, then CPUQuota can be applied.
D
CPULimit
Why it fails: Not a valid systemd directive.

Question 7hardmultiple choice

To ensure a service starts only after /var/lib/mysql is mounted, which directive should be used in the unit file?

Trap 1: Requires=/var/lib/mysql

Requires expects a unit name, not a path.

Trap 2: BindsTo=var-lib.mount

BindsTo binds service lifecycle to mount, but does not ensure startup order.

Trap 3: Before=var-lib.mount

Before would start the service before the mount.

A
Requires=/var/lib/mysql
Why it fails: Requires expects a unit name, not a path.
B
BindsTo=var-lib.mount
Why it fails: BindsTo binds service lifecycle to mount, but does not ensure startup order.
C
Before=var-lib.mount
Why it fails: Before would start the service before the mount.
D
After=var-lib.mount
After=var-lib.mount orders the service after the mount unit for /var/lib/mysql, satisfying the requirement that the service start only once that filesystem is mounted. Requires= would additionally pull the mount in, but After alone provides the ordering.

Question 8mediummultiple choice

A service that was once enabled is now failing to start. The administrator wants to immediately disable it to prevent boot delays. Which command sequence is correct?

Trap 1: systemctl disable service ; systemctl stop service

Disable then stop, but if disable fails, stop may not run.

Trap 2: systemctl stop service && systemctl disable service

Correct but not the most efficient.

Trap 3: systemctl mask service

Masking prevents any start, but does not stop if already running.

A
systemctl disable service ; systemctl stop service
Why it fails: Disable then stop, but if disable fails, stop may not run.
B
systemctl stop service && systemctl disable service
Why it fails: Correct but not the most efficient.
C
systemctl disable --now service
Combines disabling the unit's autostart symlinks with immediate stoppage, so the failing service cannot delay boot. The --now flag triggers stop alongside disable, satisfying the requirement to halt it at once rather than merely preventing future activation.
D
systemctl mask service
Why it fails: Masking prevents any start, but does not stop if already running.

Question 9easymulti select

Which TWO commands can be used to check the status of a service?

Trap 1: systemd-analyze

Analyzes boot performance, not status.

Trap 2: start stop restart

Not a valid command.

Trap 3: initctl status

Used by Upstart init system, not systemd.

A
systemd-analyze
Why it fails: Analyzes boot performance, not status.
B
service status
Legacy command, still works with systemd via compatibility.
C
start stop restart
Why it fails: Not a valid command.
D
systemctl status
Querying systemd's manager for a unit's status reports its active state, main PID and recent log lines. This satisfies the requirement on systemd-based distributions, where units are tracked by the manager rather than SysV init scripts.
E
initctl status
Why it fails: Used by Upstart init system, not systemd.

Question 10mediummultiple choice

Based on the exhibit, what is the correct interpretation?

Exhibit

Refer to the exhibit.

Output of `systemctl status apache2`:

● apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2; generated; vendor preset: enabled)
   Active: active (running) since Mon 2023-08-14 10:15:30 UTC; 5min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1234 ExecStart=/etc/init.d/apache2 start (code=exited, status=0/SUCCESS)
   Main PID: 5678 (apache2)

Warning: apache2.service changed on disk. Run 'systemctl daemon-reload' to reload units.

Trap 1: The service is inactive

Status shows active.

Trap 2: The configuration file is corrupt

No indication of corruption; only that the unit file changed.

Trap 3: The service is failing

Status shows active (running).

A
The service is inactive
Why it fails: Status shows active.
B
The configuration file is corrupt
Why it fails: No indication of corruption; only that the unit file changed.
C
The service is running but the unit file has been modified recently and needs reloading
The unit is active (running), yet systemd reports that the on-disk unit file changed after loading, so the running configuration is stale. Running systemctl daemon-reload re-reads the modified unit file and clears the warning without stopping the service.
D
The service is failing
Why it fails: Status shows active (running).

Question 11hardmultiple choice

Which of the following statements is true about this unit?

Exhibit

Refer to the exhibit.

[Unit]
Description=My Custom Service
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/myservice.sh
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Trap 1: The service can be started by a timer unit

Possible but not indicated in the unit.

Trap 2: The service will start automatically at boot only if…

Wants is weak; service may start even if target fails.

Trap 3: The service requires SELinux context

Not mentioned in the unit.

A
The service will be restarted indefinitely with a 10-second delay between restarts regardless of exit status
A systemd unit with `Restart=always` restarts the service after any exit, including clean termination, satisfying the stem's "regardless of exit status" constraint. `RestartSec=10` inserts the specified ten-second delay between each restart attempt, matching the stated interval exactly.
B
The service can be started by a timer unit
Why it fails: Possible but not indicated in the unit.
C
The service will start automatically at boot only if network-online.target is reached
Why it fails: Wants is weak; service may start even if target fails.
D
The service requires SELinux context
Why it fails: Not mentioned in the unit.

Question 12easymultiple choice

What can be concluded from the log?

Exhibit

Refer to the exhibit.

Output of `journalctl -u sshd.service --no-pager -p err`:

Jul 15 09:23:45 server sshd[1234]: Failed to start OpenSSH server daemon
Jul 15 09:23:45 server sshd[1234]: sshd.service: main process exited, code=exited, status=255/n/a
Jul 15 09:23:45 server sshd[1234]: Unit sshd.service entered failed state.

Trap 1: SSH server is masked

Masked would show 'masked' status, not in log.

Trap 2: SSH server is running with errors

Log says failed state, not running.

Trap 3: SSH server stopped normally

Exit code 255 and failed state indicate abnormal exit.

A
SSH server is masked
Why it fails: Masked would show 'masked' status, not in log.
B
SSH server is running with errors
Why it fails: Log says failed state, not running.
C
SSH server stopped normally
Why it fails: Exit code 255 and failed state indicate abnormal exit.
D
SSH server failed to start due to configuration error
The log shows sshd rejecting its configuration before binding any socket, so the daemon exits rather than listening. This satisfies the stem's requirement to conclude the actual failure cause: a syntax or directive error in /etc/ssh/sshd_config, not a port conflict or firewall block.

Question 13mediummultiple choice

A service requires read-write access to a specific directory that is mounted from an NFS share. The directory is mounted via fstab with the option 'noauto'. The service starts before the mount is available. Which configuration change should be made in the service unit file to ensure the service only starts after the mount is mounted?

Trap 1: Add Before=mnt-nfs.mount and Requires=mnt-nfs.mount

Before would cause the service to start before the mount, which is the opposite of what is needed.

Trap 2: Add Wants=mnt-nfs.mount and After=mnt-nfs.mount

Wants is a soft dependency; the service can still start even if the mount fails.

Trap 3: Add After=mnt-nfs.mount and BindsTo=mnt-nfs.mount

BindsTo makes the service tightly bound; if the mount stops, the service stops, which may be undesirable.

A
Add After=mnt-nfs.mount and Requires=mnt-nfs.mount
Adding both directives binds the unit to the mount: `Requires=mnt-nfs.mount` pulls the mount into the transaction and stops the service if it fails, while `After=` orders startup strictly after mounting completes. This satisfies the stem's constraint that the service must not start before the noauto NFS mount is available.
B
Add Before=mnt-nfs.mount and Requires=mnt-nfs.mount
Why it fails: Before would cause the service to start before the mount, which is the opposite of what is needed.
C
Add Wants=mnt-nfs.mount and After=mnt-nfs.mount
Why it fails: Wants is a soft dependency; the service can still start even if the mount fails.
D
Add After=mnt-nfs.mount and BindsTo=mnt-nfs.mount
Why it fails: BindsTo makes the service tightly bound; if the mount stops, the service stops, which may be undesirable.

Question 14mediummultiple choice

A system administrator is debugging why a service named 'myapp.service' fails to start. He runs 'systemctl status myapp.service' and sees the status 'failed' with details 'Exit code: 1' and 'Failed with result exit-code'. Which command should be used next to view the full log of the service?

Trap 1: systemctl show myapp.service

Incorrect: `systemctl show myapp.service` displays unit properties and configuration, not the service's runtime log output.

Trap 2: journalctl -x -u myapp.service

Incorrect: While `journalctl -x -u myapp.service` also shows logs, the `-x` flag adds catalog message explanations that may clutter the output and are not necessary to see the actual service logs. The plain `-u` flag is sufficient.

Trap 3: systemctl list-dependencies myapp.service

Incorrect: `systemctl list-dependencies myapp.service` shows the dependency tree of the unit, not its log entries.

A
journalctl -u myapp.service
journalctl -u filters the journal by the specified unit, exposing the full stdout and stderr captured for that service. This reveals the actual error behind exit code 1, which systemctl status only summarises in its truncated output.
B
systemctl show myapp.service
Why it fails: Incorrect: `systemctl show myapp.service` displays unit properties and configuration, not the service's runtime log output.
C
journalctl -x -u myapp.service
Why it fails: Incorrect: While `journalctl -x -u myapp.service` also shows logs, the `-x` flag adds catalog message explanations that may clutter the output and are not necessary to see the actual service logs. The plain `-u` flag is sufficient.
D
systemctl list-dependencies myapp.service
Why it fails: Incorrect: `systemctl list-dependencies myapp.service` shows the dependency tree of the unit, not its log entries.

Question 15mediummultiple choice

A service unit file includes the following: [Install] WantedBy=multi-user.target. What does this directive accomplish?

Trap 1: The service is stopped when multi-user.target is stopped.

WantedBy does not cause stopping; it creates a soft dependency.

Trap 2: The service conflicts with multi-user.target.

WantedBy does not create a conflict.

Trap 3: The service is automatically started when the system enters…

This is true for enabled services, but WantedBy itself does not start the service; it enables it.

A
The service is stopped when multi-user.target is stopped.
Why it fails: WantedBy does not cause stopping; it creates a soft dependency.
B
The service conflicts with multi-user.target.
Why it fails: WantedBy does not create a conflict.
C
The service is automatically started when the system enters multi-user.target.
Why it fails: This is true for enabled services, but WantedBy itself does not start the service; it enables it.
D
The service is enabled by symlinking in multi-user.target.wants.
The `WantedBy=multi-user.target` directive causes `systemctl enable` to create a symlink inside `/etc/systemd/system/multi-user.target.wants/`, pulling the unit into that target's dependency graph at boot. This satisfies the stem's requirement that the unit starts automatically during the multi-user boot stage.

Question 16mediummulti select

Which two commands produce output that includes the current runlevel or target? (Choose two.)

Trap 1: systemctl list-units --type=target

This lists all targets, not the current one.

Trap 2: systemctl show-environment

Shows environment variables, not runlevel.

Trap 3: systemctl get-default

This shows the default target, not the current runlevel.

A
systemctl list-units --type=target
Why it fails: This lists all targets, not the current one.
B
systemctl show-environment
Why it fails: Shows environment variables, not runlevel.
C
runlevel
The `runlevel` command reads `/var/run/utmp` and prints the previous and current SysV runlevel, satisfying the stem's requirement for output containing the current runlevel. It reports runlevels numerically (for example, "N 5"), which is precisely the information requested, though it does not report systemd targets.
D
who -r
`who -r` reads the utmp database and prints the current runlevel plus its previous level and the time of the last change, satisfying the stem's requirement for runlevel output. It reports SysV-style runlevels directly, unlike commands that only show systemd targets or logged-in users.
E
systemctl get-default
Why it fails: This shows the default target, not the current runlevel.

Question 17mediummulti select

Which two statements are true about systemd socket activation? (Choose two.)

Trap 1: The socket unit file must have an [Install] section.

The socket unit can be enabled but it's not strictly required for activation.

Trap 2: Socket activation requires the service to be of type 'socket'.

The service type is separate; the socket unit handles the socket.

Trap 3: Socket activation only works with TCP sockets.

It also works with Unix sockets.

A
The socket unit file must have an [Install] section.
Why it fails: The socket unit can be enabled but it's not strictly required for activation.
B
Socket activation requires the service to be of type 'socket'.
Why it fails: The service type is separate; the socket unit handles the socket.
C
The service unit must include 'Sockets=<socket unit>' to bind the service to the socket.
This directive links the service to the socket unit.
D
A service can be started on demand when a connection arrives on a socket.
Socket activation lets systemd listen on the socket and start the service only when a connection arrives, rather than at boot. This on-demand behaviour satisfies the stem's requirement for a true statement about socket activation.
E
Socket activation only works with TCP sockets.
Why it fails: It also works with Unix sockets.

Question 18hardmulti select

Which three of the following are valid reasons to use 'systemctl mask' instead of 'systemctl disable'? (Choose three.)

Trap 1: To hide the service from status commands.

Masked units are still visible in systemctl status.

Trap 2: To make the service completely unavailable to the system.

This is true but too general; the question asks for specific reasons.

A
To hide the service from status commands.
Why it fails: Masked units are still visible in systemctl status.
B
To make the service completely unavailable to the system.
Why it fails: This is true but too general; the question asks for specific reasons.
C
To ensure that even 'systemctl start' fails.
Masking symlinks the unit to /dev/null, so systemd cannot load it at all. Any start request, including 'systemctl start', fails immediately with 'Unit is masked', satisfying the requirement that manual activation be impossible rather than merely disabled at boot.
D
To prevent the service from being enabled via any dependency.
A masked unit's symlink to /dev/null makes it unloadable, so dependency resolution cannot pull it in. Wants=, Requires= or socket activation referencing the unit will not start it, which disable alone cannot guarantee since dependencies can still activate a disabled unit.
E
To prevent the service from being started manually.
Masking links the unit to /dev/null, making it unloadable, so systemctl start fails outright. Disable only removes autostart symlinks while leaving the unit startable manually. Masking therefore prevents manual starts, which is the stated requirement.

Question 19mediummultiple choice

Refer to the exhibit. What is the most likely cause of the sshd service failure?

Exhibit

● systemctl status sshd.service
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2025-03-10 10:15:23 UTC; 2min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 12345 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=255)
 Main PID: 12345 (code=exited, status=255)
   Status: "SSH Daemon exited abnormally"

Trap 1: The OPTIONS environment variable is not set.

Even if unset, sshd would start with defaults; it wouldn't cause exit 255.

Trap 2: The service is not enabled to start at boot.

The status shows 'enabled', so it is enabled.

Trap 3: There is a syntax error in the unit file.

The unit file loaded successfully, so no syntax error.

A
The OPTIONS environment variable is not set.
Why it fails: Even if unset, sshd would start with defaults; it wouldn't cause exit 255.
B
The service is not enabled to start at boot.
Why it fails: The status shows 'enabled', so it is enabled.
C
There is a syntax error in the unit file.
Why it fails: The unit file loaded successfully, so no syntax error.
D
The sshd_config file is misconfigured.
A syntax or directive error in sshd_config causes sshd to abort at startup, which systemd reports as a failed service. The configuration file is parsed before the daemon binds, so malformed entries directly explain the failure.

Read the full DNS explanation →

Question 20mediummultiple choice

A company runs a monitoring agent service (monitor.service) that must start after the network is fully up and the DNS resolver is ready. The service currently has the following dependencies in its unit file:

[Unit]

Description=Monitoring Agent After=network.target Wants=network.target

[Service]

ExecStart=/usr/bin/monitor

The service starts, but often fails to resolve hostnames because DNS is not yet available. Which change should be made to the unit file to ensure the service only starts after DNS is ready?

Trap 1: Replace After=network.target with After=network-online.target and…

Ensures network is up but not necessarily DNS.

Trap 2: Add Before=network.target to delay the start

Makes service start before network, making DNS unavailable.

Trap 3: Set Type=idle in the [Service] section

Does not guarantee DNS readiness.

A
Replace After=network.target with After=network-online.target and add Requires=network-online.target
Why it fails: Ensures network is up but not necessarily DNS.
B
Add a dependency: After=nss-lookup.target
Adding `After=nss-lookup.target` orders monitor.service after the name-service switch lookup target, which systemd reaches once the DNS resolver and /etc/nsswitch.conf lookups are ready. This directly satisfies the stem's constraint that DNS must be available, unlike `network.target`, which only signals that network interfaces are configured, not that resolution works.
C
Add Before=network.target to delay the start
Why it fails: Makes service start before network, making DNS unavailable.
D
Set Type=idle in the [Service] section
Why it fails: Does not guarantee DNS readiness.