EX200 Operate running systems Practice Question
A junior administrator configured a new network interface (ens224) with a static IP address using a configuration file in /etc/sysconfig/network-scripts/ifcfg-ens224. After restarting the network service, the interface comes up but does not get the IP address. The administrator runs 'ip addr show ens224' and sees no IP address assigned. The interface is listed as DOWN. The administrator then runs 'ifup ens224' manually, which succeeds, and the IP address appears. What is the most likely cause?
⚠ Common exam trap
In Red Hat Enterprise Linux, the ONBOOT directive in ifcfg files controls whether the interface is brought up automatically at boot. Candidates often mistakenly think that enabling the network service at boot is sufficient, but each interface must have ONBOOT=yes to activate automatically. Without it, the interface remains DOWN until manually started with ifup.
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 ONBOOT directive is set to no in the ifcfg file.
The ONBOOT directive controls whether the interface is automatically brought up at system boot. When set to 'no', the interface configuration file is read but the interface remains DOWN after a network service restart, requiring manual intervention via 'ifup'. The junior administrator's observation that 'ifup ens224' succeeds confirms the configuration is valid, but the interface fails to activate automatically due to ONBOOT=no.
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 ONBOOT directive is set to no in the ifcfg file.
Why this is correct
The ONBOOT directive in the interface's ifcfg file (e.g., /etc/sysconfig/network-scripts/ifcfg-eth0) explicitly controls whether the interface is activated when the system boots. When ONBOOT=no, the interface is fully configured but is deliberately skipped by the boot-time startup sequence, so it stays down until an administrator runs ifup or uses NetworkManager to connect manually. Manual activation succeeds because the rest of the configuration (e.g., IP address, netmask, gateway) is valid, and the service that performs ifup is already running. This exactly matches the symptom of an interface that is correctly configured but not active after a reboot.
- ✗
The network service is not enabled to start at boot.
Why it's wrong here
The network service (or NetworkManager) being disabled at boot is a system-wide setting that prevents the entire networking stack from starting during boot, affecting all interfaces, not just one. In this scenario, the service was able to be restarted, meaning it is enabled or at least can run, and the problem is isolated to a single interface. If the service were actually disabled, manual ifup would fail because the service isn't running to handle the request, but here manual ifup works fine. The real cause is the interface-level ONBOOT flag, not the boot enablement of the service.
- ✗
The interface name does not match the device file.
Why it's wrong here
In RHEL systems, each ifcfg file must contain a DEVICE or NAME that matches the actual kernel interface name (e.g., eth0, ens33) and, optionally, an HWADDR to bind it to a NIC. If the name did not match the device file, trying to run ifup would fail with an error like 'Unknown interface', because the system would look for a device with the specified name and not find it. Since manual ifup succeeded here, the interface name and device are properly matched, ruling out a naming or hardware address mismatch. The problem is not a name/device mismatch but the ONBOOT setting controlling automatic activation.
- ✗
There is a conflict with NetworkManager managing the interface.
Why it's wrong here
NetworkManager and the legacy network service cannot both manage the same interface cleanly, and if NetworkManager owned this interface, it would likely override the manual ifup command or apply its own connection profile automatically. The fact that the interface comes up and remains up after a manual ifup indicates that NetworkManager is not actively managing this particular interface — otherwise it would either detect the device and bring it up at boot (if a connection existed) or conflict with the manual action. Since the interface stays down after boot until intervened, the scenario is consistent with the network service alone handling a per-interface ONBOOT=no flag. Therefore, a NetworkManager conflict is not the root cause; the ifcfg ONBOOT directive is.
Go deeper
Related to this question
About these practice questions
One of 127 original EX200 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.