If you walk into the EX200 exam without a solid review strategy, you will waste precious minutes on questions you could have answered in seconds, and you will almost certainly fall into traps that the exam setters have deliberately placed for you. This chapter is about giving yourself the best possible chance to pass — not by learning new material, but by organising what you already know, managing your clock, and spotting the common pitfalls before they trip you up.
Jump to a section
A simple way to picture Exam Review and Practical Tips for Success
Have you ever spent two hours cooking a complicated meal, only to realise you forgot to preheat the oven? That moment of panic is exactly what happens during the EX200 exam when you skip the final review phase.
Imagine you're teaching a friend to bake a three-layer birthday cake from a family recipe. You don't just hand them the recipe card and walk away. Instead, you spend the last hour together: you check they understand the order of steps, you point out that 'room temperature butter' doesn't mean 'microwaved butter', and you remind them that the oven thermometer might run 10 degrees hot. You flag the tricky bits — folding, not stirring — and you set a timer for each stage. On exam day, you are both the cook and the teacher. The exam is the cake. The 'review and tips' phase is that final hour: checking your timing, calibrating your tools, and rehearsing the steps you always fumble. Without that hour, you risk pulling a burnt, lopsided cake out of the oven and wondering what went wrong.
The EX200 exam, also called the Red Hat Certified System Administrator exam, is a performance-based test. That means you don't just tick multiple-choice boxes. You sit at a real or virtual computer (called a 'node' or a 'system') and complete tasks such as configuring network interfaces, setting up storage volumes, managing users and groups, and troubleshooting services. The exam lasts two and a half hours, and everything is timed. There are no breaks. The exam environment is a set of Red Hat Enterprise Linux (RHEL) systems that are already running but need specific configurations applied.
To pass, you need three things: technical knowledge, speed, and exam strategy. Most candidates focus on the first two and ignore the third. That is a mistake. 'Exam strategy' means knowing how the exam is structured, what the markers look for, how to prioritise tasks, and how to avoid wasting time on low-value activities.
Let us start with the exam structure. The questions (called 'tasks' or 'objectives') are listed in a document that you can view during the exam. Each task is worth a certain number of points, although you do not know the exact point values. Some tasks require you to complete multiple sub-steps. For example, a task might say: 'Configure a logical volume named data that is 2 GB in size, mount it persistently at /mnt/data, and ensure it is accessible to the group finance.' That single task actually tests three or four separate skills: logical volume management, file system creation, persistent mounting via /etc/fstab, and file permissions or group ownership. If you miss one sub-step, you lose the points for the whole task. That is a key trap: partial credit is not typically given. You either complete the objective fully or you do not get the marks.
Now, time management. With 150 minutes and roughly 20 tasks, you have about 7 or 8 minutes per task on average. However, some tasks are fast (30 seconds to configure a cron job) and some are slow (15 minutes to set up a RAID array). The trick is to do a 'scan-and-plan' phase at the start. Open the task list, read every task, and mentally estimate which are easy and which are hard. Do the easy tasks first. Build confidence and bank marks. Leave the hardest or most time-consuming tasks for the end. If you get stuck on a task for more than 10 minutes, move on. You can come back if you have time.
Common pitfalls include: rebooting a system before checking that your changes will survive a reboot (persistence is tested explicitly); editing configuration files with the wrong tool (use the official Red Hat tools like systemctl and nmcli, not raw text editors, unless the task specifies otherwise); forgetting to enable and start a service separately (enable ensures it starts on boot, start ensures it starts right now — do both); and typos in file paths, usernames, or IP addresses. The exam environment uses a specific set of hostnames and IP addresses that are printed on your exam sheet. Double-check every command you type.
Another major pitfall is not reading the task carefully. Red Hat tasks often contain multiple constraints. For example: 'Create a user named john with a UID of 2000, add him to the group wheel, and set a password.' If you create the user but forget the UID, you fail that part. If you add him to the wrong group, you lose marks. If you set the password on the wrong user, you lose marks. Read the task twice before you type anything.
Finally, practise in a realistic environment. Use virtual machines (VMs) that mirror the exam setup. Red Hat provides official practice exams and a learning subscription. Time yourself. Practise rebooting to verify persistence. The more you simulate exam conditions, the less surprising the real exam will be.
Scan and Plan (First 5 minutes)
Open the task list and read every task from start to finish. Identify which tasks are easy (e.g., set a password, create a user), which are medium (e.g., configure a cron job, set up a logical volume), and which are hard (e.g., configure a network bond, set up a RAID array). This mental map lets you prioritise. Write nothing down — just memorise the order of attack.
Do the Easy Tasks First (Next 60 minutes)
Tackle all quick tasks first: user creation, group management, simple cron jobs, file permissions, setting hostnames. These tasks often take less than 2 minutes each. Completing them early builds confidence and banks marks. Do not skip any easy task because you think it is too simple — marks are marks.
Tackle Medium Tasks (Next 60 minutes)
Now work through tasks that require multiple steps, like creating logical volumes, configuring persistent mounts, enabling firewalld rules, and setting up SSH key authentication. For each task, follow the 8-step workflow: read, identify host, SSH, check state, make change, verify, verify persistence, move on.
Hard Tasks and Leftovers (Last 20 minutes)
If time remains, attempt the hardest tasks: network bonding, RAID configuration, advanced selinux changes. If a task seems impossible after 5 minutes, skip it. Better to spend that 5 minutes verifying your completed tasks than failing a new one. Use this time to double-check persistence (enable, fstab) on all completed tasks.
Final Verdict: Reboot and Verify (Last 10 minutes)
Reboot each system using the reboot command or shutdown -r now. After each reboot, SSH back in. Run systemctl list-units --type=service --state=running to see which services are up. Check mounts with mount or df -h. Verify that users exist with id username. If anything is missing, quickly fix it. This step catches the most common oversight — persistence failures.
Imagine you are a junior Linux administrator at a small company called 'GreenLeaf Tech'. Your boss asks you to set up a new server for the finance team. You have a list of requirements: create a logical volume of 10 GB, mount it at /finance, ensure it is owned by the finance group, and configure a cron job to back up the data every night. This sounds exactly like an EX200 task.
In the real world, you would not rush. You would plan. You would check the existing volume group (the pool of disk space) to see if there is enough free space. You would decide on the file system type (usually XFS on RHEL). You would create the logical volume, format it with mkfs.xfs, mount it temporarily, then add an entry to /etc/fstab so the mount survives a reboot. You would create the finance group if it does not exist, set the group ownership on the mount point, and ensure the permissions allow access. Then you would test: unmount, remount, reboot, verify. That final test — rebooting and checking — is what separates a good admin from a careless one.
Now, how does this relate to exam strategy? The real-world admin has unlimited time (within reason) and can reference documentation. The exam candidate does not. So the exam strategy is about replicating the logical workflow but compressing it. The real-world admin might write a script to automate the whole process. The exam candidate might also write a script, but only if they are fast enough. Scripting is not required, but it can save time if you are skilled.
What does an IT professional actually do with exam review and time management skills on the job? They triage incidents. When a server goes down, you do not fix everything at once. You assess which services are critical, fix those first, and then move to lower-priority items. That is exactly the 'scan-and-plan' approach. They also avoid common pitfalls: they never edit a running configuration file without taking a backup first; they never restart a service without checking the maintenance window; they always test changes in a non-production environment first. These habits are exactly what the EX200 exam is trying to instill.
On a typical day, a sysadmin might:
Check system logs for errors (journalctl -xe)
Monitor disk usage with df -h
Verify that critical services are running with systemctl status
Add a new user account for a contractor
Reset a forgotten password
Troubleshoot a network connectivity issue using ping, traceroute, and ss
Apply a security patch using dnf update
The EX200 exam tests the foundational versions of all these tasks. The review phase is where you check your work: did the user actually get created? Is the service enabled for boot? Did the file system mount correctly? Do not rely on memory. Type the verification commands. Make it a habit.
The EX200 exam tests your ability to apply Linux system administration knowledge under time pressure. Specifically for 'Exam Review and Practical Tips for Success', the exam does not have a dedicated section called 'exam strategy'. Instead, the strategy is embedded in every task. The exam setters assume you will read all tasks, manage your time, and avoid common traps. Your performance on the skills is the test of your strategy.
Question types: all tasks are hands-on. There are no multiple-choice questions. You are given a list of objectives and a set of systems. You must SSH into each system and complete the tasks. The exam interface shows the task list on one side and a terminal on the other. You can switch between systems using SSH. You cannot use the internet or your own notes. The only reference available is the built-in man pages and info pages, plus any files that are already on the systems.
Traps they set:
The 'surprise reboot' trap: a task might say 'ensure the web server starts automatically after a reboot'. A candidate who only starts the service (systemctl start httpd) without enabling it (systemctl enable httpd) will fail that task because the service will not survive a reboot. Always do both start and enable, or use systemctl enable --now httpd to do both at once.
The 'wrong host' trap: the exam gives you three or four virtual machines with different hostnames. A task might say 'on servera, configure a user named alice'. If you accidentally type the command on serverb, you get zero marks. Always check the hostname with the hostname command or by looking at the prompt before you start typing.
The 'partial completion' trap: a task with multiple sub-steps. For example: 'Create a group called sales, create a user called bob, add bob to sales, and set bob's primary group to sales.' If you create the group and the user but forget to change the primary group, you lose all the points. Verify each sub-step explicitly.
The 'persistence check' trap: after configuring something (like a mount point or a network bond), the exam will reboot the system (or you are told to reboot). If your configuration does not survive, you fail. The correct pattern is: configure, test, verify persistence (by checking /etc/fstab, /etc/sysconfig/network-scripts, systemctl enable, etc.), then reboot and verify again.
Key concepts to memorise:
The 8-step workflow for any configuration task: 1. Read the task completely. 2. Identify the target system. 3. SSH into it. 4. Check current state (using commands like lsblk, df, systemctl status). 5. Make the change using the correct tool. 6. Verify the change immediately. 7. Verify persistence (enable or /etc/fstab). 8. Move to the next task. This workflow is your safety net.
The difference between 'start' and 'enable': start runs the service now; enable ensures it runs on boot. Always do both unless the task explicitly says 'without starting' or 'without enabling'.
The importance of the 'reboot test': if you have time at the end of the exam, reboot every system and log back in. Check that your critical services are running and your mounts are present. If anything is missing, you still have a few minutes to fix it.
The 'man page' is your friend: if you forget the exact syntax of a command, use man. The exam gives you full access to man pages. Do not guess. Look it up.
Red Hat specific tools: the exam expects you to use Red Hat tools like nmcli (for networking), systemctl (for services), and firewall-cmd (for firewalld). Do not use legacy commands like ifconfig, service, or iptables. They may still work, but the exam setters prefer the modern tools.
Read every task twice before typing any command — missing a single constraint can cost you all the points for that task.
Always enable a service in addition to starting it, using systemctl enable --now, to ensure it survives a reboot.
SSH into the correct host — double-check the hostname before you start working, or you may configure the wrong machine.
Verify persistence by rebooting each system at the end of the exam and checking that services and mounts are still active.
Use modern Red Hat tools (systemctl, nmcli, firewall-cmd) rather than legacy commands (service, ifconfig, iptables).
Do the easiest tasks first to build confidence and secure marks, then move to harder tasks if time allows.
If a task takes longer than 10 minutes, move on — you can return if you have spare time.
Man pages are allowed and encouraged — use them to confirm command syntax rather than guessing.
Partial credit is very rare — fully complete a task or move on; half-done tasks earn nothing.
Simulate exam conditions in practice: time yourself, reboot to test persistence, and use a bare-minimal setup.
These come up on the exam all the time. Here's how to tell them apart.
Start (systemctl start)
Starts the service immediately, right now.
Does not affect boot behaviour.
If you only start, the service stops after a reboot.
Enable (systemctl enable)
Configures the service to start on boot.
Does not start the service immediately (unless combined with --now).
If you only enable, the service will not run now.
Do Hard Tasks First
Risk of running out of time on hard tasks.
Less confidence boost early on.
May end up with no completed tasks if stuck.
Do Easy Tasks First
Guarantees some marks early.
Builds confidence and momentum.
Leaves hard tasks for leftover time.
Guessing Command Syntax
High risk of typos and errors.
Slows debugging later.
No guarantee the command works as intended.
Using Man Pages
Takes 20-30 seconds to confirm syntax.
Reduces risk of mistakes.
Lets you use unfamiliar commands correctly.
Working on One System at a Time
Clear focus and fewer context-switches.
Easier to track progress per system.
Less chance of applying config to wrong host.
Juggling Multiple Systems Simultaneously
Requires careful note-keeping of changes.
Higher risk of editing the wrong file on the wrong host.
May save a few seconds but increases mistake rate.
Mistake
I should do the tasks in the order they are listed, because that is the logical order.
Correct
You should do easy tasks first to bank marks quickly, then tackle harder tasks. The exam order is not a learning sequence.
Beginners often assume the exam is a linear progression. It is not. The tasks are independent. Doing the hard tasks first can waste time and cause panic if you get stuck.
Mistake
If I reboot the system at the end of the exam, my changes might be lost, so I should not reboot.
Correct
You must reboot (or simulate a reboot) to verify that your configurations are persistent. Rebooting is the only way to test that enabled services and /etc/fstab entries actually work.
Many beginners fear rebooting because they think it will break things or that they will lose the SSH connection. In reality, Red Hat provides console access if SSH breaks. Rebooting and rechecking is the final quality check.
Mistake
I can use any command to achieve the result, as long as it works.
Correct
Red Hat expects you to use the recommended tools (systemctl, nmcli, firewall-cmd). Using legacy tools (ifconfig, service, iptables) may work but can cost you marks if the exam expects the modern equivalent.
Beginners who learned on older Linux distributions often stick with familiar old commands. The exam explicitly tests knowledge of the current RHEL toolset.
Mistake
The man pages are not useful during the exam because they are too slow to read.
Correct
Man pages are your best resource. They are faster than guessing. A quick skim of the SYNOPSIS section can confirm the exact syntax and save you from a typo that costs the whole task.
Under time pressure, people panic and guess. Guessing leads to errors. Taking 20 seconds to check a man page is far faster than debugging a mistake later.
Mistake
I should aim to complete all tasks perfectly. Partial marks will add up.
Correct
Partial marks are rarely given. If you miss one sub-step of a multi-part task, you likely get zero for that entire task. Focus on fully completing fewer tasks rather than partially completing all of them.
Beginners want to attempt everything. It is better to fully complete 15 tasks and skip 5 than to partially complete all 20 and fail many due to missed sub-steps.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. The exam is closed-book. You cannot bring any external materials. However, the man pages, info pages, and any documentation files already installed on the system are fully available to you.
If you break a system (e.g., corrupt the boot configuration), you can request a system rebuild from the proctor. This costs you time — typically 10-15 minutes — and you lose all work on that system. It is better to be cautious and test changes before applying them.
You can reboot at any time, but the most efficient approach is to reboot all systems only during the final 10 minutes for a persistent check. Rebooting during the middle of the exam wastes time that could be spent on other tasks.
Red Hat does not disclose exact point values. All tasks are weighted, but you cannot tell which ones are high-value. That is why you should complete all easy tasks first — they might be worth the same as a hard task.
Using legacy commands is risky. The exam markers expect modern tools (nmcli, ip, systemctl). Ifconfig and route may still function on RHEL 9, but the exam specifically tests knowledge of the current toolset. Stick with modern commands.
Do not submit early. Use the remaining time to reboot every system and verify persistence. Check that cron jobs run, mounts are present, and services are active. Re-read the task list to ensure you have not missed any sub-step. Early finishing is a common cause of unexpected failure.
Yes. You will have SSH access to all provided systems from a 'control node' (also called the 'bastion host'). You can SSH from one system to another. Just make sure you are on the correct host before executing commands.
You've finished Exam Review and Practical Tips for Success. Continue through the EX200 study guide to build a complete picture of the exam.
Done with this chapter?