Courseiva

CCNA Service Configuration Questions

57 questions · Service Configuration · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

A Linux administrator needs to ensure that the nginx.service is restarted automatically if it crashes, but only after a 10-second delay, and that it does not restart more than 5 times within 1 minute to avoid a restart loop. Which set of directives in the [Service] section achieves this?

A.Restart=on-failure, RestartSec=10, StartLimitIntervalSec=60, StartLimitBurst=10
B.Restart=on-failure, RestartSec=10, StartLimitIntervalSec=60, StartLimitBurst=5
C.Restart=always, RestartSec=10, StartLimitInterval=60, StartLimitBurst=5
D.Restart=on-abnormal, RestartSec=10, StartLimitIntervalSec=60, StartLimitBurst=5
AnswerB

Restart=on-failure restarts the service only when it exits with a non-zero status or is killed by a signal. RestartSec=10 sets a 10-second delay before restarting. StartLimitIntervalSec=60 and StartLimitBurst=5 limit restarts to 5 within 60 seconds, preventing loops. This combination exactly matches the requirements.

Why this answer

The correct directives are Restart=on-failure, RestartSec=10, StartLimitIntervalSec=60, and StartLimitBurst=5. Restart=on-failure ensures restarts only on crashes, RestartSec=10 adds the delay, and the start limit directives restrict restarts to 5 per 60 seconds. The other options either use the wrong restart policy, an outdated directive name, or an incorrect burst value.

Exam trap

The trap here is using StartLimitInterval instead of StartLimitIntervalSec, or confusing StartLimitBurst with the number of restarts allowed within the interval.

Practice this question →
2
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

'Exec format error' occurs when the kernel cannot execute the binary, typically because the ExecStart path is wrong or a script lacks its shebang line. The kernel then cannot identify an interpreter, so execution fails before the service runs.

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 →
3
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

`systemctl daemon-reload` forces systemd to re-read all unit files and rebuild its dependency tree, so the edited service definition is picked up without a reboot. Running `systemctl restart` alone reuses the cached unit, leaving your changes ignored. This satisfies the stem's requirement that modifications take effect.

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 →
4
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

The enable subcommand creates the persistent symlink that ties httpd into the boot target, so systemd starts it automatically at every boot. Start alone only launches the service for the current session, failing the boot-persistence requirement.

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 →
5
MCQeasy

A system administrator needs to configure a new systemd service unit file for a custom application. The service should start after the network is fully online and requires the /opt/data directory to be mounted. Which section of the unit file should contain the After= and Requires= directives to define these dependencies?

A.[Path]
B.[Install]
C.[Unit]
D.[Service]
AnswerC

The [Unit] section contains generic unit configuration options, including dependency ordering (After, Before) and requirement (Requires, Wants). Directives like After=network-online.target and RequiresMountsFor=/opt/data belong here because they define relationships with other units and mount points, not service execution parameters.

Why this answer

Dependency and ordering directives such as After= and Requires= are placed in the [Unit] section because they describe the unit's relationships with other units and targets. The [Service] section is for execution parameters, [Install] for enabling, and [Path] for path units. Thus, [Unit] is correct.

Exam trap

The trap here is assuming that all directives related to a service go in the [Service] section, but dependency directives are unit-level and belong in [Unit].

Practice this question →
6
Multi-Selecthard

A Linux administrator is configuring a systemd service unit for a database application. The administrator needs to ensure that the service is automatically restarted if it crashes, but only after a 10-second delay, and that the restart is not attempted if the service is explicitly stopped by an administrator. Which two directives should be used in the [Service] section to achieve these requirements? (Choose two.)

Select 2 answers
A.Restart=always
B.RestartSec=10
C.StartLimitIntervalSec=10
D.Restart=on-failure
E.RestartPreventExitStatus=0
AnswersB, D

RestartSec=10 sets the delay between the service stopping and systemd attempting to restart it. This directly satisfies the requirement for a 10-second delay before restart. It works in conjunction with Restart= to control the timing of automatic restarts, making it the second correct directive for this scenario.

Why this answer

To automatically restart a service after a crash but not after an explicit stop, Restart=on-failure is the appropriate setting because it restarts only on abnormal termination. To introduce a 10-second delay before each restart attempt, RestartSec=10 is used. Together, these directives ensure the service restarts after crashes with a delay, but remains stopped when an administrator issues systemctl stop.

Other options either restart too broadly or do not control the delay.

Exam trap

The trap here is selecting Restart=always, which seems to ensure restarts but also restarts the service after an administrator intentionally stops it, contrary to the requirement.

Practice this question →
7
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

systemctl enable creates the symlinks defined by the unit's [Install] section, wiring myapp.service into the appropriate target's .wants directory so systemd starts it at boot. Starting it immediately would instead require systemctl start, which does not persist across reboots.

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 →
8
MCQhard

A Linux administrator is managing a systemd service called app.service that runs a Java application. The service is configured with Restart=on-failure and RestartSec=5. After a recent update, the application crashes immediately upon start with exit code 1. The administrator notices that systemd keeps restarting the service every 5 seconds indefinitely. Which command should the administrator use to view the number of times the service has been restarted and the current restart limit status?

A.journalctl -u app.service -n 50
B.systemctl status app.service
C.systemctl show app.service -p NRestarts -p StartLimitBurst -p StartLimitIntervalSec
D.systemctl list-units --state=failed
AnswerC

systemctl show with -p (property) can display specific properties. NRestarts shows the number of automatic restarts, StartLimitBurst and StartLimitIntervalSec show the rate limiting parameters. This command provides exactly the restart count and limit configuration, helping diagnose the restart loop.

Why this answer

To see the number of restarts and the restart limit configuration, systemctl show with specific properties is the correct tool. NRestarts gives the count, while StartLimitBurst and StartLimitIntervalSec define the rate limiting. Other commands provide logs or status but not these internal counters.

Exam trap

The trap here is assuming that systemctl status or journalctl will show the restart count, but only systemctl show exposes the NRestarts property and limit settings.

Practice this question →
9
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

The User directive in the [Service] section specifies the UNIX account the service process runs as, directly satisfying the requirement to run the service under a specific user rather than root or the default system account.

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 →
10
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

journalctl -u webserver.service queries the systemd journal filtered by the unit name, returning that service's logged output, including recent failure messages. The -u flag restricts entries to the specified unit, directly satisfying the requirement to isolate webserver.service errors rather than scanning the entire journal.

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 →
11
MCQmedium

A Linux administrator is troubleshooting a custom systemd service named data-sync.service that repeatedly fails with the error 'start request repeated too quickly'. The unit file has Restart=always and RestartSec=5. Which command should the administrator use to reset the failed state and clear the restart counter so the service can be started again?

A.systemctl reset-failed data-sync.service
B.systemctl daemon-reload
C.systemctl restart data-sync.service
D.systemctl kill data-sync.service
AnswerA

This command resets the failed state of the unit and clears the restart counter maintained by systemd. When a service hits the start limit (default: 5 starts within 10 seconds), systemd refuses further starts until the counter is reset. After running this, the administrator can successfully start the service again with systemctl start.

Why this answer

When a systemd service is configured with Restart=always and crashes repeatedly, systemd enforces a start limit (default 5 starts in 10 seconds) and then refuses further starts with the error 'start request repeated too quickly'. To recover, the administrator must clear the failed state and restart counter using systemctl reset-failed, after which the service can be started normally. This command is specifically designed for this purpose and is the correct tool for the scenario.

Exam trap

The trap here is assuming that restarting the service will automatically clear the failure after the restart delay, but systemd maintains a persistent start counter that must be explicitly reset.

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

Wants establishes a weak dependency: systemd starts the wanted unit when this service starts, but failure of that unit does not stop this one. It satisfies the requirement for a dependency directive while tolerating the target's absence, unlike Requires, which enforces a strict dependency.

Why this answer

In a systemd unit file, Wants= (option B) and Requires= (option E) are dependency directives that pull in other units: Wants= establishes a weak dependency where the listed units are started if possible but failure does not stop this unit, while Requires= establishes a strong dependency where the listed units must be activated successfully or this unit fails. Both belong to the [Unit] section and define which other units are needed, which is exactly what the question asks. By contrast, After= (option A) and Before= (option C) only control ordering — they specify start/stop sequence relative to other units but do not create a dependency that pulls those units in.

Alias= (option D) merely provides an alternative name for the unit and has nothing to do with dependencies.

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

CPUQuota constrains aggregate CPU time within the cgroup v2 hierarchy, expressed as a percentage of one core. Setting CPUQuota=25% caps database.service at a quarter of a single CPU, directly limiting the spikes causing excessive load.

Why this answer

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
MCQeasy

A system administrator wants to view the current runtime status of the sshd.service, including whether it is active, its main PID, and recent log entries. Which command should they use?

A.systemctl show sshd.service
B.systemctl status sshd.service
C.journalctl -u sshd.service -f
D.systemctl list-units --type=service | grep sshd
AnswerB

systemctl status sshd.service displays the current state of the service, including whether it is active, the main PID, and the most recent log lines. This directly provides the runtime status and recent logs as requested. It is the standard command for checking a service's health and recent activity in systemd.

Why this answer

systemctl status sshd.service is the correct command because it provides a concise overview of the service's current state, including active/inactive, main PID, and the last few log lines. It combines status and recent logs in one output, exactly matching the administrator's need. Other commands either only show logs or only list units without detailed status.

Exam trap

The trap here is thinking that journalctl -u sshd.service -f shows the current status, when it only follows logs and does not display the service state.

Practice this question →
15
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 systemd has queued the stop operation but the unit has not yet reached an inactive state, so a restart request is refused until that job completes. This directly matches the "pending stop job" status, indicating the earlier stop command is still being processed.

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 →
16
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.
AnswerD

systemd resolves units by exact filename, so a typographical error in the unit name passed to systemctl start yields 'Unit not found' even after daemon-reload succeeds. Verifying the spelling against the unit file in /etc/systemd/system corrects the invocation.

Why this answer

The 'Unit not found' error after `systemctl daemon-reload` typically indicates that systemd cannot locate a unit with the specified name. While correct placement of unit files is important, systemd scans both /etc/systemd/system/ and /usr/lib/systemd/system/ after a daemon-reload. Therefore, placing a custom unit in /usr/lib/systemd/system/ would not cause this error.

The most likely cause is that the service name was misspelled in the `systemctl start` command. A simple typo would lead to a 'Unit not found' message because systemd looks for an exact match. Other options like forgetting `systemctl enable` or group membership do not affect unit discovery at start time.

Exam trap

Candidates often overthink the directory paths and forget that a simple typo in the service name is the most common cause of 'Unit not found' errors. The trap is focusing on file placement rather than the exact command used to start the service.

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 →
17
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

A target unit groups other units into a synchronisation point, replacing SysV runlevels during boot. It satisfies the stem's requirement for a valid systemd unit type, since systemd recognises targets natively alongside service, socket, device, mount, automount, swap, timer, path, slice and scope units.

Why this answer

Option C (target) is a valid systemd unit type: targets group other units and synchronize boot, replacing SysV runlevels (e.g., multi-user.target). Option D (socket) is valid: socket units describe an IPC or network socket that systemd listens on and activates the corresponding service via socket activation. Option E (service) is valid: service units define and control daemons or oneshot processes managed by systemd (e.g., sshd.service).

Options A (notification) and B (startup) are not systemd unit types; notification is not a unit type at all, and startup is not a recognized unit suffix, whereas real types include service, socket, target, device, mount, automount, swap, timer, path, slice, and scope.

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 →
18
MCQmedium

A Linux administrator wants to view the current resource limits (such as CPU and memory) applied to a running systemd service named database.service. Which command will display these limits?

A.systemctl show database.service
B.systemctl cat database.service
C.systemctl status database.service
D.systemctl list-dependencies database.service
AnswerA

systemctl show displays all properties of a unit, including resource control settings like CPUQuota, MemoryLimit, and others. This command provides a comprehensive view of the service's current configuration, including limits, without needing to inspect the unit file.

Why this answer

To view the effective resource limits of a running service, systemctl show is the appropriate command. It outputs all properties, including CPUQuota, MemoryLimit, and other cgroup-related settings. systemctl status and cat do not show the current effective limits, and list-dependencies is unrelated.

Exam trap

The trap here is assuming that systemctl status or systemctl cat will display resource limits, when in fact only systemctl show provides the full set of runtime properties.

Practice this question →
19
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

Restart=on-failure triggers a restart whenever the process exits non-zero, and RestartSec=10 inserts a ten-second delay before systemd attempts that restart. This satisfies the stem's non-zero exit condition while honouring the configured interval, so the unit is relaunched after the pause rather than immediately.

Why this answer

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 →
20
MCQeasy

A Linux administrator needs to modify the default runlevel (target) on a systemd-based Linux server so that it boots into a graphical environment by default. Which command should the administrator use?

A.systemctl enable graphical.target
B.ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target
C.systemctl isolate graphical.target
D.systemctl set-default graphical.target
AnswerD

This command sets the default boot target to graphical.target by creating a symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/graphical.target. It ensures that on the next boot, the system will start the graphical environment. This is the correct and recommended method for changing the default runlevel on systemd systems.

Why this answer

The default systemd target is controlled by the /etc/systemd/system/default.target symlink. The systemctl set-default command is the official way to change this symlink to point to the desired target, such as graphical.target for a graphical boot. Unlike isolate, which only changes the current state, set-default persists across reboots.

Using enable is incorrect because it does not alter the default.target symlink. Manual symlink creation is possible but not the recommended practice.

Exam trap

The trap here is confusing the immediate effect of isolating a target with the persistent change of setting the default target, leading to a temporary switch that does not survive a reboot.

Practice this question →
21
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

Directory permissions 755 grant write access only to the root owner, so user 'myapp' cannot create or append to files within /var/log/myapp/. The service therefore fails to open the log for writing, satisfying the stem's constraint that logs are absent despite the service running.

Why this answer

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 →
22
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

Editing a unit file does not alter the loaded configuration; systemd caches unit definitions until `systemctl daemon-reload` re-reads them. Because the stale in-memory copy still holds the original `Restart=no`, `systemctl show` reports that value, satisfying the stem's mismatch between the file's `Restart=on-failure` and the displayed setting.

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 →
23
Drag & Dropmedium

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

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct sequence to create a partition with fdisk is: first use 'n' to create a new partition, then specify the partition type and number (e.g., primary, logical) when prompted, then define the starting and ending sectors, and finally use 'w' to write the changes to the disk. Skipping or reordering steps can lead to errors or unintended configurations.

Practice this question →
24
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

EnvironmentFile= satisfies the requirement to keep configuration outside the unit file, letting systemd read DATABASE_URL from /etc/webapp.env and inject it into the process environment at start. This is the native mechanism for separating variables from unit definitions.

Why this answer

Using EnvironmentFile allows the administrator to keep the DATABASE_URL variable in a separate file, which can be updated without modifying the unit file. Option A 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.

Option D modifies ExecStart but is less standard and less maintainable than using EnvironmentFile.

Practice this question →
25
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 runs before ExecStart, and systemd requires each ExecStartPre command to exit successfully before proceeding. Since /bin/true always returns zero, the service starts normally; had it failed, systemd would mark the unit failed and skip ExecStart, satisfying the stem's dependency constraint.

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 →
26
Multi-Selectmedium

A system administrator is troubleshooting a custom systemd service that fails to start. They want to override a setting in the service's unit file without modifying the original file in /usr/lib/systemd/system/. Which two methods can be used to create a drop-in override? (Choose two.)

Select 2 answers
A.Edit the unit file directly in /usr/lib/systemd/system/ and run systemctl daemon-reload.
B.Create a file in /etc/systemd/system/<service>.service.d/ with a .conf extension.
C.Copy the original unit file to /etc/systemd/system/ and edit it there.
D.Run systemctl edit <service>.service and add directives in the editor.
E.Use systemctl mask <service>.service to create an override.
AnswersB, D

Drop-in directories under /etc/systemd/system/<service>.service.d/ are read by systemd and override the original unit file. Files with a .conf extension in this directory are automatically included. This method is recommended for local overrides because it does not touch the vendor-provided unit file and survives package updates.

Why this answer

The two correct methods are creating a drop-in directory with a .conf file and using systemctl edit. Both place overrides in /etc/systemd/system/<service>.service.d/ and are applied after daemon-reload. They preserve the original unit file and are the intended way to customize services without conflicting with package updates.

Other methods either replace the unit, mask it, or modify vendor files.

Exam trap

The trap here is thinking that copying the entire unit file to /etc/systemd/system/ is the same as a drop-in override, when it actually replaces the unit and can cause update conflicts.

Practice this question →
27
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

systemd parses unit files strictly; a malformed directive or invalid argument causes the parser to reject the unit, producing 'not loaded properly: Invalid argument'. The daemon cannot build the unit's dependency graph until the syntax is corrected.

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 →
28
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

Enabling the unit creates the systemd symlink under the appropriate target's .wants directory, so systemd starts myapp.service automatically at boot. This satisfies the reboot-persistence constraint, complementing the restart behaviour configured separately in the unit file.

Why this answer

Option B is correct because 'systemctl enable myapp.service' creates the necessary symlinks (typically under /etc/systemd/system/*.wants/) so systemd starts the unit automatically at boot, satisfying the reboot requirement. Option D is correct because 'Restart=always' in the [Service] section instructs systemd to restart the service regardless of exit status, including a clean exit code 0, which matches the requirement that it restart no matter how it stops. Option C is incorrect because 'Restart=on-failure' only restarts on non-zero exit codes, signals, or timeouts, so a normal exit would not trigger a restart.

Option A is incorrect because 'systemctl mask' links the unit to /dev/null and prevents it from being started at all, the opposite of the desired behavior. Option E is incorrect because 'After=network.target' only orders startup relative to the network target and does not enable boot startup or automatic restarts.

Exam trap

LFCS often tests the distinction between 'Restart=on-failure' and 'Restart=always' — candidates pick on-failure assuming it covers all cases, but it explicitly excludes clean exits, which the question calls out.

Practice this question →
29
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

'systemctl status' queries the unit's runtime state and prints Active: active (running) or inactive (dead), along with the main PID and recent log lines. This directly reports whether the service is currently running, satisfying the check required by the stem.

Why this answer

Option A, `systemctl status service`, is correct because it queries the service's runtime state and displays the Active line (e.g., `Active: active (running)`), directly showing whether the unit is currently running. Option C, `systemctl is-active service`, is correct because it prints the unit's active state (typically `active` or `inactive`) and returns exit code 0 when the service is running, making it ideal for scripted checks. Option B, `systemctl list-units --state=running`, lists all running units system-wide rather than confirming one specific service, so it is not a targeted check.

Option D, `systemctl is-enabled service`, only reports whether the unit is enabled to start at boot, not whether it is currently running. Option E, `systemctl show service`, dumps all unit properties by default and does not by itself answer the running-state question without filtering for ActiveState.

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 →
30
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

`After=network-online.target` orders the unit's start after the network-online target is reached, satisfying the requirement that networking be fully operational first. `After=` alone only sequences startup; it does not pull the target in, so `Wants=network-online.target` is typically paired with it.

Why this answer

`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 →
31
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

`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 →
32
MCQmedium

A Linux administrator is troubleshooting a custom systemd service named backup.service that fails to start. They run systemctl status backup.service and see that the service is in a failed state, but the output does not show detailed error messages. Which command should they use to view the most recent log entries specifically for this service?

A.journalctl -xe
B.journalctl -u backup.service -n 50
C.systemctl show backup.service
D.systemctl cat backup.service
AnswerB

journalctl -u backup.service filters the journal by the specified unit and shows log entries for that service. The -n 50 option displays the most recent 50 lines. This command directly provides the recent error messages for backup.service, which is exactly what the administrator needs to troubleshoot the failure.

Why this answer

To view logs for a specific systemd unit, journalctl with the -u option is used. Adding -n specifies the number of recent lines. This filters the journal to only backup.service, providing the most recent error messages.

Other commands like systemctl cat or show do not display logs, and journalctl -xe is not unit-specific.

Exam trap

The trap here is using systemctl status and expecting full logs, or using journalctl without unit filtering, which buries the relevant messages.

Practice this question →
33
MCQmedium

A system administrator needs to configure a systemd service so that it restarts automatically only when it exits with a non-zero exit code, but not when it is cleanly stopped by an administrator. The service unit file currently has no Restart directive. Which combination of directives should the administrator use?

A.Restart=always and RestartSec=5
B.Restart=on-failure and RestartSec=5
C.Restart=on-success and RestartSec=5
D.Restart=on-abnormal and RestartSec=5
AnswerB

Restart=on-failure tells systemd to restart the service only when it exits with a non-zero exit code, is killed by a signal, or times out. A clean stop via systemctl stop is considered a success and will not trigger a restart. RestartSec=5 adds a five-second delay between restart attempts, which is useful to avoid rapid restart loops.

Why this answer

Restart=on-failure is the correct directive because it restarts the service only on abnormal termination, such as non-zero exit codes or signals. It does not restart on a clean stop, which matches the requirement. RestartSec=5 adds a delay to prevent tight restart loops.

The other Restart values either restart too broadly (always) or too narrowly (on-abnormal, on-success).

Exam trap

The trap here is assuming that Restart=always is needed for automatic restarts, but it also restarts after a clean administrator stop, which is not desired.

Practice this question →
34
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

OnCalendar uses systemd's calendar syntax, and *-*-* 02:00:00 specifies every day at exactly 02:00. This satisfies the daily 2 AM schedule, and pairing it with a Type=oneshot service ensures the script runs once per trigger.

Why this answer

`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 →
35
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

journalctl -u myapp.service queries the systemd journal filtered to that unit, returning the full stdout and stderr captured before the process exited with status 1. This exposes the actual error message rather than just the exit code.

Why this answer

journalctl -u myapp.service retrieves the full log output for that systemd unit from the journal, including stdout/stderr captured before the service exited with status 1. This is the correct tool to see the complete error trace, not just the summary. systemctl status only shows a truncated tail and the exit code.

Exam trap

LFCS often tests the confusion between systemctl status (summary view) and journalctl -u (full unit logs), so candidates pick status thinking it shows complete error output.

How to eliminate wrong answers

Option A is wrong because systemctl status myapp.service shows only a short summary and the last few log lines (often truncated), not the full error output. Option B is wrong because systemctl reload asks the service to reload its configuration and does nothing to display logs; it may even fail if the unit is not running. Option D is wrong because systemctl restart attempts to restart the service, which does not help retrieve the prior failure's output and may overwrite or add new log entries.

Practice this question →
36
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

A target unit groups other units and services into a synchronisation point for boot execution, satisfying the stem's grouping requirement. Unlike service units, which run a specific process, targets aggregate units and are pulled in by dependencies, replacing SysV runlevels. This makes `target` the unit type designed for boot-stage grouping.

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 →
37
MCQhard

An administrator is creating a systemd timer unit called backup.timer that should trigger backup.service every day at 2:00 AM. The timer should also run the service immediately if the system was powered off at 2:00 AM. Which timer directives are required to achieve this?

A.OnCalendar=*-*-* 02:00:00 and Persistent=true
B.OnBootSec=2h and OnUnitActiveSec=1d
C.OnCalendar=02:00 and Persistent=false
D.OnCalendar=daily and AccuracySec=1h
AnswerA

OnCalendar=*-*-* 02:00:00 schedules the timer to trigger daily at 2:00 AM. Persistent=true ensures that if the system was off at the scheduled time, the service runs immediately upon boot. Together, these directives satisfy both the daily schedule and the catch-up requirement. They are placed in the [Timer] section of the timer unit.

Why this answer

The correct directives are OnCalendar with a full calendar specification for 2:00 AM daily and Persistent=true to handle missed runs. OnCalendar=*-*-* 02:00:00 sets the exact time, and Persistent=true stores the last trigger time on disk, so if the system was off, the timer fires immediately on next boot. Other options either set wrong times or lack persistence.

Exam trap

The trap here is using OnCalendar=daily thinking it means 2:00 AM, or forgetting that Persistent=true is needed for catch-up after downtime.

Practice this question →
38
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

systemctl enable creates the symlinks in the appropriate target's .wants directory, so systemd starts sshd automatically during boot. It does not start the unit now, which is why enable is paired with start when immediate activation is also needed.

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 →
39
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

'systemctl enable' creates the symlinks under the target's .wants directory that pull the unit into the boot transaction, satisfying automatic start at boot. It does not start the service now; 'systemctl start' handles that separately.

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 →
40
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 custom.service` creates a symlink from the service unit file in `/etc/systemd/system` into the appropriate multi-user.target.wants directory, which instructs systemd to start the service automatically at boot. This satisfies the stem’s requirement for a custom service to be launched during the boot sequence without manual intervention, leveraging systemd’s dependency-based parallel startup mechanism.

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 →
41
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

Type is a valid [Service] directive controlling how systemd judges the unit started, with values such as simple, forking, oneshot, notify and dbus. It belongs in [Service], not [Unit] or [Install], so it satisfies the stem's section constraint.

Why this answer

Option A (Type) is correct because Type is a [Service]-section directive that tells systemd how to start and track the process (e.g., simple, forking, oneshot, notify, dbus, idle), which is essential for correct service supervision. Option C (User) is correct because User is a [Service]-section directive that sets the UNIX account the service process runs as, a common hardening and permission control. Option D (ExecStart) is correct because ExecStart is a [Service]-section directive that specifies the command line to launch the service, and it is the primary way systemd knows what to execute.

Option B (Requires) does not belong because Requires is a dependency directive valid in the [Unit] section, not [Service]. Option E (Description) does not belong because Description is a metadata directive valid in the [Unit] section, not [Service].

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 →
42
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

`systemctl stop httpd` halts the running unit immediately while leaving its enablement state untouched, so the symlinks in the multi-user.target.wants directory remain intact and the service still starts on subsequent boots. This satisfies the stem's requirement to stop temporarily without disabling autostart, unlike `systemctl disable`, which removes those symlinks.

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 →
43
MCQeasy

A system administrator wants to change the default runlevel (target) of a Linux system from graphical.target to multi-user.target. Which command should they use?

A.systemctl set-default multi-user.target
B.systemctl default multi-user.target
C.systemctl isolate multi-user.target
D.systemctl enable multi-user.target
AnswerA

systemctl set-default multi-user.target changes the default target that systemd boots into. It creates a symbolic link /etc/systemd/system/default.target pointing to multi-user.target. This is the correct and persistent way to change the default runlevel on a systemd-based system. It takes effect on the next boot.

Why this answer

The default target is set by the /etc/systemd/system/default.target symlink. The systemctl set-default command manages this symlink, pointing it to the desired target. isolate switches the current runtime state but does not persist. enable is for enabling units to start automatically, not for setting the boot target. Therefore, set-default is the correct command.

Exam trap

The trap here is confusing the temporary isolate command with the persistent set-default command.

Practice this question →
44
MCQhard

A Linux administrator is creating a custom systemd timer unit named backup.timer to schedule a daily backup script. The administrator wants the timer to trigger the backup service exactly at 2:00 AM every day, regardless of when the system was last booted. Which timer directive should be used in the [Timer] section of backup.timer?

A.OnStartupSec=2h
B.OnCalendar=*-*-* 02:00:00
C.OnUnitActiveSec=24h
D.OnBootSec=2h
AnswerB

The OnCalendar directive defines a calendar-based schedule using systemd's calendar event format. Specifying *-*-* 02:00:00 means every day at 2:00 AM. This is independent of boot time and ensures the timer triggers at the exact wall-clock time. This is the correct directive for the scenario.

Why this answer

To schedule a task at a specific time of day, such as 2:00 AM daily, the OnCalendar directive is used with a calendar expression. The expression *-*-* 02:00:00 matches every day at 2:00 AM. Other timer directives like OnBootSec, OnStartupSec, and OnUnitActiveSec are monotonic and relative to events like boot or last activation, so they cannot guarantee a fixed wall-clock time.

Therefore, OnCalendar is the correct choice for this scenario.

Exam trap

The trap here is selecting a monotonic timer directive like OnBootSec, which seems to schedule a daily event but actually depends on boot time and will drift if the system is rebooted at different times.

Practice this question →
45
MCQhard

A system administrator is creating a systemd service unit for a custom application. The application requires that a specific environment variable, APP_ENV=production, be set before the service starts. The administrator wants this variable to be available only to this service, not system-wide. Which directive should be used in the service unit file?

A.Environment=APP_ENV=production
B.PassEnvironment=APP_ENV
C.EnvironmentFile=/etc/sysconfig/myapp
D.SetEnvironment=APP_ENV=production
AnswerA

Environment= sets environment variables for the executed process. It can be used multiple times to set multiple variables. This directive applies only to the service unit, not system-wide, and is the correct way to set a service-specific environment variable. It is placed in the [Service] section of the unit file.

Why this answer

The Environment= directive in a systemd service unit sets environment variables specifically for that service. It does not affect the system-wide environment. EnvironmentFile= requires an external file, SetEnvironment= is not a valid directive, and PassEnvironment= only forwards existing variables from the manager.

Therefore, Environment= is the correct choice.

Exam trap

The trap here is confusing Environment= with PassEnvironment=, or assuming EnvironmentFile= is required for any environment variable.

Practice this question →
46
MCQmedium

A Linux administrator is configuring a custom systemd service called backup.service. The service should run a backup script only when the server is connected to AC power and not running on battery. Which condition directive should be added to the [Unit] section of backup.service?

A.ConditionACPower=true
B.ConditionKernelCommandLine=ac
C.ConditionCapability=CAP_SYS_ADMIN
D.ConditionPathExists=/sys/class/power_supply/AC/online
AnswerA

ConditionACPower=true ensures the unit runs only when the system is on AC power. In this scenario, the administrator wants the backup to execute only when the server is not on battery, so this directive precisely matches the requirement. It is a condition, not a dependency, so if the condition is not met, the unit is skipped without failure.

Why this answer

ConditionACPower=true is the correct directive because it directly checks whether the system is running on AC power. When the system is on battery, the condition fails, and systemd skips the unit. This prevents the backup from running and draining battery.

Other conditions check file existence, kernel command line, or capabilities, none of which reliably indicate AC power status.

Exam trap

The trap here is confusing ConditionACPower with a generic file existence check, leading to the use of ConditionPathExists on a power supply path.

Practice this question →
47
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

`systemctl list-units --type=service --state=active` queries systemd's unit manager directly, filtering loaded units by the service type and the active runtime state. This satisfies the stem's requirement to display every currently running service, unlike `systemctl status` (single unit) or `--state=running` (excludes active-but-exited ones).

Why this answer

`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 →
48
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

`Restart=on-failure` restarts the service only when it exits with a non-zero status, is killed by a signal, or times out — satisfying the crash-recovery requirement without restarting after a clean stop. Paired with `WantedBy=multi-user.target`, it also covers automatic start at boot for the port 8080 application.

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 →
49
MCQeasy

A junior administrator has written a custom systemd service unit file named backup.service in /etc/systemd/system/. The unit is intended to run a backup script once per day. After placing the file, the administrator runs systemctl start backup.service, but systemd reports 'Unit backup.service not found.' The file exists and has correct syntax. Which command should the administrator run to make systemd aware of the new unit file?

A.systemctl reload backup.service
B.systemctl daemon-reload
C.systemctl reset-failed backup.service
D.systemctl enable backup.service
AnswerB

systemd caches unit files and does not automatically detect new or changed units in /etc/systemd/system/. Running systemctl daemon-reload forces systemd to re-scan all unit directories and rebuild its dependency tree, making backup.service available for systemctl start. Without this, systemctl start fails with 'Unit not found' even though the file is present and valid.

Why this answer

systemd maintains an in-memory cache of unit files and does not watch /etc/systemd/system/ for new files. After adding or modifying a unit, systemctl daemon-reload must be run so systemd re-reads unit definitions and rebuilds dependencies. Only then does systemctl start recognize the new backup.service unit.

Exam trap

The trap here is assuming that placing a unit file in /etc/systemd/system/ is immediately recognized by systemd without a daemon-reload.

Practice this question →
50
MCQmedium

A Linux administrator is configuring a custom systemd service that must not start until a network share is mounted. The mount is managed by a systemd mount unit named mnt-data.mount. Which directive should be added to the [Unit] section of the service unit to enforce this ordering?

A.Before=mnt-data.mount
B.After=mnt-data.mount
C.Wants=mnt-data.mount
D.Requires=mnt-data.mount
AnswerB

After= ensures that the service starts only after mnt-data.mount has finished activating. This is the correct directive for ordering, as it tells systemd to delay the service start until the specified unit is active, which is exactly what is needed for the mount to be available.

Why this answer

The service must wait for the mount unit to be active before starting. The After= directive explicitly defines ordering, ensuring the service starts only after mnt-data.mount has activated. Requiring the mount alone does not guarantee order, and Before= would reverse the desired sequence.

Exam trap

The trap here is confusing a dependency directive like Requires= with an ordering directive like After=, assuming that requiring a unit also ensures it starts first.

Practice this question →
51
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

Sending a signal via systemctl kill terminates or signals the running process, immediately altering the unit's active state. It satisfies the stem's requirement for an action affecting a currently running service, unlike query or enable operations that leave runtime state untouched.

Why this answer

Option A, `systemctl kill myapp.service`, is correct because it sends a signal (SIGTERM by default) to the service's processes, which changes the running state by terminating or signaling them. Option B, `systemctl reload myapp.service`, is correct because it triggers the service's ExecReload action, causing the running process to reload its configuration without stopping, thus affecting its runtime state. Option E, `systemctl stop myapp.service`, is correct because it explicitly stops the running service, transitioning it from active to inactive.

Option C, `systemctl disable myapp.service`, only removes the service's autostart symlinks and does not affect a currently running instance. Option D, `systemctl daemon-reload`, only reloads systemd manager configuration and does not alter the state of any running service.

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 →
52
MCQhard

A Linux administrator is configuring a systemd service that must only start after the network is fully online and must stop if the network goes down. The unit file currently has After=network.target. However, the service sometimes starts before DNS resolution is available, causing failures. Which target should the administrator use instead to ensure the network is fully configured and DNS is available?

A.network.target
B.multi-user.target
C.basic.target
D.network-online.target
AnswerD

network-online.target is a special target that waits until the network is actually configured and reachable, not just the network management stack started. Using After=network-online.target and Wants=network-online.target ensures the service starts only after the network is online, which includes DNS resolution. This directly addresses the premature start issue.

Why this answer

network-online.target is designed specifically to wait until the network is fully operational, including DNS resolution. By using After=network-online.target and Wants=network-online.target, the service will not start until the network is truly online. This is the correct target for services that require actual network connectivity, unlike network.target which only signals that the network stack has started.

Exam trap

The trap here is confusing network.target with network-online.target; the former only indicates the network stack is up, while the latter waits for actual connectivity.

Practice this question →
53
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

CPUQuota=50% caps the service's aggregate CPU time at half of one core, enforced by the cgroup v2 cpu.max controller. This directly satisfies the stem's 50%-of-a-single-core ceiling, unlike CPUShares or Nice, which only weight scheduling priority without imposing a hard bandwidth limit.

Why this answer

`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 →
54
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=` drops privileges to the named account before the service's main process starts, satisfying the stem's non-root requirement. systemd performs the setuid itself, so no shell wrapper or `su` is needed. Pair it with `Group=` for full control over the process credentials.

Why this answer

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 →
55
MCQmedium

A Linux administrator is configuring a systemd service unit for a custom application. The application requires that the /opt/app/data directory exists and is writable before the service starts. The administrator wants to ensure this directory is created automatically if it does not exist. Which systemd directive should be added to the [Service] section to achieve this?

A.ExecStartPre=/bin/mkdir -p /opt/app/data
B.StateDirectory=app/data
C.RuntimeDirectory=app/data
D.WorkingDirectory=/opt/app/data
AnswerA

ExecStartPre specifies a command to run before the main ExecStart command. Using /bin/mkdir -p /opt/app/data ensures the directory exists and creates parent directories as needed. This is a flexible and direct way to meet the requirement, as it can create any path and set permissions if needed. It is the correct approach for this scenario.

Why this answer

The ExecStartPre directive allows running a command before the main service starts. Using /bin/mkdir -p /opt/app/data will create the directory and any missing parent directories, ensuring it exists before the application starts. Other directives like StateDirectory and RuntimeDirectory only manage directories in specific system locations (/var/lib and /run, respectively).

WorkingDirectory merely sets the working directory but does not create it. Thus, ExecStartPre is the correct solution for creating a custom directory under /opt.

Exam trap

The trap here is assuming that StateDirectory or RuntimeDirectory can create arbitrary directories, when they are restricted to /var/lib and /run respectively.

Practice this question →
56
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

'systemctl status' shows the unit's state, exit code and the most recent journal entries, giving both failure details and last log lines in one view. It satisfies the requirement to inspect a failed unit without a separate journalctl invocation.

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 →
57
MCQeasy

A system administrator needs to prevent a service named backup.service from starting automatically at boot, while keeping it available for manual start. The service is currently enabled. Which command should the administrator run?

A.systemctl stop backup.service
B.systemctl mask backup.service
C.systemctl disable backup.service
D.systemctl kill backup.service
AnswerC

Disabling a service removes the symlinks that cause it to start at boot, but the unit file remains available. The administrator can still start it manually with systemctl start. This matches the requirement to prevent automatic startup while allowing manual activation.

Why this answer

To prevent automatic startup while retaining the ability to start manually, the service must be disabled. Disabling removes the boot-time symlinks but leaves the unit file intact. Masking would prevent manual start, and stopping or killing only affects the current runtime state.

Exam trap

The trap here is confusing disabling a service with masking it, or thinking that stopping a service also disables it from starting at boot.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Service Configuration questions.

Start 20-question session