Courseiva

CCNA Service Configuration Questions

58 questions · Service Configuration · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
Multi-Selecthard

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

Select 3 answers
A.To hide the service from status commands.
B.To make the service completely unavailable to the system.
C.To ensure that even 'systemctl start' fails.
D.To prevent the service from being enabled via any dependency.
E.To prevent the service from being started manually.
AnswersC, D, E

Masking causes start to fail; disable does not.

Why this answer

Option C is correct because 'systemctl mask' creates a symlink from the unit file to /dev/null, which causes all attempts to start the service (including 'systemctl start') to fail silently. This is a stronger action than 'systemctl disable', which only removes the symlinks that enable automatic startup but still allows manual starting via 'systemctl start'.

Exam trap

The trap here is that candidates often confuse 'disable' with 'mask', thinking both prevent manual start, but only 'mask' ensures that even explicit 'systemctl start' commands fail.

Practice this question →
2
MCQeasy

What can be concluded from the log?

A.SSH server is masked
B.SSH server is running with errors
C.SSH server stopped normally
D.SSH server failed to start due to configuration error
AnswerD

Exit status 255 typically indicates a configuration problem.

Why this answer

The log shows that the SSH service failed to start because of a configuration error. Specifically, the log entry indicates a syntax error or invalid directive in the SSH daemon configuration file (typically /etc/ssh/sshd_config), which prevents the service from binding to the port and starting. This is a common issue when editing the configuration file manually, as the SSH daemon validates its configuration at startup and will refuse to run if any errors are found.

Exam trap

The trap here is that candidates often confuse a service that fails to start due to a configuration error with a service that is running but has errors, leading them to select option B instead of D.

How to eliminate wrong answers

Option A is wrong because a masked service would not produce a log entry about a configuration error; instead, systemctl status would show 'masked' and the service would be prevented from starting entirely. Option B is wrong because the log indicates a failure to start, not a running service with errors; a running SSH server with errors would show operational issues like failed authentication attempts or connection drops, not a startup failure. Option C is wrong because a normal stop would generate a clean shutdown message (e.g., 'Stopping OpenSSH server daemon') and the service would exit with status 0, not a configuration error.

Practice this question →
3
MCQmedium

A custom systemd service unit file has been created but the service fails to start with 'Exec format error'. What is the most likely cause?

A.The unit file has incorrect permissions
B.The user does not have permission to start the service
C.The service is disabled
D.The ExecStart command path is incorrect or missing shebang
AnswerD

An invalid executable or missing interpreter causes exec format error.

Why this answer

The 'Exec format error' in systemd indicates that the binary or script specified in the ExecStart directive cannot be executed, typically because the path is incorrect, the file is not executable, or (most commonly) the script lacks a valid shebang line (e.g., #!/bin/bash). Without a shebang, the kernel does not know which interpreter to use, causing an execve() failure.

Exam trap

Linux Foundation often tests the distinction between 'Exec format error' and other startup failures, trapping candidates who confuse permission issues (chmod +x) with the missing shebang requirement for interpreted scripts.

How to eliminate wrong answers

Option A is wrong because unit file permissions (e.g., 644) do not affect execution; systemd reads the unit file as root, and the error is about the ExecStart target, not the unit file itself. Option B is wrong because if the user lacked permission to start the service, systemctl would report 'Permission denied' or 'Access denied', not an 'Exec format error'. Option C is wrong because a disabled service simply means it won't start automatically at boot; attempting to start it manually with systemctl start would still work if the unit is correct, and the error would not be 'Exec format error'.

Practice this question →
4
MCQeasy

After editing a service unit file, which command must be run for changes to take effect?

A.systemctl restart <service>
B.systemctl daemon-reload
C.systemctl reenable <service>
D.systemctl reload <service>
AnswerB

daemon-reload reloads all unit files, applying any changes.

Why this answer

When a service unit file is edited, systemd must be notified to reload its configuration from disk. The `systemctl daemon-reload` command instructs systemd to re-read all unit files, applying any changes to the unit definitions without requiring a full system reboot. This is necessary because systemd caches unit file contents in memory, and only a daemon-reload will update that cache.

Exam trap

The trap here is that candidates confuse restarting the service (which affects the running process) with reloading the systemd daemon (which updates the unit definition cache), leading them to choose `systemctl restart` instead of `systemctl daemon-reload`.

How to eliminate wrong answers

Option A is wrong because `systemctl restart <service>` only stops and starts the service using the currently loaded unit configuration; it does not cause systemd to re-read the unit file from disk, so any changes to the unit file itself are ignored. Option C is wrong because `systemctl reenable <service>` recreates symlinks in the systemd configuration directories but does not reload the unit definitions into systemd's running state. Option D is wrong because `systemctl reload <service>` sends a SIGHUP or equivalent signal to the service process to reload its own configuration files, not systemd's unit file definitions.

Practice this question →
5
MCQeasy

A system administrator needs to ensure the Apache httpd service starts automatically on system boot. Which command should they use?

A.systemctl enable httpd
B.systemctl start httpd
C.systemctl disable httpd
D.systemctl reload httpd
AnswerA

systemctl enable creates symlinks for automatic start at boot.

Why this answer

The `systemctl enable httpd` command creates the necessary symlinks in the systemd unit configuration directories (typically `/etc/systemd/system/multi-user.target.wants/`) to ensure the Apache httpd service starts automatically at boot time. This is the correct approach because `enable` configures the service to be started on system startup, whereas `start` only runs it immediately without affecting boot behavior.

Exam trap

The trap here is confusing `systemctl start` (immediate runtime action) with `systemctl enable` (persistent boot-time configuration), leading candidates to choose the command that works now but fails after a reboot.

How to eliminate wrong answers

Option B is wrong because `systemctl start httpd` starts the service immediately in the current session but does not configure it to start on boot; it only affects the runtime state. Option C is wrong because `systemctl disable httpd` removes the boot-time symlinks, preventing the service from starting automatically at boot, which is the opposite of what is required. Option D is wrong because `systemctl reload httpd` sends a SIGHUP signal to the httpd process to reload its configuration without restarting, which has no effect on boot-time behavior.

Practice this question →
6
MCQeasy

An administrator deploys a new custom service using a unit file called myapp.service. The service needs to start automatically at system boot. Which command should the administrator run to achieve this?

A.systemctl start myapp.service
B.systemctl enable myapp.service
C.systemctl add-wants myapp.service
D.systemctl daemon-reload myapp.service
AnswerB

Creates symlinks to start the service at boot.

Why this answer

The `systemctl enable` command creates the necessary symlinks in the systemd unit configuration directories (e.g., `/etc/systemd/system/multi-user.target.wants/`) to ensure the service is started automatically at boot. This is the correct method to enable a service to start on boot in a systemd-based Linux system.

Exam trap

The trap here is that candidates confuse `systemctl start` (which runs the service now) with `systemctl enable` (which configures automatic startup at boot), leading them to select option A incorrectly.

How to eliminate wrong answers

Option A is wrong because `systemctl start` immediately starts the service but does not configure it to start automatically at boot; it only affects the current session. Option C is wrong because `systemctl add-wants` is not a valid systemd command; the correct command to add a dependency is `systemctl add-wants` is not recognized, and the proper way to enable a service is via `systemctl enable`. Option D is wrong because `systemctl daemon-reload` reloads systemd manager configuration but does not enable a service for boot-time startup; it is used after modifying unit files.

Practice this question →
7
MCQmedium

A service is configured to run as a specific user. Which directive in the [Service] section sets the user?

A.RunAs
B.User
C.Account
D.UserID
AnswerB

User= specifies the service's user.

Why this answer

In systemd service units, the directive to specify the user under which the service process runs is `User=` within the `[Service]` section. This directive sets the Unix user account (by name or UID) that the service's main PID will execute as, ensuring proper privilege separation and security.

Exam trap

The trap here is that candidates may confuse systemd's `User=` with the `RunAs` keyword from other operating systems (like Windows services or Solaris) or with generic terms like `Account`, leading them to pick a plausible-sounding but incorrect option.

How to eliminate wrong answers

Option A is wrong because `RunAs` is not a valid systemd directive; it is a concept from other init systems like Solaris SMF or some Docker configurations. Option C is wrong because `Account` is not a systemd directive; it might be confused with the `Account=` field in PAM or NSS contexts but has no place in a systemd service unit. Option D is wrong because `UserID` is not a valid systemd directive; systemd uses `User=` for the username and `Group=` for the group, not a literal 'UserID' key.

Practice this question →
8
MCQeasy

A service named webserver.service is failing to start. The administrator wants to see the most recent error messages related to this service. Which command provides this information?

A.journalctl -u webserver.service
B.systemctl status webserver.service --full
C.systemctl list-units --type=service | grep webserver
D.systemctl is-active webserver.service
AnswerA

Shows logs for the unit, including recent errors.

Why this answer

The `journalctl -u webserver.service` command queries the systemd journal for all log entries associated with the specified unit, showing the most recent error messages in reverse chronological order. This is the standard way to view detailed, time-stamped error logs for a failing service, as `journalctl` provides access to the binary journal that captures stdout, stderr, and syslog messages from the service.

Exam trap

The trap here is that candidates confuse `systemctl status` (which shows a brief log snippet) with `journalctl -u` (which provides the full, searchable journal), assuming the status command gives complete error history when it only shows a truncated view.

How to eliminate wrong answers

Option B is wrong because `systemctl status webserver.service --full` shows the current state, recent log lines (usually the last 10), and unit metadata, but it does not display the full journal history or allow filtering by priority; it truncates output and is not designed for deep error inspection. Option C is wrong because `systemctl list-units --type=service | grep webserver` only lists loaded service units and their states (active/inactive), not any error messages or logs. Option D is wrong because `systemctl is-active webserver.service` simply returns a single word (active, inactive, failed) indicating the service's current state, with no error details whatsoever.

Practice this question →
9
Multi-Selectmedium

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

Select 2 answers
A.systemctl list-units --type=target
B.systemctl show-environment
C.runlevel
D.who -r
E.systemctl get-default
AnswersC, D

Displays previous and current runlevel.

Why this answer

The `runlevel` command displays the previous and current runlevel from the `/var/run/utmp` file, making it a direct way to see the current runlevel. The `who -r` command reads the same utmp file and prints the current runlevel along with the time of the last runlevel change, so both commands produce output that includes the current runlevel or target.

Exam trap

The trap here is that candidates often pick `systemctl get-default` (option E) thinking it shows the current target, but it only shows the default target for the next boot, not the currently active target, which is a common confusion between persistent default and runtime state.

Practice this question →
10
MCQmedium

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?

A.Add After=mnt-nfs.mount and Requires=mnt-nfs.mount
B.Add Before=mnt-nfs.mount and Requires=mnt-nfs.mount
C.Add Wants=mnt-nfs.mount and After=mnt-nfs.mount
D.Add After=mnt-nfs.mount and BindsTo=mnt-nfs.mount
AnswerA

This ensures the service starts after the mount and fails if the mount fails.

Why this answer

Option A is correct because the service requires the NFS mount to be available before it starts. The `After=mnt-nfs.mount` directive ensures the service unit is ordered after the mount unit, and `Requires=mnt-nfs.mount` makes the mount a hard dependency: if the mount fails or is not active, the service will not start. This combination is necessary because the mount is defined with `noauto` in fstab, meaning it is not automatically mounted at boot; the mount unit must be explicitly started (e.g., by a dependency or another unit) before the service.

Exam trap

The trap here is that candidates often confuse `Wants` with `Requires` or forget that `After` alone does not activate the mount unit, leading them to choose option C or D, which either provide weak dependencies or incorrect ordering.

How to eliminate wrong answers

Option B is wrong because `Before=mnt-nfs.mount` would order the service to start before the mount, which is the opposite of what is needed. Option C is wrong because `Wants=mnt-nfs.mount` is a weaker dependency (soft dependency) that does not enforce the mount to be active; the service could start even if the mount fails, which does not guarantee read-write access. Option D is wrong because `BindsTo=mnt-nfs.mount` creates a stronger binding where the service stops if the mount stops, but it does not include `Requires` to ensure the mount is started; additionally, `BindsTo` alone does not imply ordering, so the service might start before the mount without `After`.

Practice this question →
11
MCQmedium

Based on the exhibit, what is the correct interpretation?

A.The service is inactive
B.The configuration file is corrupt
C.The service is running but the unit file has been modified recently and needs reloading
D.The service is failing
AnswerC

Active (running) and warning indicate unit file change.

Why this answer

The 'daemon-reload' notice in the systemctl status output indicates that the unit file has been modified on disk but systemd has not yet reloaded its configuration. Running 'systemctl daemon-reload' will re-read the unit files and apply the changes, which is why option C is correct.

Exam trap

Linux Foundation often tests the distinction between a service that is running but has a pending configuration reload versus a service that has failed or is inactive, causing candidates to misinterpret the 'daemon-reload' notice as an error.

How to eliminate wrong answers

Option A is wrong because the output shows the service is 'active (running)', not inactive. Option B is wrong because a corrupt configuration file would typically cause a failure to start or a syntax error, not a 'daemon-reload' notice; the unit file is valid but has been changed. Option D is wrong because the service is running successfully with no indication of failure; the 'daemon-reload' notice is a warning about a pending reload, not a failure state.

Practice this question →
12
Multi-Selectmedium

Which TWO directives are typically used in a systemd service unit file to configure dependencies?

Select 2 answers
A.After
B.Wants
C.Before
D.Alias
E.Requires
AnswersB, E

Creates a weak dependency.

Why this answer

B is correct because the `Wants` directive in a systemd service unit file specifies a weaker dependency: the listed units are started if possible, but the current unit will still activate even if they fail. E is correct because the `Requires` directive creates a stronger dependency: the listed units must be successfully started for the current unit to start; if they fail, the current unit is deactivated. Both are fundamental for defining service dependencies in systemd.

Exam trap

The trap here is that candidates often confuse ordering directives (`After`, `Before`) with dependency directives (`Wants`, `Requires`), mistakenly thinking that specifying an order also implies a dependency, but systemd treats them as separate concepts that must be explicitly combined.

Practice this question →
13
MCQhard

A system administrator manages a database server service (database.service) that experiences periodic CPU spikes, causing excessive load on the server. The administrator wants to limit the service's CPU usage to 25% of a single CPU core. The service is running on a system with cgroup v2. Which directive should be added to the [Service] section of the unit file to achieve this?

A.CPUAccounting=true
B.CPUQuota=25%
C.CPUWeight=100
D.CPUShares=256
AnswerB

Sets a hard limit on CPU usage.

Why this answer

Option B is correct because in cgroup v2, the `CPUQuota=` directive in a systemd unit file directly limits the CPU time a service can use, expressed as a percentage of a single CPU core. Setting `CPUQuota=25%` restricts the service to using at most 25% of one core, which matches the administrator's requirement to cap CPU usage at 25% of a single core.

Exam trap

The trap here is that candidates often confuse `CPUQuota=` (a hard limit) with `CPUWeight=` or `CPUShares=` (relative priority settings), mistakenly thinking a weight or share value can enforce a specific percentage cap on CPU usage.

How to eliminate wrong answers

Option A is wrong because `CPUAccounting=true` enables CPU usage accounting and statistics for the service, but it does not impose any limit on CPU usage; it only tracks and reports usage. Option C is wrong because `CPUWeight=100` sets the relative scheduling priority (weight) for the service in cgroup v2, which influences how CPU time is distributed among competing services but does not enforce a hard cap on CPU usage. Option D is wrong because `CPUShares=` is a cgroup v1 directive that provides relative CPU weight, not a hard limit; in cgroup v2, it is replaced by `CPUWeight=`, and neither option can enforce a specific percentage cap like 25%.

Practice this question →
14
MCQhard

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

A.Requires=/var/lib/mysql
B.BindsTo=var-lib.mount
C.Before=var-lib.mount
D.After=var-lib.mount
AnswerD

After ensures the service starts after the mount unit.

Why this answer

Option D is correct because the `After=` directive in a systemd unit file specifies that the current unit should start only after the listed units have been activated. By setting `After=var-lib.mount`, the service will wait until the mount unit for `/var/lib/mysql` is fully mounted before starting, ensuring the required filesystem is available.

Exam trap

The trap here is that candidates confuse `After=` with `Requires=` or `BindsTo=`, thinking that dependency directives alone enforce startup order, but systemd separates ordering from dependency requirements.

How to eliminate wrong answers

Option A is wrong because `Requires=` declares a hard dependency that the required unit must be active for the current unit to start, but it does not enforce ordering; the service could start simultaneously or before the mount, leading to failure. Option B is wrong because `BindsTo=` creates a stronger dependency where the bound unit's failure stops the current unit, but it also does not guarantee ordering unless combined with `After=`, and the syntax `var-lib.mount` is correct for a mount unit but the directive alone does not ensure the mount happens first. Option C is wrong because `Before=` specifies that the current unit should start before the listed unit, which would cause the service to start before the mount, defeating the purpose of waiting for the filesystem.

Practice this question →
15
Multi-Selecteasy

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

Select 2 answers
A.systemd-analyze
B.service status
C.start stop restart
D.systemctl status
E.initctl status
AnswersB, D

Legacy command, still works with systemd via compatibility.

Why this answer

The `service` command is a legacy SysV init wrapper that can query the status of a service by calling the appropriate init script with the `status` argument. It remains available on many Linux distributions for backward compatibility, making it a valid tool to check service status.

Exam trap

The trap here is that candidates may think `systemd-analyze` checks service status because of its name, but it is strictly a boot analysis tool, not a status checker.

Practice this question →
16
MCQhard

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?

A.The 'systemctl enable' command only creates symlinks; a separate 'systemctl start' must be run after enable.
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.
C.The 'systemctl enable' command was not run as root.
D.The unit file has a syntax error that prevents systemd from parsing it.
AnswerB

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.

Why this answer

Option B is correct because the 'After=network.target' directive only specifies ordering, not a requirement. If the network target is not fully reached before the service starts, systemd will attempt to start the service once and, if it fails, 'Restart=on-failure' will restart it only if the start was successful but the process later exits with a failure. It does not retry the initial start if a dependency condition is not met.

The service must have 'Requires=network.target' or 'Wants=network.target' to ensure the target is active before the service starts.

Exam trap

The trap here is that candidates confuse 'After=' with a dependency directive, assuming ordering implies requirement, and overlook that 'Restart=on-failure' only applies to runtime failures, not initial start failures due to unmet conditions.

How to eliminate wrong answers

Option A is wrong because 'systemctl enable' creates symlinks to enable automatic start at boot, but the issue is that the service did not start after reboot despite being enabled; the administrator already ran 'systemctl enable', so the symlinks exist. Option C is wrong because 'systemctl enable' typically requires root privileges, but if it were not run as root, the command would have failed with a permission error, and the administrator would have noticed; the question states the command was run, implying it succeeded. Option D is wrong because if the unit file had a syntax error, 'systemctl enable' would have reported an error, and the service would not have been enabled; the administrator ran 'systemctl enable' without issue, and the service started manually, indicating the unit file is syntactically correct.

Practice this question →
17
MCQhard

A system administrator cannot restart a service because another unit 'stop' the request. The status message says 'Unit test.service is not running, but has pending stop job'. What is the most likely cause?

A.The service unit file has RefuseManualStop=yes
B.The service has a dependency that is stopping
C.A previous stop command is still being processed
D.The service is masked
AnswerC

A pending stop job means the stop is in progress; this can happen if the service is taking too long to stop.

Why this answer

The message 'Unit test.service is not running, but has pending stop job' indicates that systemd has queued a stop operation for the service, but the stop job has not yet completed. This typically happens when a previous 'systemctl stop' command was issued but the service's stop process (e.g., ExecStop script) is still running or hanging. Until that job finishes, any attempt to restart the service will be blocked because systemd serializes jobs for the same unit.

Exam trap

The trap here is that candidates confuse 'pending stop job' with a configuration error like masking or manual-stop refusal, when in fact it is a transient state caused by an incomplete stop operation.

How to eliminate wrong answers

Option A is wrong because RefuseManualStop=yes prevents manual stop commands entirely, but the status shows a stop job is pending, meaning a stop was initiated; RefuseManualStop would have rejected the stop request outright, not left it pending. Option B is wrong because a dependency stopping would affect the dependent unit's state, but the error message specifically refers to a pending stop job on test.service itself, not on a dependency. Option D is wrong because a masked service cannot be started or stopped at all; its unit file is symlinked to /dev/null, and attempting to stop it would fail immediately with a different error, not a pending stop job.

Practice this question →
18
MCQmedium

A system administrator configures a web server using systemd. After creating a custom service unit file, the administrator runs `systemctl daemon-reload` but the service still fails to start with a 'Unit not found' error. What is the most likely cause?

A.The administrator forgot to run `systemctl enable` before starting the service.
B.The unit file is placed in /usr/lib/systemd/system/ instead of /etc/systemd/system/.
C.The administrator is not in the 'systemd' group.
D.The service name was misspelled in the `systemctl start` command.
AnswerB

Unit files for custom services should be in /etc/systemd/system/; /usr/lib/systemd/system/ is for distribution-provided units.

Why this answer

The 'Unit not found' error after `systemctl daemon-reload` indicates that systemd cannot locate the unit file. Unit files in `/usr/lib/systemd/system/` are intended for distribution packages and are not automatically scanned by `daemon-reload` unless they are symlinked or the directory is explicitly included. The correct location for custom administrator-created unit files is `/etc/systemd/system/`, which is the primary location for locally managed units and is always included in the unit search path.

Exam trap

The trap here is that candidates assume any systemd directory works for custom units, but the LFCS exam specifically tests the distinction between vendor-provided units (`/usr/lib/`) and administrator-managed units (`/etc/`), and that `daemon-reload` does not automatically scan `/usr/lib/` for new files.

How to eliminate wrong answers

Option A is wrong because `systemctl enable` creates symlinks for automatic startup but is not required to start a service; `systemctl start` can start a service without enabling it. Option C is wrong because there is no 'systemd' group in standard Linux; systemd operations are controlled by user privileges (root or sudo) and polkit rules, not group membership. Option D is wrong because while a misspelled service name would cause a 'Unit not found' error, the question states the administrator created a custom unit file and ran `daemon-reload`, making the file location the more likely and fundamental issue.

Practice this question →
19
Multi-Selecthard

Which THREE of the following are valid systemd unit types?

Select 3 answers
A.notification
B.startup
C.target
D.socket
E.service
AnswersC, D, E

Groups units for synchronization.

Why this answer

Option C is correct because 'target' is a standard systemd unit type used to group other units together, similar to runlevels in SysVinit. Targets are defined in .target files and are essential for defining synchronization points during system boot or service state transitions.

Exam trap

The trap here is that candidates may confuse systemd unit types with service configuration directives (like Type=notify) or with generic terms like 'startup', leading them to select invalid options that sound plausible but are not defined in systemd's unit type specification.

Practice this question →
20
MCQmedium

A company runs an Apache HTTP server hosting multiple virtual hosts on a single server. The server is managed by systemd. After editing the configuration file for one of the virtual hosts, the administrator notices that the entire Apache service fails to start with a syntax error. Other virtual hosts are currently down because the service failed. The administrator must resolve the issue with minimal downtime and without affecting the configuration of the working virtual hosts. Which course of action is most appropriate?

A.Check the Apache error log to identify the syntax error, fix the configuration, and run 'systemctl restart httpd'.
B.Run 'systemctl restart httpd' immediately to apply the change; the error will be logged.
C.Run 'apachectl configtest' to validate all configurations, fix any reported errors, then run 'systemctl reload httpd'.
D.Disable the problematic virtual host file by renaming it, then restart Apache to bring up the other sites.
AnswerC

Correct: configtest checks syntax without starting; reload applies changes without full restart, minimizing downtime.

Why this answer

Using apachectl configtest to validate the configuration before restarting is the safest approach. It identifies syntax errors without affecting running services. Then the fix can be applied and a reload (or restart) performed.

Option A ignores validation and restarts, causing potential additional downtime if the error persists. Option B also restarts without validation. Option D disables the problematic site, but that may not be desired if the site is needed.

Practice this question →
21
MCQhard

An administrator configures a systemd service with Restart=on-failure and RestartSec=10. What happens if the service exits with a non-zero exit code?

A.It restarts immediately
B.It retries infinitely regardless of exit code
C.It does not restart
D.It waits 10 seconds before restarting
AnswerD

RestartSec defines the delay between restart attempts.

Why this answer

Option D is correct because when Restart=on-failure is set, systemd only restarts the service if it exits with a non-zero exit code or is terminated by a signal (excluding SIGHUP, SIGINT, SIGTERM, and SIGPIPE). The RestartSec=10 directive then introduces a 10-second delay before the restart attempt, preventing rapid restart loops and giving the system time to stabilize.

Exam trap

The trap here is that candidates often confuse Restart=on-failure with Restart=always, assuming any exit triggers a restart, or they forget that RestartSec applies even when Restart=on-failure is set, leading them to choose 'immediately' (Option A).

How to eliminate wrong answers

Option A is wrong because RestartSec=10 explicitly adds a 10-second delay; the service does not restart immediately. Option B is wrong because Restart=on-failure does not cause infinite retries for any exit code — it only triggers restarts on non-zero exit codes or certain signals, and the number of restart attempts is limited by StartLimitBurst and StartLimitInterval (default 5 attempts within 10 seconds). Option C is wrong because the service does restart on a non-zero exit code when Restart=on-failure is configured; it only does not restart if the exit code is zero.

Practice this question →
22
MCQmedium

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

A.CPUShares
B.CPUQuota
C.CPUAccounting=yes and CPUQuota
D.CPULimit
AnswerC

CPUAccounting enables accounting, then CPUQuota can be applied.

Why this answer

Option C is correct because to limit CPU usage in systemd, you must first enable CPU accounting with `CPUAccounting=yes` to track CPU consumption, and then set `CPUQuota` to specify a maximum percentage of CPU time the service can use. Without `CPUAccounting=yes`, the `CPUQuota` directive is ignored by systemd, making the combination essential for enforcing a hard CPU limit.

Exam trap

The trap here is that candidates assume `CPUQuota` works independently, but the LFCS exam tests the requirement to enable `CPUAccounting=yes` first, as systemd defaults to accounting being off for performance reasons.

How to eliminate wrong answers

Option A is wrong because `CPUShares` controls relative CPU priority among services under contention, not a hard limit on CPU usage; it distributes available CPU time proportionally. Option B is wrong because `CPUQuota` alone is insufficient; systemd requires `CPUAccounting=yes` to be explicitly set for the quota to take effect, otherwise the directive is silently ignored. Option D is wrong because `CPULimit` is not a valid systemd resource control directive; the correct directive for limiting CPU usage is `CPUQuota`.

Practice this question →
23
Multi-Selectmedium

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

Select 2 answers
A.Environment variables can be loaded using EnvFile= directive.
B.The default service type is 'forking'.
C.The [Service] section is mandatory for a service unit file.
D.The [Install] section is used by systemctl enable to create symlinks.
E.The [Service] section must appear before the [Unit] section.
AnswersC, D

A service unit must have a [Service] section to define the process.

Why this answer

Option C is correct because the [Service] section is mandatory in a systemd service unit file; without it, systemd cannot determine how to manage the service process. This section defines the service type, execution command, and other runtime parameters essential for the unit to function.

Exam trap

The trap here is that candidates often confuse the 'EnvironmentFile=' directive with a non-existent 'EnvFile=', and assume 'forking' is the default service type because many legacy daemons use it, but systemd's default is 'simple'.

Practice this question →
24
MCQmedium

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?

A.journalctl -u myapp.service
B.systemctl show myapp.service
C.journalctl -x -u myapp.service
D.systemctl list-dependencies myapp.service
AnswerA

This shows the full log for the service unit.

Why this answer

The correct command is `journalctl -u myapp.service` because it retrieves the full systemd journal logs for the specified unit, showing detailed error messages, stdout/stderr output, and timestamps that explain why the service exited with code 1. The `-u` flag filters the journal to entries related to that specific service unit, which is essential for debugging exit-code failures.

Exam trap

The trap here is that candidates may confuse `systemctl show` (which shows unit properties) with `journalctl` (which shows logs), or think that the `-x` flag in `journalctl` is required to see the full log when it only adds explanatory catalog messages, not the actual service output.

How to eliminate wrong answers

Option B is wrong because `systemctl show myapp.service` displays the current properties and configuration parameters of the unit (e.g., environment variables, resource limits), not the runtime log output or error messages. Option C is wrong because while `journalctl -x -u myapp.service` adds explanatory context (catalog messages) to the log, the `-x` flag is optional and not required to view the full log; the core command is still `journalctl -u myapp.service`, and the question asks for the command to view the full log, not necessarily with extra decoration. Option D is wrong because `systemctl list-dependencies myapp.service` shows the dependency tree of the unit (e.g., required mounts, sockets, other services), which is irrelevant to debugging the exit-code failure.

Practice this question →
25
MCQhard

A developer reports that a web application's logs are not being written to /var/log/myapp.log. The service runs as user 'myapp' and the log directory /var/log/myapp/ has permissions 755 owned by root. What is the most likely cause?

A.AppArmor is denying access.
B.SELinux is blocking the write.
C.The service is logging to systemd-journald instead of a file.
D.The service user 'myapp' does not have write permission to the log directory.
AnswerD

The directory is owned by root with 755, so only root can write; myapp needs write permission.

Why this answer

Option D is correct because the /var/log/myapp/ directory has permissions 755, which grants read and execute access to the 'others' category but not write. Since the service runs as user 'myapp', which is not the owner (root) and not in the root group, it falls under 'others' and thus lacks write permission. Without write permission on the directory, the service cannot create or write to /var/log/myapp.log, even if the file itself might have different permissions.

Exam trap

The trap here is that candidates may focus on file permissions of the log file itself rather than the directory permissions, or incorrectly assume that SELinux or AppArmor is the default cause for permission denials without evidence of their enforcement.

How to eliminate wrong answers

Option A is wrong because AppArmor is a Linux security module that uses profiles to restrict program capabilities, but there is no indication that AppArmor is enabled or that a profile is blocking the write; the issue is purely a filesystem permission problem. Option B is wrong because SELinux is a mandatory access control system that enforces security policies via contexts, but the question does not mention SELinux being enabled or any denial audit messages; the permissions 755 on the directory are the direct cause. Option C is wrong because while systemd-journald can capture logs, the developer explicitly states logs are not being written to /var/log/myapp.log, and the service configuration likely targets that file; the issue is not about the logging destination but the inability to write due to permissions.

Practice this question →
26
MCQmedium

Refer to the exhibit. The service unit file has Restart=on-failure, but systemctl show displays Restart=no. What is the most likely reason?

A.The User=backup directive overrides Restart.
B.The unit file was edited but systemctl daemon-reload was not run.
C.The unit is not enabled.
D.The Restart directive is only valid for Type=simple.
AnswerB

Without daemon-reload, systemctl show displays the previously loaded configuration.

Why this answer

The most likely reason is that the unit file was edited but `systemctl daemon-reload` was not executed. When a service unit file is modified, systemd does not automatically reload the configuration; it continues to use the cached version until `systemctl daemon-reload` is run. This explains why `systemctl show` displays `Restart=no` despite the file containing `Restart=on-failure`.

Exam trap

Linux Foundation often tests the distinction between editing a unit file and reloading the daemon, trapping candidates who assume changes take effect immediately without running `systemctl daemon-reload`.

How to eliminate wrong answers

Option A is wrong because the `User=` directive does not override the `Restart=` directive; `User=` specifies the user under which the service runs, while `Restart=` controls the restart policy, and they are independent settings. Option C is wrong because whether a unit is enabled (i.e., configured to start at boot) has no effect on the current runtime restart policy shown by `systemctl show`; `Restart=` is applied regardless of enablement status. Option D is wrong because the `Restart=` directive is valid for all service types, including `Type=simple`; there is no restriction that limits it to specific types.

Practice this question →
27
Drag & Dropmedium

Order the steps to create a new partition on a disk using fdisk.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

fdisk interactive commands: n, then specify type/number, then sectors, then w.

Practice this question →
28
MCQmedium

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?

A.systemctl disable service ; systemctl stop service
B.systemctl stop service && systemctl disable service
C.systemctl disable --now service
D.systemctl mask service
AnswerC

Stops and disables immediately.

Why this answer

Option C is correct because `systemctl disable --now service` both stops the service immediately and disables it from starting at boot in a single atomic command. This is the most efficient way to prevent boot delays caused by a failing service, as it combines the stop and disable actions without relying on shell operators that could fail if the first command exits with a non-zero status.

Exam trap

The trap here is that candidates often choose Option B because they think stopping the service first is safer, but they overlook that the `&&` operator will skip the disable if the stop fails, leaving the service enabled and potentially causing boot delays, whereas `systemctl disable --now` handles both actions reliably regardless of the stop command's exit status.

How to eliminate wrong answers

Option A is wrong because it uses a semicolon to run `systemctl disable service` before `systemctl stop service`, which means the disable command runs even if the stop command fails, but more critically, the order is reversed: disabling a running service does not stop it, so the service remains running until the stop command executes, and if the stop command fails, the service stays enabled. Option B is wrong because `systemctl stop service && systemctl disable service` uses a logical AND operator, so if the stop command fails (e.g., because the service is already stopped or fails to stop), the disable command never runs, leaving the service enabled and potentially causing boot delays. Option D is wrong because `systemctl mask service` creates a symlink to /dev/null that prevents the service from being started manually or by dependencies, but it does not stop a currently running service, so it does not address the immediate need to stop the failing service and prevent boot delays.

Practice this question →
29
MCQeasy

A system administrator is managing a web application running as a systemd service on a new Linux server. The application requires a specific environment variable, DATABASE_URL, to be set before starting. The administrator has created a custom service unit file at /etc/systemd/system/webapp.service with the following content: [Unit] Description=Web Application Service [Service] ExecStart=/usr/local/bin/webapp Restart=on-failure The administrator prefers to keep configuration separate from the unit file for easier updates. The service fails to start. Upon investigation, the administrator notices that the DATABASE_URL variable is not being passed to the process. What is the most appropriate course of action to ensure the environment variable is correctly set?

A.Add an Environment directive in the [Service] section: Environment=DATABASE_URL=value
B.Add EnvironmentFile=/etc/webapp.env in the [Service] section and place the variable in that file
C.Export the DATABASE_URL variable in the shell before running systemctl start webapp
D.Modify the ExecStart line to: ExecStart=/usr/bin/env DATABASE_URL=value /usr/local/bin/webapp
AnswerB

Keeps configuration separate, easy to update.

Why this answer

Option D is correct. Using EnvironmentFile allows the administrator to keep the variable in a separate file, which can be updated without modifying the unit file. Option A modifies ExecStart, which is not standard.

Option B hardcodes the variable in the unit file, reducing flexibility. Option C only sets the variable in the current shell session and does not persist for the service.

Practice this question →
30
MCQhard

A service unit has the directive 'ExecStartPre=/bin/true' and 'ExecStart=/usr/bin/myapp'. What is the effect of ExecStartPre?

A.It sets an environment variable.
B.It runs a post-start script.
C.It runs a pre-start script; if it fails, the service still starts.
D.It runs a pre-start script; if it fails, the service is not started.
AnswerD

ExecStartPre must exit with code 0 for the service to start.

Why this answer

ExecStartPre is a systemd directive that specifies a command to run before the main ExecStart command. If the ExecStartPre command fails (returns a non-zero exit code), systemd will not proceed to start the service, unless the '-' prefix is used to ignore failure. Here, /bin/true always succeeds (exit code 0), so it does not block the service, but the directive itself is designed to enforce a pre-start check.

Exam trap

The trap here is that candidates may confuse ExecStartPre with ExecStartPost or assume that a pre-start script failure is non-fatal, but systemd strictly enforces that a failed ExecStartPre prevents the service from starting unless explicitly configured otherwise.

How to eliminate wrong answers

Option A is wrong because ExecStartPre does not set environment variables; that is the role of Environment or EnvironmentFile directives. Option B is wrong because ExecStartPre runs before the main process, not after; ExecStartPost is the directive for post-start scripts. Option C is wrong because it states the service still starts if ExecStartPre fails; by default, systemd treats a failed ExecStartPre as a fatal error and does not start the service, unless the command is prefixed with '-' to allow failure.

Practice this question →
31
MCQhard

Refer to the exhibit. An administrator tries to start myapp.service with 'systemctl start myapp.service' but receives 'Failed to start myapp.service: Unit myapp.service is not loaded properly: Invalid argument'. What is the most likely issue?

A.The unit file has a syntax error.
B.The service name is misspelled.
C.The ExecStart path is invalid.
D.The service is masked.
AnswerA

'Invalid argument' indicates the unit file contains an incorrect directive or value.

Why this answer

The error 'Unit myapp.service is not loaded properly: Invalid argument' indicates that systemd attempted to parse the unit file but encountered a syntax error or an invalid directive. This typically happens when a key-value pair in the unit file is malformed, such as a missing equals sign, an unsupported option, or a value that does not conform to systemd's expected format. Unlike a runtime failure (e.g., a missing ExecStart binary), this error occurs during the loading phase, before any execution attempt.

Exam trap

Linux Foundation often tests the distinction between loading-phase errors (syntax, invalid argument) and runtime errors (execution failures, missing binaries), causing candidates to confuse a malformed unit file with a broken ExecStart path.

How to eliminate wrong answers

Option B is wrong because a misspelled service name would produce a 'Unit not found' error, not an 'Invalid argument' error, as systemd would not find a matching unit file. Option C is wrong because an invalid ExecStart path (e.g., a nonexistent binary) would cause a runtime failure after the unit is loaded, producing an error like 'main process exited, code=exited, status=203/EXEC' or 'Failed at step EXEC', not a loading-phase syntax error. Option D is wrong because a masked service would produce 'Failed to start myapp.service: Unit myapp.service is masked.' or 'Unit file is masked.', clearly indicating the masked state rather than an invalid argument.

Practice this question →
32
Multi-Selecteasy

A system administrator needs to ensure that a custom service named 'myapp.service' starts automatically after a reboot and also restarts automatically no matter how the service stops, even if it exits normally. Which two actions should the administrator take? (Choose two.)

Select 2 answers
A.Run 'systemctl mask myapp.service' to prevent manual stops.
B.Run 'systemctl enable myapp.service' to enable the service.
C.Set 'Restart=on-failure' in the [Service] section of the service file.
D.Set 'Restart=always' in the [Service] section of the service file.
E.Add 'After=network.target' to the [Unit] section of the service file.
AnswersB, D

Correct: Enabling creates symlinks for automatic start at boot.

Why this answer

To start automatically on boot, the service must be enabled via 'systemctl enable'. To restart on any exit, 'Restart=always' must be set in the service file. 'Restart=on-failure' does not cover normal exits; 'After' and 'mask' are irrelevant.

Practice this question →
33
Multi-Selecteasy

Which TWO commands can be used to check whether a systemd service is currently running?

Select 2 answers
A.systemctl status service
B.systemctl list-units --state=running
C.systemctl is-active service
D.systemctl is-enabled service
E.systemctl show service
AnswersA, C

Shows status including active/inactive state.

Why this answer

Option A is correct because `systemctl status service` displays the current status of a systemd unit, including whether it is active (running), along with recent log entries and process details. Option C is correct because `systemctl is-active service` returns a simple exit code and output (active/inactive) indicating whether the unit is currently running, making it ideal for scripting.

Exam trap

The trap here is that candidates often confuse 'is-enabled' (boot-time configuration) with 'is-active' (current runtime state), or think that listing all running units (option B) is a valid way to check a specific service, when in fact it requires additional parsing and does not directly answer the question.

Practice this question →
34
MCQmedium

A custom service requires that the network is fully operational before it starts. Which directive should be added to the [Unit] section of the service's unit file to ensure this dependency?

A.After=network-online.target
B.Requires=network.target
C.Wants=network-online.target
D.After=network.target
AnswerA

Ensures service starts after network is fully up.

Why this answer

Option A is correct because `After=network-online.target` ensures the service starts only after the network is fully operational, including IP address assignment and connectivity. This target is reached when network managers like systemd-networkd or NetworkManager confirm the network is online, making it suitable for services that require active network interfaces.

Exam trap

The trap here is that candidates confuse `network.target` (which is reached early and does not guarantee network readiness) with `network-online.target` (which waits for full network availability), leading them to pick option D or B incorrectly.

How to eliminate wrong answers

Option B is wrong because `Requires=network.target` only declares a dependency that the network target must be active, but it does not enforce ordering; the service could start before the network is fully online. Option C is wrong because `Wants=network-online.target` is a weaker dependency that does not guarantee the network is online before the service starts; it only attempts to start the target without failing if it cannot be reached. Option D is wrong because `After=network.target` orders the service after the basic network target, but `network.target` itself is reached early during boot before the network is fully configured, so the service may start before interfaces are ready.

Practice this question →
35
Multi-Selectmedium

Which TWO commands can be used to check the status of the sshd service on a system using systemd?

Select 2 answers
A.systemctl list-units --type=service
B.systemctl is-active sshd
C.systemctl is-enabled sshd
D.systemctl cat sshd
E.systemctl status sshd
AnswersB, E

Returns active/inactive/failed status.

Why this answer

Option B is correct because `systemctl is-active sshd` directly queries systemd to report whether the sshd service is currently in an active (running) state, returning a simple exit code and text output (e.g., 'active' or 'inactive'). Option E is correct because `systemctl status sshd` provides a comprehensive view of the service's current state, including whether it is active, its PID, recent log entries, and cgroup details, making it a standard command for checking service health on systemd-based systems.

Exam trap

The trap here is that candidates confuse `is-enabled` (boot-time configuration) with `is-active` (current runtime state), or they assume `list-units` is a valid status check when it actually requires additional filtering to isolate a specific service.

Practice this question →
36
MCQhard

An administrator wants to run a script daily at 2 AM. They create a timer unit and a service unit. The service unit uses Type=oneshot. Which of the following timer configurations is correct?

A.OnUnitActiveSec=24h
B.OnBootSec=1d
C.OnActiveSec=24h
D.OnCalendar=*-*-* 02:00:00
AnswerD

This sets a calendar event to run daily at 2:00 AM.

Why this answer

Option D is correct because `OnCalendar=*-*-* 02:00:00` specifies an absolute calendar event that triggers the timer at 2:00 AM every day, regardless of when the system booted or when the service last ran. This matches the requirement to run a script daily at a fixed time, and it works correctly with a `Type=oneshot` service unit.

Exam trap

The trap here is that candidates confuse `OnUnitActiveSec` (relative to last activation) with a fixed daily schedule, or they invent non-existent directives like `OnActiveSec`, while overlooking the correct `OnCalendar=` syntax for absolute time triggers.

How to eliminate wrong answers

Option A is wrong because `OnUnitActiveSec=24h` triggers the timer 24 hours after the service unit last became active, which would cause the execution time to drift if the service takes time to run or if it is manually triggered at a different time; it does not guarantee a fixed 2 AM execution. Option B is wrong because `OnBootSec=1d` triggers the timer once, 24 hours after system boot, and then never repeats; it does not create a daily recurring schedule. Option C is wrong because `OnActiveSec=24h` is not a valid systemd timer directive; the correct directive for relative time after activation is `OnUnitActiveSec`, and `OnActiveSec` does not exist in systemd timer units.

Practice this question →
37
MCQhard

Refer to the exhibit. A Linux administrator sees that 'myapp.service' is in a failed state with exit status 1. To troubleshoot, which command should the administrator use to view the full error output that the service produced before exiting?

A.systemctl status myapp.service
B.systemctl reload myapp.service
C.journalctl -u myapp.service
D.systemctl restart myapp.service
AnswerC

Correct: journalctl -u shows the complete journal for the unit, including all error output.

Why this answer

The journalctl command with the -u option shows all logs for the specified unit, including stdout/stderr captured by systemd. systemctl status only shows a brief log tail; restarting would remove the current state; reload does not affect failed units.

Practice this question →
38
MCQmedium

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?

A.Requires=network.target postgresql.service
B.Wants=network.target postgresql.service
C.BindsTo=network.target postgresql.service
D.After=network.target postgresql.service
AnswerD

After= ensures myapp starts after the listed units are active, combined with Wants= or Requires= for dependency.

Why this answer

Option D is correct because the `After=` directive in a systemd unit file specifies ordering constraints, ensuring that `myapp.service` starts only after `network.target` and `postgresql.service` have reached the 'started' state. This does not create a dependency that forces those units to start; it only orders the startup sequence, which is exactly what the administrator needs to guarantee the service starts after the network and PostgreSQL are available.

Exam trap

The trap here is that candidates often confuse ordering directives (`After=`, `Before=`) with dependency directives (`Requires=`, `Wants=`, `BindsTo=`), and assume that `Requires=` or `Wants=` automatically imply ordering, which they do not without an explicit `After=` or `Before=`.

How to eliminate wrong answers

Option A is wrong because `Requires=` creates a hard dependency that will cause `myapp.service` to fail if `network.target` or `postgresql.service` fail to start, but it does not enforce ordering; without `After=`, the units could start in parallel. Option B is wrong because `Wants=` creates a soft dependency that does not cause failure if the target units fail, but like `Requires=`, it does not impose any ordering constraint. Option C is wrong because `BindsTo=` creates a strong dependency where `myapp.service` will be stopped or restarted if the bound units stop or restart, and it also implies `Requires=` and `After=` behavior, but it is overly restrictive and not the standard directive for simple ordering; using `BindsTo=` would cause unintended side effects if PostgreSQL restarts.

Practice this question →
39
MCQeasy

Which systemd unit type is used to group services and other units together for boot execution?

A.socket
B.timer
C.service
D.target
AnswerD

target units group services and other units.

Why this answer

In systemd, the 'target' unit type is designed to group services, sockets, timers, and other units into a logical synchronization point for boot execution. Targets do not execute code themselves but instead define dependencies (via Wants, Requires, and After directives) that ensure all associated units are started in the correct order to reach a desired system state, such as multi-user.target or graphical.target.

Exam trap

The trap here is that candidates often confuse 'service' units with the concept of grouping, because services are the most common unit type, but they fail to recognize that only 'target' units can aggregate multiple units into a single boot synchronization point.

How to eliminate wrong answers

Option A is wrong because a 'socket' unit type is used for socket-based activation (e.g., listening on a TCP port or Unix socket), not for grouping units for boot execution. Option B is wrong because a 'timer' unit type schedules and triggers services based on time or calendar events, not for grouping units during boot. Option C is wrong because a 'service' unit type manages a single daemon or process, not a collection of units; grouping multiple services requires a target.

Practice this question →
40
Matchingmedium

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

1

2

9

15

19

Why these pairings

Standard signal numbers used in Linux.

Practice this question →
41
MCQhard

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?

A.Restart=on-success RestartSec=10
B.Restart=on-failure RestartSec=10
C.Restart=always RestartSec=10
D.RestartSec=10
AnswerB

Restarts the service only when it exits with a non-zero exit code or is terminated by a signal, with a 10-second delay.

Why this answer

Option B is correct because `Restart=on-failure` ensures the service restarts only when it exits with a non-zero exit code or is terminated by a signal (e.g., SIGKILL), which matches the 'crashes' scenario. Adding `RestartSec=10` introduces a 10-second delay before the restart attempt, as required. The other options either restart on success (irrelevant) or always restart (which would restart even on intentional stops), or omit the restart condition entirely.

Exam trap

The trap here is that candidates often confuse `Restart=on-failure` with `Restart=always`, not realizing that `always` restarts even on clean exits (e.g., `systemctl stop`), which would interfere with manual service management.

How to eliminate wrong answers

Option A is wrong because `Restart=on-success` triggers restarts only when the service exits with a zero exit code (success), which is the opposite of a crash condition. Option C is wrong because `Restart=always` restarts the service regardless of the exit status, including when the administrator manually stops it with `systemctl stop`, which is not desired for crash-only recovery. Option D is wrong because it only sets `RestartSec=10` without specifying a `Restart=` directive, so the default `Restart=no` applies and the service will never restart automatically.

Practice this question →
42
MCQmedium

An administrator runs 'systemctl status sshd' and sees the output above. The administrator wants sshd to start automatically at boot. Which command should be used?

A.systemctl reenable sshd
B.systemctl mask sshd
C.systemctl start sshd
D.systemctl enable sshd
AnswerD

Creates symlinks to enable the service to start at boot.

Why this answer

The `systemctl enable sshd` command creates the necessary symlinks in the systemd unit configuration directories (e.g., `/etc/systemd/system/multi-user.target.wants/`) so that the sshd service is started automatically at boot. This is the correct way to configure a service to start on boot in a systemd-based Linux distribution.

Exam trap

The trap here is confusing `systemctl start` (immediate runtime start) with `systemctl enable` (persistent boot-time start), leading candidates to choose Option C when the question explicitly asks for automatic startup at boot.

How to eliminate wrong answers

Option A is wrong because `systemctl reenable sshd` is not a valid systemd command; the correct command to re-enable a service is `systemctl enable sshd` (which removes and recreates symlinks if already enabled). Option B is wrong because `systemctl mask sshd` prevents the service from being started manually or automatically by linking it to `/dev/null`, which is the opposite of what is needed. Option C is wrong because `systemctl start sshd` starts the service immediately but does not configure it to start automatically at boot; it only affects the current runtime state.

Practice this question →
43
MCQeasy

Which command enables a service to start automatically at boot in a systemd-based system?

A.systemctl enable service
B.systemctl set-default service
C.systemctl daemon-reload
D.systemctl start service
AnswerA

Enables the service to start at boot.

Why this answer

The `systemctl enable` command creates the necessary symlinks in the `/etc/systemd/system/` directory tree (typically `multi-user.target.wants/`) to ensure the specified service unit is started automatically when the system boots. This is the standard mechanism in systemd to configure a service for automatic startup at boot time.

Exam trap

The trap here is confusing `systemctl enable` (which configures automatic boot-time startup) with `systemctl start` (which runs the service immediately but does not persist across reboots), leading candidates to incorrectly choose option D.

How to eliminate wrong answers

Option B is wrong because `systemctl set-default` sets the default target (e.g., `multi-user.target` or `graphical.target`), not a service; it controls which target the system boots into, not individual service autostart. Option C is wrong because `systemctl daemon-reload` reloads systemd manager configuration after unit file changes but does not enable or disable any service for boot-time startup. Option D is wrong because `systemctl start` immediately starts a service in the current session but does not configure it to start automatically at future boots.

Practice this question →
44
MCQeasy

A system administrator wants to configure a custom service to start automatically at boot. Which command accomplishes this?

A.systemctl daemon-reload custom.service
B.systemctl enable custom.service
C.systemctl reenable custom.service
D.systemctl start custom.service
AnswerB

systemctl enable creates symlinks to start the service at boot.

Why this answer

The `systemctl enable custom.service` command creates the necessary symlinks in the systemd unit file directories (e.g., `/etc/systemd/system/multi-user.target.wants/`) so that the service is automatically started at boot. This is the correct method to configure a custom service for automatic startup in a systemd-based Linux distribution.

Exam trap

The trap here is that candidates confuse `systemctl start` (immediate runtime start) with `systemctl enable` (boot-time persistence), leading them to select option D when the question specifically asks for automatic boot-time configuration.

How to eliminate wrong answers

Option A is wrong because `systemctl daemon-reload` reloads the systemd manager configuration after unit files have been changed, but it does not enable a service to start at boot. Option C is wrong because `systemctl reenable` removes and then recreates the enablement symlinks, which is useful for resetting the enablement state but is not the standard command for initially enabling a service. Option D is wrong because `systemctl start` immediately starts the service in the current session but does not configure it to start automatically at boot.

Practice this question →
45
Multi-Selectmedium

Which THREE of the following are valid directives for the [Service] section of a systemd unit file?

Select 3 answers
A.Type
B.Requires
C.User
D.ExecStart
E.Description
AnswersA, C, D

Valid [Service] directive to define service type.

Why this answer

The `Type` directive is valid in the `[Service]` section because it defines the service's process startup type (e.g., `simple`, `forking`, `oneshot`, `dbus`, `notify`, `idle`). This tells systemd how to monitor the service's main process and determine when it has started successfully, which is essential for proper service management.

Exam trap

The trap here is that candidates often confuse `[Unit]` directives (like `Requires`, `Description`, `After`) with `[Service]` directives, leading them to select options that are valid in other sections but not in the `[Service]` block.

Practice this question →
46
MCQeasy

A Linux administrator needs to temporarily stop a service named 'httpd' without disabling it from starting automatically on subsequent boots. Which command should be used?

A.systemctl stop httpd
B.systemctl mask httpd
C.systemctl disable httpd
D.systemctl kill httpd
AnswerA

Stops the service immediately without changing its enable status.

Why this answer

The `systemctl stop httpd` command sends a SIGTERM signal to the main process of the httpd service, causing it to stop immediately. This action does not modify the service's enablement state, so the service will still start automatically on subsequent boots if it is enabled. This is the correct way to temporarily stop a service without altering its boot-time behavior.

Exam trap

The trap here is that candidates confuse 'stop' with 'disable' or 'mask', thinking that stopping a service also prevents it from starting at boot, when in fact 'stop' only affects the current runtime state and has no effect on boot-time enablement.

How to eliminate wrong answers

Option B is wrong because `systemctl mask httpd` creates a symlink to /dev/null, which prevents the service from being started manually or automatically, even by dependencies, and is not temporary — it requires unmasking to reverse. Option C is wrong because `systemctl disable httpd` removes the symlinks that cause the service to start at boot, permanently altering its enablement state until re-enabled. Option D is wrong because `systemctl kill httpd` sends a signal (default SIGTERM) to the service's control group, but it is not the standard command for stopping a service; it is used for sending arbitrary signals or killing specific processes, and it does not manage the service's unit state or dependencies properly.

Practice this question →
47
MCQhard

A company runs a web application stack consisting of a frontend web server (web.service) and a backend application server (app.service). The app.service uses Restart=on-failure to automatically restart if it crashes. The administrator wants the web.service to automatically restart whenever app.service restarts, so that the frontend remains in sync with the backend. Which directive should be added to the web.service unit file's [Unit] section to achieve this?

A.BindsTo=app.service
B.PartOf=app.service
C.Requires=app.service
D.Wants=app.service
AnswerB

Propagates stop/restart from app.service to web.service.

Why this answer

Option B (PartOf=app.service) is correct because when app.service stops or restarts, PartOf causes systemd to stop or restart web.service as well, keeping the frontend in sync with the backend. Unlike BindsTo, PartOf does not create a strict dependency that would prevent app.service from starting independently, and it ensures the frontend follows the backend's state changes without requiring the backend to be fully operational for the frontend to start.

Exam trap

The trap here is that candidates confuse PartOf with BindsTo, assuming the stronger dependency is always better, but PartOf is the correct choice because it only propagates restarts without creating a hard binding that would prevent independent startup or cause the frontend to be stopped if the backend fails.

How to eliminate wrong answers

Option A (BindsTo=app.service) is wrong because BindsTo creates a stronger dependency where web.service would be bound to the lifecycle of app.service, and if app.service fails or stops, web.service would be forcefully stopped and could not be started independently; this is too restrictive for a frontend that should only restart when the backend restarts, not be permanently tied. Option C (Requires=app.service) is wrong because Requires only ensures that app.service is started when web.service starts, but it does not cause web.service to restart when app.service restarts; it only activates the dependency at startup. Option D (Wants=app.service) is wrong because Wants is a weaker form of Requires that does not enforce any restart behavior; it merely attempts to start app.service alongside web.service but does not propagate restarts or stops.

Practice this question →
48
MCQeasy

Which command displays the current status of all active services?

A.systemctl list-units --type=service --state=active
B.systemctl status --all
C.systemctl show --type=service
D.systemctl list-unit-files --type=service
AnswerA

This command filters for active services only.

Why this answer

Option A is correct because `systemctl list-units --type=service --state=active` filters systemd units to show only those of type 'service' that are currently in the 'active' state (i.e., running or exited but still considered active). This is the precise command to list all active services without showing inactive or failed units.

Exam trap

The trap here is that candidates often confuse `systemctl status --all` (which shows all units regardless of state) with listing only active services, or they mistakenly think `systemctl list-unit-files` shows current runtime status instead of disk-based enablement configuration.

How to eliminate wrong answers

Option B is wrong because `systemctl status --all` shows the status of all units (including non-service types like sockets, timers, and mounts) and includes inactive and failed units, not just active services. Option C is wrong because `systemctl show --type=service` displays detailed properties/parameters of service units (like environment variables or resource limits) rather than their current runtime status. Option D is wrong because `systemctl list-unit-files --type=service` lists the enablement state (enabled/disabled/static) of service unit files on disk, not their current active/inactive runtime status.

Practice this question →
49
MCQmedium

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?

A.Replace After=network.target with After=network-online.target and add Requires=network-online.target
B.Add a dependency: After=nss-lookup.target
C.Add Before=network.target to delay the start
D.Set Type=idle in the [Service] section
AnswerB

Ensures name resolution services are available.

Why this answer

Option B is correct because `nss-lookup.target` is a synchronization point that indicates the hostname resolution subsystem (including DNS) is fully operational. By adding `After=nss-lookup.target`, the monitor service will not start until DNS resolution is available, solving the hostname resolution failures. The existing `Wants=network.target` is insufficient because `network.target` only signals that basic network interfaces are configured, not that DNS services are ready.

Exam trap

The trap here is that candidates confuse `network-online.target` with DNS readiness, assuming network connectivity automatically implies DNS resolution is available, but DNS is a separate service that may not be synchronized with network interface activation.

How to eliminate wrong answers

Option A is wrong because `network-online.target` ensures the network stack is fully up (e.g., IP addresses assigned), but it does not guarantee DNS resolution is ready; DNS is a separate subsystem. Option C is wrong because `Before=network.target` would attempt to start the monitor service before the network is up, making the DNS problem worse. Option D is wrong because `Type=idle` only delays the service start until all other jobs are dispatched, but it does not wait for DNS readiness; it is a scheduling hint, not a dependency.

Practice this question →
50
MCQmedium

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

A.The service is stopped when multi-user.target is stopped.
B.The service conflicts with multi-user.target.
C.The service is automatically started when the system enters multi-user.target.
D.The service is enabled by symlinking in multi-user.target.wants.
AnswerD

WantedBy= creates a symlink in the .wants directory of the target when the service is enabled.

Why this answer

The `WantedBy=multi-user.target` directive in the `[Install]` section of a systemd service unit file does not directly start the service when the target is entered. Instead, when the service is enabled (via `systemctl enable`), systemd creates a symbolic link from the service unit file into the `multi-user.target.wants/` directory. This symlink causes systemd to automatically start the service as a dependency when `multi-user.target` is activated, effectively enabling the service for that target.

Exam trap

The trap here is that candidates confuse the declarative `WantedBy` directive with an immediate start action (Option C), when in fact it only defines a dependency relationship that takes effect after the service is enabled via symlinking.

How to eliminate wrong answers

Option A is wrong because `WantedBy` does not define a stop behavior; stopping the target stops the service only if the service has a `PartOf=` or `BindsTo=` relationship, not from `WantedBy` alone. Option B is wrong because `WantedBy` establishes a weak dependency (a 'wants' relationship), not a conflict; a conflict would require `Conflicts=` in the `[Unit]` section. Option C is wrong because `WantedBy` does not directly start the service upon entering the target; it only causes the service to be pulled in as a dependency when the target is activated, which happens only if the service is enabled (symlinked).

Practice this question →
51
MCQmedium

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

A.The OPTIONS environment variable is not set.
B.The service is not enabled to start at boot.
C.There is a syntax error in the unit file.
D.The sshd_config file is misconfigured.
AnswerD

sshd exiting with 255 often indicates bad configuration.

Why this answer

The exhibit shows that the sshd service fails to start, and the most likely cause is a misconfiguration in the sshd_config file. When sshd is started via systemd, a syntax error or invalid directive in /etc/ssh/sshd_config will cause the daemon to exit immediately, resulting in a failed status. This is a common issue because sshd validates its configuration file at startup and will refuse to run if it finds an error.

Exam trap

The trap here is that candidates often assume a unit file syntax error (Option C) is the cause, but systemd unit files are parsed before the service runs, so a unit file error would prevent the service from starting at all, whereas a misconfigured sshd_config allows the unit to start but causes the daemon to exit immediately after parsing the config.

How to eliminate wrong answers

Option A is wrong because the OPTIONS environment variable is not a standard systemd or sshd mechanism; sshd uses command-line arguments or the sshd_config file, not an OPTIONS variable. Option B is wrong because the service not being enabled to start at boot would not cause a failure when manually starting the service; it would simply not start automatically on boot, but 'systemctl start sshd' would still succeed if the configuration is valid. Option C is wrong because a syntax error in the unit file would typically produce a specific systemd error message (e.g., 'Failed to parse unit file') and would prevent the service from being started at all, whereas the exhibit likely shows a failure after the unit file is parsed successfully.

Practice this question →
52
MCQhard

A server runs a custom application that listens on TCP port 8080. The administrator wants to ensure the application starts automatically on boot and restarts if it crashes. Which systemd unit file directive should be used to achieve the restart behavior?

A.RestartSec=5
B.Type=notify
C.RemainAfterExit=yes
D.Restart=on-failure
AnswerD

This directive tells systemd to restart the service when it exits unexpectedly.

Why this answer

The `Restart=on-failure` directive in a systemd unit file instructs systemd to automatically restart the service unit when it exits with a non-zero exit code, is terminated by a signal (including SIGKILL), or times out. This directly satisfies the requirement for the application to restart if it crashes, as a crash typically results in an unclean exit that triggers the restart condition.

Exam trap

The trap here is that candidates often confuse `RestartSec` with the restart policy itself, or assume `Type=notify` or `RemainAfterExit=yes` imply automatic restart behavior, when in fact only `Restart=` directives control restart logic.

How to eliminate wrong answers

Option A is wrong because `RestartSec=5` specifies a delay (5 seconds) before attempting a restart, but it does not enable restart behavior on its own; it only modifies the timing if a restart is already configured via `Restart=`. Option B is wrong because `Type=notify` tells systemd that the service will send a notification (via sd_notify) when it is fully started, but it has no effect on restart behavior after a crash. Option C is wrong because `RemainAfterExit=yes` makes systemd consider the service as active even after the main process exits, which is used for one-shot services that set up state; it does not cause automatic restarts on failure.

Practice this question →
53
Multi-Selectmedium

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

Select 2 answers
A.The socket unit file must have an [Install] section.
B.Socket activation requires the service to be of type 'socket'.
C.The service unit must include 'Sockets=<socket unit>' to bind the service to the socket.
D.A service can be started on demand when a connection arrives on a socket.
E.Socket activation only works with TCP sockets.
AnswersC, D

This directive links the service to the socket unit.

Why this answer

Option C is correct because the service unit must include a 'Sockets=' directive (e.g., 'Sockets=myapp.socket') to explicitly bind the service to the corresponding socket unit. This tells systemd which socket(s) the service should accept connections from when activated. Without this directive, the service will not receive the file descriptors for the socket, and activation will fail.

Exam trap

The trap here is that candidates often confuse the 'Type=' directive in the service unit (e.g., 'Type=socket') with the socket unit's role, leading them to incorrectly select Option B, when in fact the service type is independent of socket activation.

Practice this question →
54
Multi-Selecthard

Which THREE actions will affect the state of a systemd service that is currently running? (Choose three.)

Select 3 answers
A.systemctl kill myapp.service
B.systemctl reload myapp.service
C.systemctl disable myapp.service
D.systemctl daemon-reload
E.systemctl stop myapp.service
AnswersA, B, E

Sends a signal to the service process.

Why this answer

Option A is correct because `systemctl kill myapp.service` sends a signal (default SIGTERM) to the main process of the running service, which can terminate or alter its state. This directly changes the service from a running state to a stopped or failed state depending on the signal and process behavior.

Exam trap

The trap here is that candidates often confuse `disable` (which only affects future boots) with `stop` (which affects the current runtime state), or think `daemon-reload` immediately impacts running services when it only updates unit definitions for subsequent operations.

Practice this question →
55
MCQhard

An administrator wants to limit the CPU usage of a service to at most 50% of a single CPU core. Which directive should be set in the [Service] section of the unit file?

A.CPUQuota=50%
B.CPUAccounting=true
C.CPUWeight=100
D.CPUShares=512
AnswerA

Sets a hard limit of 50% CPU time.

Why this answer

Option A is correct because `CPUQuota=` is the systemd directive that limits the CPU time a service can use, expressed as a percentage of a single CPU core. Setting `CPUQuota=50%` restricts the service to at most 50% of one core's time, effectively capping its CPU usage to half a core.

Exam trap

The trap here is that candidates often confuse relative CPU shares (like `CPUWeight` or `CPUShares`) with absolute CPU limits (`CPUQuota`), or mistakenly think `CPUAccounting=true` alone restricts CPU usage.

How to eliminate wrong answers

Option B is wrong because `CPUAccounting=true` enables CPU usage tracking and accounting for the unit, but it does not impose any limit on CPU usage. Option C is wrong because `CPUWeight=100` sets the relative weight for CPU time distribution among competing services under the CFS scheduler, not a hard limit. Option D is wrong because `CPUShares=512` is a legacy cgroup v1 parameter that also controls relative CPU share, not an absolute cap, and is deprecated in favor of `CPUWeight` in cgroup v2.

Practice this question →
56
MCQhard

Which of the following statements is true about this unit?

A.The service will be restarted indefinitely with a 10-second delay between restarts regardless of exit status
B.The service can be started by a timer unit
C.The service will start automatically at boot only if network-online.target is reached
D.The service requires SELinux context
AnswerA

Restart=always triggers on any exit, with RestartSec delay.

Why this answer

Option A is correct because the `Restart=always` directive in a systemd service unit causes the service to be restarted indefinitely regardless of the exit status, and the `RestartSec=10` directive introduces a 10-second delay between each restart attempt. This behavior is defined in the systemd.service(5) man page, where `Restart=always` triggers a restart for any exit reason, including clean exits or signals.

Exam trap

Linux Foundation often tests the misconception that `Restart=always` only applies to non-zero exit codes, when in fact it triggers restarts for any exit status, including successful exits (exit code 0).

How to eliminate wrong answers

Option B is wrong because the question does not provide any evidence of a timer unit (e.g., a `.timer` file) being associated with this service; a timer unit is a separate systemd unit that must be explicitly configured and enabled to start a service on a schedule. Option C is wrong because the service unit does not include `Wants=network-online.target` or `After=network-online.target` in the `[Unit]` section, nor does it specify `Requires=network-online.target`; without such directives, the service is not dependent on network-online.target for boot-time startup. Option D is wrong because SELinux context is not a requirement of systemd service units; SELinux policies may apply to the service's executable or files, but the unit file itself does not require an SELinux context to function.

Practice this question →
57
MCQeasy

An administrator needs to configure a service to run as a non-root user for security reasons. Which systemd unit file directive accomplishes this?

A.AmbientCapabilities=CAP_NET_BIND_SERVICE
B.DynamicUser=yes
C.User=myuser
D.Group=myuser
AnswerC

User= specifies the username or UID to run the service.

Why this answer

Option C is correct because the `User=` directive in a systemd unit file specifies the user (by name or UID) under which the service process runs. By setting `User=myuser`, the service executes with the privileges of that non-root user, reducing the attack surface and adhering to the principle of least privilege. This is the standard systemd mechanism for dropping root privileges for a service.

Exam trap

The trap here is that candidates often confuse `User=` with `Group=` or assume that `DynamicUser=yes` is the only way to run as a non-root user, missing that `User=` directly specifies a static, named user account.

How to eliminate wrong answers

Option A is wrong because `AmbientCapabilities=CAP_NET_BIND_SERVICE` grants a specific capability (binding to privileged ports below 1024) to the service, but it does not change the user context; the service would still run as root unless a `User=` directive is also used. Option B is wrong because `DynamicUser=yes` creates a transient, ephemeral user and group for the service, but it does not allow you to specify a particular non-root user like 'myuser'; it is intended for services that need isolated, temporary credentials. Option D is wrong because `Group=myuser` sets the group ID for the service but does not change the user; the service would still run as root (or whatever user is set by `User=`) unless `User=` is also specified.

Practice this question →
58
MCQeasy

To check the details of a failed systemd service unit, including the last log entries, which command is most appropriate?

A.systemctl status service
B.systemctl list-units --failed
C.systemctl is-failed service
D.systemctl show service
AnswerA

Shows current state and last log lines.

Why this answer

`systemctl status service` is the most appropriate command because it displays the current state of the service unit, including whether it is active, failed, or inactive, along with the last several log entries from the journal for that unit. This provides both the failure status and the contextual log output needed to diagnose why the service failed, all in a single command.

Exam trap

The trap here is that candidates often confuse `systemctl is-failed` (which only checks the failure state) with `systemctl status` (which provides both the state and the logs), leading them to choose a command that gives insufficient diagnostic information for the question's requirement of 'including the last log entries'.

How to eliminate wrong answers

Option B is wrong because `systemctl list-units --failed` only lists all failed units without showing the detailed status or log entries for a specific service. Option C is wrong because `systemctl is-failed service` only returns a simple exit code or string ('failed' or 'active') indicating whether the unit is in a failed state, but it does not provide any log entries or detailed failure information. Option D is wrong because `systemctl show service` displays all unit properties (such as environment variables, resource limits, and dependency information) in a structured key-value format, but it does not include the recent log entries needed for troubleshooting a failure.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Service Configuration questions.

Start 20-question session