EX200 Deploy, configure, and maintain systems Practice Question
A junior system administrator configures rsyslog on a RHEL 9 server to forward logs to a remote centralized log server. They add the line *.* @192.168.1.100:514 to /etc/rsyslog.conf and restart rsyslog with systemctl restart rsyslog. Local logging works fine, but the remote server does not receive any logs. The administrator checks the local firewall and confirms that UDP port 514 is open outbound. They also verify network connectivity using nc. What is the most likely cause?
⚠ Common exam trap
The trap here is that candidates focus on network-level troubleshooting (firewall, connectivity) and overlook SELinux, which is a mandatory access control layer that can block outbound connections even when the firewall is open.
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
✓
The SELinux boolean rsyslog_remote is disabled, blocking outbound syslog.
On RHEL 9, SELinux enforces a targeted policy that blocks rsyslog from making outbound network connections by default. The boolean `rsyslog_remote` controls this behavior; when disabled, SELinux denies the outbound syslog traffic even though the local firewall allows it. The administrator must enable this boolean with `setsebool -P rsyslog_remote on` to allow rsyslog to forward logs via UDP or TCP.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The systemd unit for rsyslog is masked, preventing it from running.
Why it's wrong here
A masked systemd unit cannot be started at all — systemctl start would fail with 'Unit rsyslog.service is masked.' Since the administrator successfully restarted rsyslog, the unit is not masked. Masking creates a symlink to /dev/null, which overrides any enable/disable state; a masked service is a configuration state, not a runtime failure, and would prevent the daemon from running regardless of SELinux.
- ✗
The remote rsyslog server is not listening on UDP port 514.
Why it's wrong here
While it's true that the remote rsyslog server must listen on UDP 514 for the @ directive to deliver messages, this option describes a remote host issue rather than a local RHEL 9 configuration problem. The question implies the local rsyslog service started and the administrator is troubleshooting outbound delivery; a common local cause is SELinux denying the rsyslogd process network access. The remote listener can be verified independently with ss -ulpn or tcpdump, but the SELinux boolean is the more direct and frequently overlooked culprit on a default RHEL 9 installation.
- ✓
The SELinux boolean rsyslog_remote is disabled, blocking outbound syslog.
Why this is correct
On RHEL 9, SELinux ships with the rsyslog_remote boolean disabled by default, which prevents rsyslogd from making outbound TCP/UDP connections to a central log server. Even with a correct rsyslog action line (e.g., *.* @192.0.2.10:514), SELinux will silently drop the packet and log an AVC denial in /var/log/audit/audit.log. Enabling the boolean with `setsebool -P rsyslog_remote 1` allows rsyslog to send syslog messages over the network, making this the correct fix when the service restarts normally but no logs arrive at the remote server.
- ✗
The configuration should use @@ for TCP instead of @ for UDP.
Why it's wrong here
The @ prefix in rsyslog indicates UDP, while @@ indicates TCP; both are valid transport protocols depending on the remote server's configuration. The question specifically states the remote server is configured for UDP, so using @ is correct. Switching to @@ would change the transport to TCP and fail because the remote server's UDP listener would never receive the packets — it would not resolve the underlying SELinux denial and would introduce a new protocol mismatch.
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.