Skip to main content

Final Practice Exam

Hands-On Lab


Photo of Rob Marti

Rob Marti

Linux Training Architect I in Content





The Red Hat Certified Systems Administrator, or EX 200, exam is one of the most highly regarded entry-level exams in the Linux world. The skills you learn while preparing for the exam will not only prepare you to pass the exam itself, but also to perform real-world activities in a real production environment. Instead of a multiple-choice test, the exam takes place in a real environment. This makes the RHCSA an extremely desirable certification. This hands-on lab will walk you through similar scenarios to those you may find on the exam and will provide insight to the preparations you need to make to pass the exam. Please note, this exam should be taken after you have completed the RHCSA course. This practice exam should not necessarily be used as a study guide, but as a readiness indicator. The repo/GPG key required for the exam can be found here:

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Red Hat Certified System Administrator Exam Prep


The Red Hat Certified Systems Administrator, or EX 200, exam is one of the most highly regarded entry-level exams in the Linux World. The skills learned while preparing for the exam not only prepare you to pass the exam, but to perform real-world activities in a real production environment. The exam itself places you in a real environment, as opposed to in front of a multiple-choice test. This makes the RHCSA an extremely desirable certification. This Learning Activity will walk you through similar scenarios to those you may find on the exam and will help provide insight to the preparations needed to pass the exam. Please note, this is to be taken after you have completed the RHCSA course and should not be necessarily used as a study guide, but as a readiness indicator. The repository/GPG key required for the exam is here:

The other half is on the filesystem of the VM, here:


Get Logged In

The credentials and server IP in the hands-on lab overview page are not for the SSH protocol, they are for VNC, and the server is listening on port 5901. Just as it is in the real exam, SSH is disabled. To simulate sitting for the exam, we're going to VNC into a machine, then run most of the lab in a virtual machine that we create from there.

We'll start by running sudo -i to become root once we're logged into the lab server and have a terminal open.

Starting the Guest VM

List the virtual machines that exist on the system with virsh list --all. We'll see one called centos7.0. That's the one we need to start up. Let's install Virtual Machine Manager (yum -y install virt-manager) and launch it with virt-manager. Once it's up, we should see that same centos7.0 listed. Hit the Play button and wait until the VM has a Running status.

When it's running, click the Open button, where we're greeted with a login prompt. We don't have a password, so we'll have to reboot into an emergency shell, where we can set one. Reboot the VM (using the menu in the manager -- the button next to Pause has a dropdown).

When the list of bootable kernels comes up, make sure the first is highlighted and press e. Using the editor we land in, arrow down and over to the end of the line starting with linux16 and ending with rhbg quiet. We need to add rd.break to the end of that line. Press Ctrl + X to save and exit.

Now, we should land at an emergency shell:


Running an ls command will show that there's a sysroot directory here. This is where everything gets mounted, so we'll run this:

switch_root:/# mount -o remount,rw /sysroot/

To make that our new root environment, run:

switch_root:/# chroot /sysroot

Now we can set the root password for the VM, and make sure that SELinux relabels the system when it boots:

sh-4.2/# passwd root
New password:
Retype new password:
passwd: all authentication toekns updated successfully
sh-4.2/# touch .autorelabel
sh-4.2/# exit

Back at the emergency prompt, we'll run another mount command:

switch_root:/# mount -o remount,ro /sysroot/
switch_root:/# logout

This will force the system to reboot, with our new root password in effect. It may take a few minutes for SELinux to relabel the filesystem.

Once we're at a login prompt, log in as root with the password we set.

Installing and Configuring Apache

We need to set Apache up, but not quite the same way as someone normally would. We want websites housed in /var/web/, not the usual /var/www/html spot.

Download Apache

We can install Apache using this command:

[root@host]# yum install httpd

YUM Trouble

We've got no YUM repositories installed, so this won't work. Before we can yum install anything, we'll have to set a repo up. Let's look at an example, on the lab server:

[root@lab_server]# cd /etc/yum.repos.d
[root@lab_server]# ls

This will show us a few repo files. Let's look at one:

[root@lab_server]# cat epel.repo

We're going to a file from scratch on the VM. There will be an example in /etc/yum.conf we can use as a guide. Create it with whatever text editor you like (we're using Vim here) with:

[root@host]# vim /etc/yum.repos.d/base.repo

Put these contents into the file:

name=Practice Exam Base

Now we can try listing our repositories with a yum repolist.

Network Trouble

Wow, we can't win! Just kidding, we'll get there. We've got no functioning network though, so we'll have to fix that first. Let's see what we've got for interfaces and what information a couple commands will give us:

[root@host]# ip a s
[root@host]# nmcli con show

Things look ok, so let's see if we can just bring up our interface:

[root@host]# nmcli con up eth0

Running another ip a s will show that we've got an IP address now, so let's retry the yum repolist command again and see what happened.

Hey! We've got liftoff! Now, let's go back to Apache...

Try Downloading Apache Again

[root@host]# yum install httpd

Configure Apache

Now we've got to edit Apache's configuration file (/etc/httpd/conf/httpd.conf) to get our document root changed. There's a line in there by default that reads DocumentRoot "/var/www/html". We need it to say DocumentRoot "/var/web". There are also two <Directory "/var/www/html"> directives that need to be altered. Just change /var/www/html to /var/web in both spots.

Now we can start Apache:

[root@host]# systemctl start httpd

Well, maybe not quite yet. Why are we getting the error? We can run a systemctl status httpd. There's a line indicating that /var/web isn't a directory. Well, that makes sense, since we never created it. Let's do it with a mkdir /var/web, then try again, this time with feeling:

[root@host]# systemctl start httpd

Yay! It's up! There's nothing to see yet though, because Apache's document root is an empty directory. Let's make an index.html file:

[root@host]$ echo "Hello world" > /var/web/index.html

Test Apache

Now, let's either scroll back, or run ip a s again to get it, and snag our machine's IP address. In the lab server's terminal, we should be able to see that web page:

[root@lab_server]# curl http://&ltIP_ADDRESS>/

We got our hopes up too early. Web traffic isn't coming through. Is it maybe the firewall?

Firewall Trouble

Let's check our firewall settings on the VM:

[root@host]# firewall-cmd --list-services

There's no http listed, so we'll have to add it, make it permanent, and force the firewall to reload the rules:

[root@host]# firewall-cmd --add-service=http --permanent
[root@host]# firewall-cmd --reload
[root@host]# firewall-cmd --list-services

Now we should see it listed. So let's try the curl command again, back on the lab server.

It's still failing? How could that be? The error is spouting off about permissions. On the VM, an ls -l /var/web/ shows that anyone has read access. An ls -lZ though, which shows what SELinux has to say about things, tells us that index.html's content type is var_t. Running ls -l /var/www/html shows that by default, SELinux is looking for Apache things to have a content type of httpd_sys_content_t.

Changing SELinux Settings

Let's set a different content label with this:

[root@host]# semanage

We don't have semanage installed apparently. What's the package called? Let's look for anything "sort of like" semanage with this:

[root@host]# yum provides */semanage

In the output, we'll see three things returned. Two of them are just header files though. The install command we want to run is this, for the third one that actually is a package:

[root@host]# yum -y install policycoreutils-python

The best way to move forward is to change the content type of the directory so that it survives not only a reboot, but a relabeling:

[root@host]# semanage fcontext -a -t httpd_sys_content_t '/var/web(/.*)?'

This command will take a while to run. It changes things in the SELinux database. Once it's done, we can apply changes to the actual filesystem with:

[root@host]# restorecon -R /var/web

Now if we run an ls -lZ on /var/web, we'll see that the content label is correct. And, if we head back over to the lab server and run the curl command again, we'll see the "Hello world" text that's in out index.html file.

User Creation

We need to create three users that belong to the instructors group, Derek, Tom, and Kenny. Then we need to make sure Tom cannot login to a shell. We also want to set Tom's account to expire in 10 days from the current date.

Create and Modify Users

We'll create the users with the useradd command:

[root@host]# useradd tom
[root@host]# useradd kenny
[root@host]# useradd derek

Create the instructors Group

Then we'll create the instructors group that we want them all in:

[root@host]#  groupadd instructors

Add the Users to the Group

Now we'll add them all to the group:

[root@host]# usermod -aG instructors tom
[root@host]# usermod -aG instructors kenny
[root@host]# usermod -aG instructors derek

Remove Tom's Ability to Log into a Shell:

This prevents Tom from logging into a shell:

[root@host]# usermod -s /sbin/nologin tom

Make Tom's Account Expire in Ten Days

We can set Tom's account to expire ten days from now with this:

[root@host]# chage -E $(date -d "+10 days" "+%Y-%m-%d") tom

Modify the System Umask

We want all new files created on the system to have a different umask than they do now. Let's edit /etc/profile, and find the umask section. There's an if/else conditional in there, with two umask values shown. Change them both so that the last number is 6. This will give "others" no permissions at all on files by default. We need to do the same thing in /etc/bashrc.

Find Files with Specific Criteria

We need to find files in /etc with a few different criteria. They must be in /etc itself, not subdirectories of /etc. They must also not have been modified with the last 720 days. We'll save our list of files in /root/oldfiles. This command will do it:

[root@host]# find /etc/ -maxdepth 1 -mtime +720 > /root/oldfiles

Get Specific Messages and Create an Archive of Log Files

We're looking for anything in a log related to ACPI. To find matching lines in the log file, we'll use grep, then redirect the output to our file:

[root@host]# grep ACPI /var/log/messages > /root/logs

Then, to archive and compress all of /var/log:

tar -czf /tmp/log_archive.tgz /var/log/

Modify the GRUB Timeout

We simply edit /etc/default/grub, and change the GRUB_TIMEOUT to 1.

Then we'll have to grub2-mkconfig to rebuild the grub configuration and make the change take effect.

Create a CRON Job

To edit a user's crontab (derek in this case), we can run:

[root@host]# crontab -e -u derek

And then the format of the line for this task would be this:

27 16 * * * cat /etc/redhat-release > /home/derek/release

Remember that the crontab editor is Vim, so hit i to get into edit mode, make any changes, then Esc (to get out of edit mode), and finally wq to write and quit.

Modify NTP Settings

The NTP client in RHEL and CentOS is chrony, and the configuration file for it is /etc/chrony.conf.

We'll edit that file,removing the default lines that begin with server and writing a new one like this:


Create a Swap Partition

First we need to see what we've got for existing partitions:

[root@host]# fdisk -l

Then we can create a new partition on /dev/vdb:

[root@host]# fdisk /dev/vdb

In fdisk, we've got some keystrokes ahead of us:

  • n to create a new partition
  • Accept the default for partition number
  • Accept the default for starting sector
  • Use +800M for the ending sector
  • l to view the different types of partitions
  • t to set the partition type (use 82 to set it to Linux Swap)
  • w to write the changes

Now we need to make sure the kernel knows about the changes:

[root@host]# partprobe

To make it a swap type of partition, run:

[root@host]$ mkswap /dev/vdbX

X is the partition number.

We can run blkid to get the UUID of the partition, then add a line in /etc/fstab:

UUID="LONG-UUID-STRING-COPIED-FROM-blkid" swap        swap    defaults        0 0

Save and exit, then we'll run swapon -a.

Running the free command will verify everything is correct.

Create an LVM Disk and Mount It Persistently

First we need to create a physical volume. Let's assume our disk is /dev/sdb (but knowing that it might be something else):

[root@host]# pvcreate /dev/sdb

We hit a snag. There's no pvcreate on our system! This is an easy fix:

[root@host]# yum -y install lmv2

Then we need to create the Volume Group named VG-A with a 32M Physical Extent size:

[root@host]# vgcreate VG-A /dev/sdb -s 32m

We create the Logical Volume named LV-A with 30 extents:

[root@host]# lvcreate -n LV-A -l 30 VG-A

Now we can format the volume:

[root@host]# mkfs.xfs /dev/VG-A/LV-A

And finally, we can then edit /etc/fstab to add the following line:

/dev/mapper/VG--A-LV--A     /mnt    xfs    defaults    0 0

Change the Hostname of the Server

This task is easy, just a one liner. We're changing the name of our VM host to rhcsa:

[root@host]# hostnamectl set-hostname rhcsa

All we have to do is log out and we can already see that the login prompt reflects the new hostname.

Utilize for SSO and Configure autofs to Mount Users Home Directories on Login

Before we set any of this up, we've got to install some software packages:

[root@lab_server]# yum -y install authconfig-gtk nss-pam-ldapd pam_krb5 autofs nfs-utils openldap-clients

It would be best to have these package names memorized, rather than having to hunt around for them during the exam.

Once everything is installed, we'll run this:

[root@lab_server]# authconfig-gtk

In the popup window, set these:

  • User Account Database: LDAP
  • LDAP Search Base DN: dc=linuxacademy,dc=com
  • LDAP Server: ldap://

Check the Use TLS to encrypt connections, then click the Download CA Certificate button. In the next popup, as a Certificate URL, enter Leave the Authentication Method set to Kerberos, and leave the Use DNS to locate KDCs for realms box checked.

In the Advanced Options tab, check Create home directories on the first login.

Click Apply, and the window will close.

We need to create a file, /etc/auto.master.d/ldap.autofs, with these contents:

/home/guests /etc/auto.ldap

Afterward, we've got to create the /etc/auto.ldap file that we just referenced, and put this in it:

* -rw

Edit /etc/pam.d/sshd and add a line in the #%PAM-1.0 section like this:

auth    sufficient

To make this last change take effect, restart the SSH server:

[root@lab_server]$ systemctl restart sshd

We can test it out by logging in as another user, and creating some files:

[root@lab_server]$ su - ldapuser1
[ldapuser1@lab_server]# touch file
[ldapuser1@lab_server]# echo foo > file2
[ldapuser1@lab_server]# ls

We got a Creating home directory... message with the su - command, and we can read and write to it as the user.


Wow, that's quite a lab. We've gone through a bunch of tasks that you're apt to see on the RedHat exam, and made it to the end. Congratulations, and good luck at the exam!