EX200 Deploy, configure, and maintain systems Practice Question
A Red Hat Enterprise Linux 8 system was recently updated via 'yum update'. After reboot, the systemd-logind service fails to start with the error 'Failed to start Login Service' and 'Permission denied' messages in the journal. The administrator checks the SELinux status with 'getenforce' and it returns 'Enforcing'. The administrator also notices that the '/var/run' directory is now a symlink to '/run'. There are no firewall issues. The service works if SELinux is set to permissive. Which single action should the administrator take to resolve this issue permanently?
⚠ Common exam trap
The trap here is that candidates may focus on the symlink (/var/run -> /run) and assume a package reinstall or disabling SELinux is needed, rather than recognizing that SELinux contexts on the target directory (/run) are the root cause, which is fixed by a simple restorecon.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Run 'restorecon -Rv /run' to restore default SELinux contexts for /run
After a yum update, SELinux contexts on /run may be incorrect because /var/run is a symlink to /run. When SELinux is enforcing, systemd-logind requires the correct context (typically system_u:object_r:var_run_t:s0) on /run to access its runtime files. Running 'restorecon -Rv /run' restores the default SELinux contexts for all files under /run, resolving the 'Permission denied' errors permanently without disabling SELinux.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Run 'restorecon -Rv /run' to restore default SELinux contexts for /run
Why this is correct
Running `restorecon -Rv /run` recursively resets the SELinux context of every file and directory under /run to the default labels defined in the active policy's file_contexts file. After a system update introduces a new SELinux policy, dynamically created runtime files such as logind's sockets and PID files may retain old or invalid types, causing permission denials. This command corrects exactly those mismatches without a reboot and is the minimal, targeted fix for the problem.
- ✗
Add 'selinux=0' to kernel boot parameters and reboot
Why it's wrong here
Adding `selinux=0` to the kernel command line disables SELinux entirely by bypassing the LSM at boot, which masks the labeling mismatch but does not repair it. This leaves the system with no SELinux protection, violating a typical RHEL security baseline, and is considered only a temporary troubleshooting step. Moreover, after the next reboot, if the parameter is removed, the same mislabeled /run files would still prevent logind from working, so the root cause remains unresolved.
- ✗
Edit the systemd-logind service unit to add 'Permissions=yes'
Why it's wrong here
The systemd unit parser does not recognize a `Permissions=yes` directive; the only SELinux-related unit options are things like `SELinuxContext=` for explicitly specifying a context. SELinux enforcement is performed by the kernel's Linux Security Module hooks, independent of systemd, so a service option cannot grant permission beyond what the policy allows. Even if you attempted to edit the unit, it would neither relabel existing /run files nor add any SELinux allow rule, making this a fundamentally invalid approach.
- ✗
Reinstall the systemd-logind package using 'yum reinstall systemd'
Why it's wrong here
Reinstalling the systemd package via `yum reinstall systemd` only reinstalls the binaries, libraries, and unit files from the RPM, replacing the files that the package owns. It does not invoke restorecon, so the SELinux labels on runtime artifacts under /run, like /run/logind or /run/user/*, remain as whatever they were before. Because those mislabeled files are not part of the RPM package database, reinstalling systemd has no effect on their contexts, and logind would still be denied by SELinux.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX200 question from scratch — 127 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
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.