EX300 Red Hat Certified Engineer (RHCE) Free Practice Test — 30 Questions
This practice bank exercises the core competencies of a Red Hat Certified Engineer: managing SELinux contexts and policies (semanage, restorecon, semodule), configuring systemd services with dependencies (ExecStartPre, network-online.target), troubleshooting Kubernetes and cluster failures (CSI drivers, fencing, GitOps drift), and demonstrating leadership under pressure (adaptability, structured problem-solving, communication). The scenarios emphasize persistent configuration, security integration, and rapid decision-making in production environments. Mastery of these domains is critical for the RHCE exam.
What this RHCE practice set measures
This is an analysis of the practice bank, not a claim about the vendor's live exam blueprint. Use it to identify the knowledge, judgment, and recall patterns exercised here, then verify your coverage against the current official exam guide.
SELinux Policy Management and Troubleshooting
Effective SELinux administration requires understanding how to assign and persist file contexts for custom applications and services. The practice bank emphasizes using semanage fcontext to define rules and restorecon to apply them, especially for non-standard paths like /opt/custom_app. It also covers the use of semodule for installing compiled policy modules. Key scenarios include enabling httpd to write to shared directories (httpd_sys_rw_content_t), fixing NFS exports (nfs_shares_t), and interpreting audit logs during failures. The core skill is distinguishing between temporary fixes (chcon) and persistent changes (semanage).
- Use semanage fcontext with regex patterns to define persistent SELinux contexts for files and directories.
- restorecon -Rv applies default contexts recursively; crucial after semanage or when contexts are missing.
- httpd_sys_content_t for static web content; httpd_sys_rw_content_t for writable directories.
- nfs_shares_t is the correct context for NFS exported directories to allow client access.
- semodule -i installs compiled policy modules (.pp) into the active SELinux policy.
Systemd Service Configuration and Dependencies
Creating robust systemd service units involves specifying dependencies correctly to ensure services start in the right order. The practice bank highlights the error of using ExecStartPre to check a target like network-online.target, when the correct approach is to use After= and Wants= or Requires= in the unit file. Other topics include the interaction between timers and services regarding SELinux contexts, and troubleshooting failures when a service does not create directories due to missing SELinux permissions (though the explanation clarifies the actual cause is not SELinux but the timer's ownership affecting the service's user).
- Use After=network-online.target and Wants=network-online.target in the [Unit] section to delay start until network is confirmed up.
- ExecStartPre runs before the main process but is not a dependency mechanism; it cannot replace proper directive ordering.
- Timer units (type=oneshot) inherit the service's User/Group; if not set, the service runs as root if the timer is owned by root.
- systemd-tmpfiles can create directories but requires correct SELinux context and proper configuration files.
- Always verify service unit syntax with systemd-analyze verify.
Kubernetes, Clustering, and High Availability
The practice bank covers diagnosing containerized application failures in Kubernetes, especially persistent storage issues via CSI drivers and performance bottlenecks. Key diagnostic actions include examining CSI driver logs and correlating application metrics with node resource usage. For cluster management, split-brain scenarios require fencing mechanisms like STONITH to ensure data integrity. GitOps workflows demand reversal of configuration drift by reverting manual changes and reinforcing CI/CD pipeline checks. The scenarios test the ability to adopt new technologies via pilot programs and phased migrations.
- Check Kubernetes CSI driver pod logs to diagnose persistent storage failures.
- Correlate application latency with node CPU throttling, memory pressure, and I/O wait using Prometheus metrics.
- Implement STONITH (fencing) to enforce that only one node acts as primary in a cluster to prevent split-brain.
- For GitOps drift, immediately revert manual changes to the cluster and ensure Git repository is the single source of truth.
- Deploy new orchestration platforms via pilot programs on non-critical segments before full rollout.
Incident Response, Leadership, and Adaptability
The RHCE exam tests not only technical skills but also the ability to lead during incidents. Scenarios involve unexpected outages, dependency conflicts, and conflicting priorities. Effective strategies include immediate service restoration using rollback or workarounds, followed by thorough post-mortem analysis. Delegation, clear communication, and stakeholder updates are crucial. The practice bank emphasizes adaptability when project plans are disrupted by vendor delays or competitor innovations. The correct decisions balance speed with methodical diagnosis, and prioritize stability over hasty changes.
- In a kernel panic with rollback dependency conflict, cease restoration efforts and seek vendor patch if no immediate workaround exists.
- Restore service first using stable rollback configurations, then conduct deep root cause analysis.
- When a key team member leaves, re-evaluate timelines, delegate based on adjacent skills, and initiate knowledge transfer.
- Communicate revised timelines to stakeholders when security vulnerabilities require immediate remediation.
- Adapt project scope when a competitor releases a superior solution by re-evaluating core technologies for new market niches.
Practice EX300 Red Hat Certified Engineer (RHCE) with real flashcards
Read the prompt, commit to an answer, then flip the card. Move through the deck at your own pace and repeat any topic that does not come back quickly.
Card 1 of 20
1 reviewed this session
Static practice bank
Start the 30-question diagnostic
The complete question bank is embedded in this pre-rendered page. There is no database request or second content download when you begin.
A system administrator is tasked with deploying a novel, custom-built web server application on a Red Hat Enterprise Linux system. The executable is located at `/usr/local/sbin/my_web_app`. To ensure proper SELinux operation and integration with the system\'s security policy, the administrator must assign it an appropriate context that allows it to function as a web server. They have determined that the `httpd_exec_t` type is the most suitable for this executable. What is the most effective and persistent method to ensure the `my_web_app` executable and its associated files are correctly labeled with `httpd_exec_t` and that this labeling is maintained across system reboots and policy updates?
Study workflow
Turn one RHCE attempt into a study plan
- 1
Persist SELinux Contexts for Custom Applications
1. Identify the correct SELinux type (e.g., httpd_exec_t for web server executables). 2. Add a file context rule using semanage fcontext with a regex pattern: semanage fcontext -a -t httpd_exec_t '/usr/local/sbin/my_web_app'. 3. Apply the context with restorecon -Rv /usr/local/sbin. 4. Verify with ls -Z. This ensures persistence across reboots and relabeling.
- 2
Configure Systemd Service to Wait for Network
1. Edit the unit file /etc/systemd/system/my-custom-app.service. 2. Add [Unit] section with After=network-online.target and Wants=network-online.target. 3. Do not use ExecStartPre to check the target; that is a common mistake. 4. Run systemctl daemon-reload. 5. Test with systemctl start my-custom-app.timer or service.
- 3
Troubleshoot NFS Client Permission Issues with SELinux
1. On the NFS server, ensure the exported directory has the nfs_shares_t context: semanage fcontext -a -t nfs_shares_t '/srv/nfs_data(/.*)?' then restorecon -Rv /srv/nfs_data. 2. Verify export options in /etc/exports (e.g., rw, sync). 3. Restart nfs-server. 4. On the client, check SELinux booleans: getsebool nfs_export_all_rw, setsebool if needed. 5. Mount again and test access.
- 4
Diagnose Kubernetes Performance Degradation
1. Correlate application-level metrics (response times, error rates) with node resource usage (CPU throttling, memory pressure, I/O wait) via Prometheus. 2. Check pod logs for OOMKilled or CrashLoopBackOff. 3. Examine CSI driver logs if persistent storage is involved. 4. Use kubectl top nodes/pods and describe nodes/pods. 5. Adjust resource requests/limits or scale pods if resource contention is found.
- 5
Handle Critical Service Outage: Rollback vs. Root Cause Analysis
1. Immediately restore service using a known good configuration or hotfix. 2. Do not delay restoration for analysis. 3. After service is stable, begin a structured post-mortem: collect logs, timeline, and artifacts. 4. Identify the root cause and implement preventive measures. 5. Communicate the resolution and future preventative steps to stakeholders.
FAQ
Questions about this RHCE practice page
Clear boundaries on what the bank covers, how to use it, and where official vendor information still matters.
What command makes an SELinux context change persistent across reboots?+
Use semanage fcontext to define the rule (e.g., semanage fcontext -a -t httpd_sys_content_t '/var/www/html(/.*)?'), then apply with restorecon -Rv. This persists in the policy database, unlike chcon which is temporary.
How do I ensure my systemd service starts only after network is fully online?+
In the [Unit] section, add After=network-online.target and Wants=network-online.target. The network-online.target is reached when all network services report ready. Do not use ExecStartPre for dependency checks.
Why does an NFS client get 'Permission denied' even with correct permissions?+
Check the server's SELinux context on the exported directory. It must be nfs_shares_t. Use semanage fcontext and restorecon to relabel. Also ensure the NFS export options include rw and that client has proper kerberos or host-based access.
What is the first step in investigating a Kubernetes pod that fails due to persistent storage?+
Check the logs of the CSI driver pods (e.g., ceph-csi) for errors. Also examine the PersistentVolumeClaim events with kubectl describe pvc. Storage failures often manifest as pod errors like 'FailedMount' or 'Volume is not found'.
How should I decide between restoring from backup vs. fixing the root cause during an outage?+
Prioritize restoring service to customers using any safe workaround (e.g., rollback, hotfix). Defer root cause analysis until after full stability. This minimizes downtime and prevents further impact. Then conduct a thorough post-mortem.
Build the next review session
Browse another free bank or use the study strategy guide to turn your misses into spaced review.