Match each systemd unit type to its purpose.
Drag a concept onto its matching description — or click a concept then click the description.
Manages a daemon or service process
Groups units to define system states (runlevels)
Enables socket-based activation for services
Triggers activation of other units on a schedule
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
service: Manages daemon processes
Systemd unit types define system resources: service (daemons), socket (IPC), target (group/synchronization), timer (scheduled activation). Common confusions involve mixing mount with service and target with timer.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
service: Manages daemon processes
Why this is correct
Service units (.service) are the primary systemd unit type for managing daemon processes that run in the background. They define how a process is started (ExecStart), stopped (ExecStop), and supervised, including restart policies, environment variables, and user/group privileges. Unlike transient processes, services are tracked by systemd as persistent units that can be enabled to start at boot and that integrate with dependency chains.
service: Manages file system mount points
Why it's wrong here
File system mount points are not managed by service units; they are the responsibility of mount units (.mount), which represent a mount point as defined in /etc/fstab or via systemd.mount. A .mount unit encapsulates the device, filesystem type, mount options, and ordering constraints relative to network or other mounts. Confusing this role with service units conflates process execution with filesystem lifecycle management, which systemd intentionally separates.
socket: Manages inter-process communication sockets
Why this is correct
Socket units (.socket) create and manage listening sockets for inter-process communication, supporting both network sockets (e.g., AF_INET) and local Unix sockets (AF_UNIX). They enable socket-based activation: a service is started on demand when a connection arrives, and systemd hands over the listening socket to the service process. Critically, the socket unit itself only manages the socket object and its activation trigger, not the service logic.
target: Groups units to define synchronization points
Why this is correct
Target units (.target) do not execute code but serve as named synchronization points that group other units (services, sockets, timers) into a cohesive state. They define dependencies and ordering, allowing systemd to start or stop a logical collection of units as a unit, such as reaching multi-user.target or switching to rescue.target. This grouping mechanism is fundamental to boot sequencing and allows administrators to isolate the system to a particular runlevel-like state.
timer: Manages timed activation of services
Why this is correct
Timer units (.timer) schedule activation of a matching .service unit either on a realtime calendar schedule (OnCalendar=) or relative to system state events such as boot or activation (OnBootSec=, OnUnitActiveSec=). They are systemd's native replacement for cron jobs, providing robust management, missed-execution handling, integration with journaling, and consistency with the rest of the unit model. Timers trigger their associated service but do not run tasks directly, maintaining a clean separation between scheduling and execution.
timer: Groups units to define synchronization points
Why it's wrong here
This description incorrectly assigns the grouping and synchronization role of target units to timer units. Timer units are entirely scheduling mechanisms: they specify time-based triggers that activate a single associated service, and they have no mechanism for grouping multiple units or defining synchronization points. The capability to organize units into coordinated states belongs exclusively to target units, whose purpose is to aggregate dependencies and ordering across many units.
Go deeper
About these practice questions
This EX200 question is part of Courseiva's 427-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX200 practice question is part of Courseiva's free Red Hat certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the EX200 exam.