Red Hat Certified System Administrator (RHCSA) #16 フルスケール模擬試験: 16 のタスク + 解説
#1 試験紹介 から #15 試験のコツ まで、RHCSA の全ドメインを一周しました。このシリーズの最終回は読む記事ではなく 解く記事 です。実際の EX200 と同じく、全ドメインを統合した 16 のタスクを一か所に集めました。択一式ではなく、空のシェルの前でユーザーを作り、LVM を拡張し、SELinux コンテキストを直す実技シナリオで、各タスクには配点が付いています。
推奨される制限時間は実際の試験と同じ 2.5 時間 です。合格ラインは 210/300 (70%) で、16 のタスクの配点を合算して採点します。あるタスクで詰まったら印を付けて飛ばし、配点が高く手に馴染んだタスクから点数を積み上げる運用が合格ラインを越える道です。
RHCSA で最もよくある失点の原因は 設定が再起動後に消えること です。マウントは fstab に、サービスは enable で、ネットワークは NetworkManager の永続設定として残す必要があります。この模擬試験を解くときも、すべてのタスクを終えた後に一度 reboot し、再起動後も作業がそのまま維持されるかを自分で検証してください。各タスクは まず自力で最後まで解いてから 正解を開いてください。先に正解を読むと手が慣れません。
解き方 #
- RHEL 9 または互換ディストリビューション (AlmaLinux・Rocky Linux) を VM として立ち上げ、その上で直接解くのが最も実戦に近いです。ストレージタスクのために、データ用の空のディスクを 1、2 個 (例:
/dev/vdb) VM に追加しておいてください。NFS マウントタスクは、同じネットワークに NFS サーバーをもう 1 台立てるか、タスク内で提示した代替の手順に従えば大丈夫です。 - タスクごとに要求される 永続適用 を抜かさないでください。マウントは fstab に、サービスは
systemctl enableで、ネットワークは nmcli の接続プロファイルとして残してこそ採点基準を満たします。実行だけして永続化を抜かすと、再起動の検証で 0 点になります。 - 16 個を 最後まで解いてから 正解を開いて一度に採点します。途中で正解を見ると実際の試験感覚が薄れます。man page だけを参考にして解く練習を併せて行うと、試験会場の環境に近づきます。
- すべてのタスクを終えたら、必ず一度
rebootした後、再起動されたシステムで各タスクの結果が維持されるかを確認します。マウントが自動で付くか、サービスが自動起動するか、ネットワーク設定が生きているかが、RHCSA 合格を分ける最後の関門です。
ドメイン分布 #
実際の EX200 のドメイン比重に合わせて 16 のタスクを配置しました。ストレージ・ファイルシステムがタスク数が最も多く、合格を分ける核心のドメインです。
| # | ドメイン | タスク数 | タスク番号 |
|---|---|---|---|
| 1 | 必須ツールとシェルスクリプト | 2 | 1, 2 |
| 2 | ブートとシステム運用 | 3 | 3, 4, 5 |
| 3 | ストレージとファイルシステム | 4 | 6, 7, 8, 9 |
| 4 | パッケージとネットワーキング | 2 | 10, 11 |
| 5 | ユーザーとセキュリティ | 3 | 12, 13, 14 |
| 6 | コンテナ | 2 | 15, 16 |
配点はドメイン比重とタスクの難易度を反映し、合計 300 点としました。採点基準は記事末にまとめています。
タスク 1 (15 点): 必須ツールとシェルスクリプト #
/etc の下で名前が .conf で終わるファイルをすべて探し、その一覧を 1 行に 1 つずつ /root/conf-list.txt に保存してください。その後、この一覧から network という文字列を含む行だけを選び /root/conf-network.txt に保存してください。
正解
find でファイルを探して一覧を保存します。
find /etc -type f -name '*.conf' > /root/conf-list.txt保存した一覧から文字列を含む行だけを抜き出します。
grep network /root/conf-list.txt > /root/conf-network.txt解説: find の -name '*.conf' は、シェルがワイルドカードを先に展開しないように必ず引用符で囲む必要があります。標準出力を > で redirection すると結果が画面ではなくファイルに保存され、grep network でもう一度絞って 2 つ目のファイルを作ります。権限拒否メッセージが混ざらないように root で作業するのがすっきりします。
タスク 2 (15 点): 必須ツールとシェルスクリプト #
/root/bin/diskcheck.sh スクリプトを書いてください。引数としてディレクトリパスを 1 つ受け取り、そのディレクトリが存在すればディレクトリの総使用量を人が読みやすい単位で出力して終了コード 0 で終わる必要があります。引数がないかディレクトリが存在しなければ、標準エラーに使い方を出力して終了コード 1 で終わる必要があります。書いた後、実行権限を付与してください。
正解
スクリプトを書きます。
#!/usr/bin/bash
if [ -z "$1" ] || [ ! -d "$1" ]; then
echo "Usage: $0 <directory>" >&2
exit 1
fi
du -sh "$1"
exit 0実行権限を付与して動作を確認します。
mkdir -p /root/bin
chmod +x /root/bin/diskcheck.sh
/root/bin/diskcheck.sh /etc
/root/bin/diskcheck.sh ; echo $?解説: [ -z "$1" ] は引数が空かを、[ ! -d "$1" ] はディレクトリではないかを検査し、2 つの条件を || で結んでどちらか一方でも真ならエラーとして処理します。変数は空白を含むパスに備えて常に二重引用符で囲み、使い方は >&2 で標準エラーに送ります。du -sh の -s は合計、-h は人が読みやすい単位を意味し、終了コードは採点項目なので exit で明示します。
タスク 3 (15 点): ブートとシステム運用 #
root パスワードを忘れた状況を想定します。システムを再起動して rescue モードに入り、root パスワードを Redhat123 に再設定した後、SELinux ラベルが壊れないように対処して正常なブートに復帰してください。
正解
ブート時に GRUB2 メニューでカーネル行 (linux で始まる行) を e で編集して末尾に rd.break を追加し、Ctrl+x でブートします。switch_root シェルに入ったら次を実行します。
mount -o remount,rw /sysroot
chroot /sysroot
passwd root
# 新しいパスワードとして Redhat123 を入力
touch /.autorelabel
exit
exit解説: rd.break は initramfs の段階で止まるため、実際のルートは /sysroot に読み取り専用でマウントされています。したがって remount,rw で書き込み可能にして chroot で入ってこそ passwd が実際のシステムに反映されます。/.autorelabel を作らないと SELinux コンテキストがずれて /etc/shadow の更新が無視され、次のブートでログインが塞がれるのが最もよくある落とし穴です。autorelabel 後の最初のブートは、ラベルの再付与のためにもう一度再起動されます。
タスク 4 (15 点): ブートとシステム運用 #
システムのデフォルトのブート target をグラフィックモードではなくマルチユーザー (テキスト) モードに変えてください。変更後に現在のデフォルト target が何かを確認し、この設定が再起動後も維持される必要があります。
正解
デフォルト target を設定して確認します。
systemctl set-default multi-user.target
systemctl get-default解説: set-default は /etc/systemd/system/default.target シンボリックリンクを新しい target に張り直すため、それ自体で永続設定であり再起動後も維持されます。今のセッションをすぐそのモードに切り替えるには systemctl isolate multi-user.target を追加で使いますが、デフォルト値の変更だけが要求なら set-default で十分です。isolate だけ使って set-default を抜かすと、再起動時に元のモードに戻るのが落とし穴です。
タスク 5 (15 点): ブートとシステム運用 #
毎日午前 3 時 30 分に /usr/local/bin/backup.sh を実行するジョブを systemd timer で構成してください。スクリプトはすでに存在し、実行権限があると想定します。service と timer のユニットを作り、timer を有効化した後、次の実行予定時刻を確認してください。
正解
service ユニットと timer ユニットを作ります。
cat > /etc/systemd/system/backup.service <<'EOF'
[Unit]
Description=Daily backup job
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
EOFcat > /etc/systemd/system/backup.timer <<'EOF'
[Unit]
Description=Run backup daily at 03:30
[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
[Install]
WantedBy=timers.target
EOFtimer を有効化して予定時刻を確認します。
systemctl daemon-reload
systemctl enable --now backup.timer
systemctl list-timers backup.timer解説: timer は同じ名前の service (backup.timer ↔ backup.service) を自動でトリガーするため、service は Type=oneshot でジョブだけ定義すれば大丈夫です。timer 側にだけ [Install] と WantedBy=timers.target を置いて enable --now で点けてこそブート時に自動起動し、service を enable するのではないという点が落とし穴です。Persistent=true は予定時刻にシステムが落ちていた場合、ブート後に一度実行を補います。cron で解くなら crontab -e に 30 3 * * * /usr/local/bin/backup.sh を入れても大丈夫です。
タスク 6 (20 点): ストレージとファイルシステム #
空のディスク /dev/vdb にボリュームグループ vgdata を作り、その中にサイズ 500MiB の論理ボリューム lvweb を作成してください。この論理ボリュームを XFS でフォーマットして /web ディレクトリにマウントし、再起動後も自動でマウントされるように fstab に登録してください。
正解
物理ボリューム・ボリュームグループ・論理ボリュームを順に作ります。
pvcreate /dev/vdb
vgcreate vgdata /dev/vdb
lvcreate -L 500M -n lvweb vgdataXFS でフォーマットしてマウントポイントを作ります。
mkfs.xfs /dev/vgdata/lvweb
mkdir /webUUID で fstab に登録した後、検証のためマウントします。
blkid /dev/vgdata/lvweb
echo 'UUID=<上で確認した UUID> /web xfs defaults 0 0' >> /etc/fstab
mount -a
df -h /web解説: LVM の作成順序は pvcreate → vgcreate → lvcreate で、論理ボリュームのデバイスパスは /dev/<vg>/<lv> または /dev/mapper/<vg>-<lv> の形です。fstab にはデバイス名ではなく UUID を使うほうが安全で、mount -a で fstab の文法エラーを事前に捕まえます。fstab に誤字があると次のブートが emergency モードに落ちるため、登録直後に mount -a がエラーなく終わるかを必ず確認するのが核心です。
タスク 7 (20 点): ストレージとファイルシステム #
タスク 6 で作った論理ボリューム lvweb のサイズを 800MiB に拡張し、その上の XFS ファイルシステムもマウントを維持したまま拡張されたサイズをすべて使うように大きくしてください。ボリュームグループに余裕がないと拡張できないので、余裕を先に確認してください。
正解
ボリュームグループの余裕を確認して論理ボリュームを拡張します。
vgs vgdata
lvextend -L 800M /dev/vgdata/lvwebXFS ファイルシステムをオンラインで大きくします。
xfs_growfs /web
df -h /web解説: 論理ボリュームの拡張は lvextend でメタデータ上のサイズだけを大きくするため、ファイルシステムがその空間を実際に使うには別途の拡張が必要です。XFS は xfs_growfs (引数にマウントポイント)、ext4 は resize2fs (引数にデバイス) を使う点が核心的な違いで、XFS は縮小できず拡張だけできます。lvextend -r -L 800M のように -r を付ければファイルシステムの拡張を一度に処理することもできます。余裕が足りないと lvextend が失敗するため、vgs で Free 空間を先に確認します。
タスク 8 (20 点): ストレージとファイルシステム #
空のディスク /dev/vdc を LUKS で暗号化してください。パスフレーズは Secret123 を使い、ロック解除時の名前は cryptdata にマッピングしてください。解除されたデバイスを ext4 でフォーマットして /secure にマウントし、ブート時にパスフレーズを尋ねて自動でロック解除・マウントされるように crypttab と fstab に登録してください。
正解
ディスクを LUKS で初期化してロックを開きます。
cryptsetup luksFormat /dev/vdc
# YES を入力した後、パスフレーズ Secret123 を設定
cryptsetup luksOpen /dev/vdc cryptdataマッピングされたデバイスをフォーマットしてマウントします。
mkfs.ext4 /dev/mapper/cryptdata
mkdir /secure
mount /dev/mapper/cryptdata /securecrypttab と fstab に登録します。
blkid /dev/vdc
echo 'cryptdata UUID=<vdc の LUKS UUID> none' >> /etc/crypttab
echo '/dev/mapper/cryptdata /secure ext4 defaults 0 0' >> /etc/fstab
mount -a解説: LUKS は 2 段階で永続化します。/etc/crypttab がブート時に /dev/vdc を cryptdata としてロック解除し (3 番目のフィールドが none ならブート中にパスフレーズを尋ねる)、/etc/fstab はそうして解かれた /dev/mapper/cryptdata をマウントします。crypttab の UUID は、マッピングされたデバイスではなく暗号化元 (/dev/vdc) の UUID でなければならない点が最もよくある落とし穴です。crypttab を抜かすとブート時にマッピングがなく、fstab のマウントが失敗します。
タスク 9 (20 点): ストレージとファイルシステム #
NFS サーバー nfs.example.com が /exports/shared を export しています。この共有を AutoFS で構成して /mnt/shared にアクセスしたときだけ自動マウントされるようにしてください。AutoFS パッケージをインストールしてマップファイルを書いた後、サービスを有効化してください。
正解
パッケージをインストールしてマスターマップにマウントポイントを登録します。
dnf install -y autofs
echo '/mnt /etc/auto.shared' >> /etc/auto.master.d/shared.autofs直接マップファイルを書きます。
echo 'shared -rw nfs.example.com:/exports/shared' > /etc/auto.sharedサービスを有効化し、アクセスで自動マウントを確認します。
systemctl enable --now autofs
ls /mnt/shared
mount | grep shared解説: AutoFS はマスターマップ (/etc/auto.master または auto.master.d/*.autofs) に「マウントの親パス + マップファイル」を登録し、マップファイルに「下位キー + オプション + リモートパス」を書く 2 段階の構造です。マスターマップに /mnt を置いてマップファイルに shared を置くと、実際のマウントポイントは /mnt/shared になり、そのディレクトリを自分で作る必要はありません (AutoFS が管理)。サービスを enable --now で点けてこそ再起動後も維持され、NFS クライアントユーティリティがなければ dnf install nfs-utils も必要です。
タスク 10 (15 点): パッケージとネットワーキング #
postgresql モジュールストリームのうちバージョン 15 を有効化してインストールしてください。インストール後に有効化されたストリームが 15 かを確認してください。
正解
利用できるストリームを確認してバージョン 15 をインストールします。
dnf module list postgresql
dnf module install -y postgresql:15有効化されたストリームを確認します。
dnf module list postgresql --enabled解説: AppStream のモジュールは同じソフトウェアの複数のバージョンをストリームとして提供し、dnf module install postgresql:15 はストリーム 15 を有効化してデフォルトプロファイルを併せてインストールします。1 つのモジュールでは 1 つのストリームだけが有効化されるため、別のバージョンがすでに点いていれば dnf module reset postgresql で初期化した後、望むストリームをインストールします。--enabled の一覧で 15 の横に [e] の表示が見えれば正常です。
タスク 11 (15 点): パッケージとネットワーキング #
デフォルトのネットワーク接続に静的 IPv4 アドレス 192.168.50.20/24、ゲートウェイ 192.168.50.1、DNS 192.168.50.1 を設定してください。設定は nmcli で永続適用し、変更を有効化した後、適用結果を確認してください。接続名は System eth0 と想定します。
正解
接続名を確認して静的アドレスを設定します。
nmcli connection show
nmcli connection modify "System eth0" \
ipv4.addresses 192.168.50.20/24 \
ipv4.gateway 192.168.50.1 \
ipv4.dns 192.168.50.1 \
ipv4.method manual変更を適用して結果を確認します。
nmcli connection up "System eth0"
ip addr show
nmcli connection show "System eth0" | grep ipv4解説: nmcli connection modify は接続プロファイルをディスクに永続保存するため、再起動後も維持されます。ipv4.method を manual に変えないと、静的アドレスを入れても DHCP が動き続けて意図した IP が掴めないのがよくある落とし穴です。修正だけでは即時に反映されないため、connection up (または nmcli device reapply) で再び有効化する必要があり、検証は ip addr で実際のインターフェースにアドレスが付いたかを確認します。
タスク 12 (20 点): ユーザーとセキュリティ #
グループ devteam を作り、ユーザー alice と bob をこのグループの補助グループのメンバーとして追加して作成してください。alice にはパスワードなしで sudo の全権限を付与し、bob のアカウントは 90 日ごとにパスワードを変更するように有効期限ポリシーを設定してください。
正解
グループとユーザーを作ります。
groupadd devteam
useradd -G devteam alice
useradd -G devteam bob
passwd alice
passwd bobalice にパスワードなしの sudo 権限を付与します。
echo 'alice ALL=(ALL) NOPASSWD: ALL' > /etc/sudoers.d/alice
visudo -cf /etc/sudoers.d/alicebob のパスワード最大使用期間を設定します。
chage -M 90 bob
chage -l bob解説: 補助グループは useradd -G (すでにいるユーザーなら usermod -aG で既存のグループを保存) で指定し、-a なしで usermod -G だけ使うと既存の補助グループがすべて飛ぶのが落とし穴です。sudo 権限は /etc/sudoers を直接いじるより /etc/sudoers.d/ の下のファイルとして置くほうが安全で、visudo -cf で文法を検査する必要があります。chage -M 90 はパスワードの最大使用期間を 90 日にし、-l でポリシーを確認します。
タスク 13 (20 点): ユーザーとセキュリティ #
ディレクトリ /srv/project を作り、グループ devteam がこのディレクトリに読み取り・書き込み・実行ができるように ACL を設定してください。また、このディレクトリに今後新しく生まれるファイルとディレクトリも devteam が同じ権限を自動で持つように、デフォルト ACL を設定してください。
正解
ディレクトリを作り、ACL とデフォルト ACL を設定します。
mkdir -p /srv/project
setfacl -m g:devteam:rwx /srv/project
setfacl -m d:g:devteam:rwx /srv/project設定された ACL を確認します。
getfacl /srv/project解説: setfacl -m g:devteam:rwx は現在のディレクトリ自体にグループ ACL を掛けるもので、d: (default) の接頭辞を付けた項目は、そのディレクトリの中に 今後新しく生まれる ファイル・ディレクトリが継承するデフォルト権限を定めます。既存の項目と default の項目は別物なので、両方を設定してこそ「今のアクセス」と「これから生まれるもの」の両方が満たされます。getfacl の出力で default: の行が見えるかでデフォルト ACL を検証します。
タスク 14 (20 点): ユーザーとセキュリティ #
Web サーバーが非標準のディレクトリ /srv/www のコンテンツを提供するように設定したらアクセスが拒否されます。SELinux が Enforcing 状態でこのディレクトリに正しいコンテキストを永続的に付与して問題を解決してください。また、ユーザーのホームディレクトリを Web で提供する SELinux boolean を永続的に点けてください。
正解
ディレクトリに Web コンテンツコンテキストを永続ルールとして登録して適用します。
semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"
restorecon -Rv /srv/wwwboolean を永続的に点けます。
setsebool -P httpd_enable_homedirs on確認します。
ls -Zd /srv/www
getsebool httpd_enable_homedirs解説: コンテキストの変更は 2 段階です。semanage fcontext -a がポリシーデータベースに永続ルールを追加し、restorecon がそのルールどおりに実際のファイルにラベルを付けます。chcon だけ使うと今は通りますが、restorecon や relabel のときに元に戻るため永続ではないという点が核心の落とし穴です。boolean は setsebool に -P を付けてこそディスクに保存されて再起動後も維持され、-P なしで点けると一時的です。(/.*)? の正規表現は、ディレクトリ自体とその中のすべての項目を含みます。
タスク 15 (20 点): コンテナ #
Red Hat レジストリ (または docker.io) から nginx イメージを受け取り、ホストの /srv/web-content をコンテナの /usr/share/nginx/html に読み取り専用でマウントし、ホストの 8080 ポートをコンテナの 80 ポートに繋ぐコンテナ mynginx を、root ではなく一般ユーザー alice で実行してください。
正解
alice でログインした後、イメージを受け取ってコンテナを実行します。
su - alice
mkdir -p ~/web-content
podman pull docker.io/library/nginx
podman run -d --name mynginx \
-p 8080:80 \
-v ~/web-content:/usr/share/nginx/html:Z,ro \
nginx状態を確認します。
podman ps
curl http://localhost:8080解説: rootless Podman は一般ユーザーのセッションでそのまま動作するため、su - alice でそのユーザー環境に入って実行するのが核心です。-v の :Z は SELinux がホストディレクトリにコンテナ用のラベル (container_file_t) を付けてアクセス拒否を防ぎ、:ro は読み取り専用マウントです。rootless では 1024 未満のポートをホスト側へ直接開けない制約があるため、ホストポートには 8080 のような高い番号を使う点に注意します。
タスク 16 (20 点): コンテナ #
タスク 15 の mynginx コンテナが alice でログインしなくても、つまりブート時に自動で始まる systemd サービスとして回るように quadlet で構成してください。また、alice がログアウトしてもサービスが維持されるように linger を点けてください。
正解
既存のコンテナを片付け、alice の quadlet ディレクトリにユニットファイルを作ります。
su - alice
podman rm -f mynginx
mkdir -p ~/.config/containers/systemd
cat > ~/.config/containers/systemd/mynginx.container <<'EOF'
[Container]
Image=docker.io/library/nginx
ContainerName=mynginx
PublishPort=8080:80
Volume=%h/web-content:/usr/share/nginx/html:Z,ro
[Service]
Restart=always
[Install]
WantedBy=default.target
EOFユニットを生成・起動します。
systemctl --user daemon-reload
systemctl --user enable --now mynginx.service
systemctl --user status mynginx.servicealice がログアウトしても維持されるように root で linger を点けます。
exit
loginctl enable-linger alice解説: quadlet は ~/.config/containers/systemd/*.container ファイルを置くと systemd の生成器が自動で mynginx.service ユニットに変換してくれる方式で、daemon-reload の後に --user でそのサービスを点けます。quadlet ファイルの名前が mynginx.container ならサービス名は mynginx.service になる点が紛らわしいです。rootless の user サービスはそのユーザーがログインしているときだけ回るのがデフォルトなので、ブート時の自動起動とログアウト後の維持のために loginctl enable-linger が必ず必要です。
採点基準 #
各タスクの配点を合算して採点します。合計は 300 点で、210 点以上が合格圏 です。
| ドメイン | タスク・配点 | 小計 |
|---|---|---|
| 必須ツールとシェルスクリプト | 1(15) · 2(15) | 30 |
| ブートとシステム運用 | 3(15) · 4(15) · 5(15) | 45 |
| ストレージとファイルシステム | 6(20) · 7(20) · 8(20) · 9(20) | 80 |
| パッケージとネットワーキング | 10(15) · 11(15) | 30 |
| ユーザーとセキュリティ | 12(20) · 13(20) · 14(20) | 60 |
| コンテナ | 15(20) · 16(20) | 40 |
| 合計 | (合計) | 300 |
採点は実際の試験と同じく 成果物基準 です。コマンドをどう打ったかではなく、作られたユーザー・ボリューム・マウント・サービスの最終状態が要件と一致するかを見ます。特に採点の直前にシステムが 再起動 されるため、永続化を抜かしたタスクは実行に成功していても 0 点になります。1 つのタスクの中でも権限・サイズ・コンテキスト・オプションのような項目別に部分点が分かれるため、詰まる項目があっても埋められる部分は最後まで埋めるほうが点数に有利です。
ドメイン別の弱点復習 #
採点後、点数が低いドメインを下表の該当記事に戻って復習してください。
| ドメイン | 関連タスク | 復習する記事 |
|---|---|---|
| 必須ツールとシェルスクリプト | 1, 2 | #2 · #3 |
| ブートとシステム運用 | 3, 4, 5 | #4 · #9 |
| ストレージとファイルシステム | 6, 7, 8, 9 | #5 · #6 · #7 |
| パッケージとネットワーキング | 10, 11 | #8 · #10 |
| ユーザーとセキュリティ | 12, 13, 14 | #11 · #12 · #13 |
| コンテナ | 15, 16 | #14 |
特定のタスクで時間が足りなかったなら、ドメイン知識より手の速さの問題かもしれません。その場合は #15 試験のコツと時間管理 を読み直し、同じ 16 のタスクを時間を計ってもう一度解いてください。LVM 拡張と LUKS・SELinux コンテキストは一度手に馴染むと、タスクあたりの所要時間が目に見えて減ります。
シリーズを終えて #
#1 の試験紹介から出発し、シェルツール・スクリプト・ブート・systemd・LVM・LUKS・ファイルシステム・NFS・パッケージ・ネットワーキング・ユーザー・sudo・ACL・firewalld・SELinux・Podman まで、RHCSA の全ドメインを 16 編で通過しました。この模擬試験で 210 点を越えたなら、実際の試験会場でも十分に合格ラインを越えられる手ができています。おめでとうございます。
RHCSA が RHEL システム管理者の実技だったとすれば、次の段階はその手作業を Ansible で自動化する RHCE (EX294) で、RHCSA の保有が RHCE 受験の前提条件なので、合格の勢いを引き継いで次の実技に進まれることをおすすめします。