Red Hat Certified Engineer (RHCE) #19 フルスケール模擬試験: 15 のタスク + 解説

読了 17分

#1 試験の紹介 から #18 試験のコツ まで、RHCE の全ドメインを一周しました。このシリーズの最終回は読む記事ではなく 解く記事 です。実際の EX294 と同じく、全ドメインを統合した 15 のタスクを一か所に集めました。択一式ではなく、空の control node で直接プレイブックを書いて実行する実技シナリオで、各タスクには配点が付いています。

推奨される制限時間は実際の試験と同じ 4 時間 です。合格ラインは 210/300 (70%) で、15 のタスクの配点を合算して採点します。あるタスクで詰まったら印を付けて飛ばし、配点が高く手に馴染んだタスクから点数を積み上げる運用が合格ラインを越える道です。

RHCE はコマンドを一度うまく打つ試験ではなく、同じプレイブックを何度回しても結果が同じ という冪等性を検証する試験です。すべての task はできるかぎりモジュールで書き、commandshell の乱用を避け、最新の環境では ansible.builtin.copy のように FQCN (Fully Qualified Collection Name) でモジュールを書く習慣が、採点とデバッグの両方を助けます。各タスクは まず自力で最後まで解いてから 正解を開いてください。先に正解を読むと手が慣れません。

解き方 #

  1. control node 1 台と managed node 複数台で組んだ環境で解くのが最も実戦に近いです。ローカルで難しければ、クラウド VM 3、4 台で control node 1 台と managed node node1node4 を立てておきます。inventory と SSH キー、become まで自分で組んだことのある人は、試験会場でも落ち着いて対応できます。
  2. 書いたプレイブックは必ず 2 回実行 します。2 回目の実行で changed が 0 になって初めて冪等性が検証されたことになります。
冪等性チェック — 2回実行
ansible-navigator run -m stdout site.yml
ansible-navigator run -m stdout site.yml   # 2 回目: changed=0 を確認
  1. インターネットがないので、モジュールの使い方は ansible-doc <module> で探します。ドキュメント下部の EXAMPLES を素早く見る習慣が時間を節約します。このシリーズで整えた ansible.cfginventoryremote_userbecome のデフォルト値を先に適用すると、毎回のコマンドでオプションを減らせます。
  2. 15 個を 最後まで解いてから 正解を開いて一度に採点します。途中で正解を見ると実際の試験感覚が薄れます。

ドメイン分布 #

実際の EX294 のドメイン比重に合わせて 15 のタスクを配置しました。RHCSA 自動化が試験の半分ほどを占めるため、タスク数も最も多いです。

#ドメインタスク数タスク番号
1環境と inventory、接続21, 2
2プレイブックと変数、テンプレート33, 4, 5
3制御フローとエラー処理、Vault36, 7, 8
4role と collection、system roles39, 10, 11
5RHCSA タスク自動化412, 13, 14, 15

配点はドメイン比重とタスクの難易度を反映し、合計 300 点としました。採点基準は記事末にまとめています。


タスク 1 (16 点): 環境と inventory、接続 #

作業ディレクトリ /home/ansible/examansible.cfginventory を書いてください。inventory には managed node node1node4 が必要で、node1node2 はグループ webserversnode3 はグループ dbserversnode4 はグループ balancers に属します。さらに webserversdbservers を子に持つグループ prod を作ります。ansible.cfg はこの inventory をデフォルトで使い、remote_user は ansible、privilege escalation は sudo で自動適用されるように設定します。

正解

/home/ansible/exam/ansible.cfg を書きます。

ansible.cfg
[defaults]
inventory = ./inventory
remote_user = ansible
host_key_checking = False

[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

/home/ansible/exam/inventory を書きます。

inventory
[webservers]
node1
node2

[dbservers]
node3

[balancers]
node4

[prod:children]
webservers
dbservers

構成を検証します。

inventory の検証
ansible-inventory --graph
ansible prod --list-hosts

解説: [prod:children] は他のグループを子としてまとめるグループです。ansible.cfginventory 値を相対パス (./inventory) にすると、作業ディレクトリで実行するときだけ認識されるため、採点時に実行位置を作業ディレクトリに置く点が落とし穴です。become = True[privilege_escalation] セクションに置いて初めて、すべてのプレイで別途の宣言なしに root 権限が適用されます。

タスク 2 (16 点): 環境と inventory、接続 #

webservers グループに変数 package_state: present を、dbservers グループに変数 db_port: 5432 を適用してください。さらに node1 1 台にだけ host 変数 server_role: primary を適用してください。group_vars と host_vars のディレクトリ構造に分けて定義し、ad-hoc コマンドで各変数が正しいホストでのみ見えるかを確認します。

正解

作業ディレクトリの下にディレクトリと変数ファイルを作ります。

ディレクトリ作成
mkdir -p group_vars host_vars

group_vars/webservers.yml を書きます。

group_vars/webservers.yml
package_state: present

group_vars/dbservers.yml を書きます。

group_vars/dbservers.yml
db_port: 5432

host_vars/node1.yml を書きます。

host_vars/node1.yml
server_role: primary

変数が正しいホストでのみ見えるかを ad-hoc で確認します。

変数の確認
ansible node1 -m ansible.builtin.debug -a "var=server_role"
ansible node3 -m ansible.builtin.debug -a "var=db_port"
ansible node2 -m ansible.builtin.debug -a "var=package_state"

解説: group_vars/<グループ名>.ymlhost_vars/<ホスト名>.yml は inventory と同じディレクトリに置くと Ansible が自動的に読み込みます。ファイル名がグループ・ホスト名と正確に一致する必要があり、タイプミスがあると変数が静かに空になりデバッグが難しくなります。host 変数は group 変数より優先順位が高いため、node1 で 2 つの値が重なると host_vars が勝ちます。


タスク 3 (20 点): プレイブックと変数、テンプレート #

webservers グループに httpd をインストール・起動するプレイブック web.yml を書いてください。httpd パッケージをインストールし、サービスを enabled・started 状態にし、/var/www/html/index.html"Welcome to {{ inventory_hostname }}" の内容で生成します。index.html が変わると httpd を再起動する handler を置いてください。プレイブックは 2 回実行しても冪等でなければなりません。

正解

web.yml を書きます。

web.yml
---
- name: Configure web servers
  hosts: webservers
  tasks:
    - name: Install httpd
      ansible.builtin.dnf:
        name: httpd
        state: present

    - name: Ensure httpd is enabled and started
      ansible.builtin.service:
        name: httpd
        state: started
        enabled: true

    - name: Deploy index page
      ansible.builtin.copy:
        content: "Welcome to {{ inventory_hostname }}\n"
        dest: /var/www/html/index.html
      notify: Restart httpd

  handlers:
    - name: Restart httpd
      ansible.builtin.service:
        name: httpd
        state: restarted
実行と冪等性確認
ansible-navigator run -m stdout web.yml
ansible-navigator run -m stdout web.yml   # changed=0

解説: copy モジュールの content は短い本文をインラインで入れるときに使い、同じ内容なら 2 回目の実行で ok が出て冪等です。handler は task が changed のときだけ notify でトリガーされるため、2 回目の実行では index.html が変わらず handler も回りません。handler の名前は notify の値と正確に一致して初めて呼び出されます。

タスク 4 (16 点): プレイブックと変数、テンプレート #

プレイブック facts.yml を書いて、すべての prod ホストでそのホストの総メモリ (MB) と既定の IPv4 アドレスを収集し、メモリが 2048MB 未満のホストに対してのみ警告メッセージを出力してください。出力にはホスト名と実際のメモリ値が含まれている必要があります。

正解

facts.yml を書きます。

facts.yml
---
- name: Report host facts
  hosts: prod
  tasks:
    - name: Show memory and IP
      ansible.builtin.debug:
        msg: "{{ inventory_hostname }} has {{ ansible_facts['memtotal_mb'] }}MB, IP {{ ansible_facts['default_ipv4']['address'] }}"

    - name: Warn on low memory
      ansible.builtin.debug:
        msg: "WARNING: {{ inventory_hostname }} has only {{ ansible_facts['memtotal_mb'] }}MB"
      when: ansible_facts['memtotal_mb'] | int < 2048
実行
ansible-navigator run -m stdout facts.yml

解説: fact はプレイ開始時に gather_facts (デフォルト true) で自動収集され、ansible_facts['memtotal_mb'] のように辞書でアクセスします。数値の比較時に | int フィルターを通すと、文字列・整数の混同を防ぎます。fact 収集を切ったプレイなら、ansible.builtin.setup モジュールで先に集めて初めて変数が埋まります。

タスク 5 (20 点): プレイブックと変数、テンプレート #

Jinja2 テンプレート motd.j2 とプレイブック motd.yml を書いてください。すべての prod ホストの /etc/motd に、ホスト名・OS のディストリビューションとバージョン・CPU 数を含む案内文を配布します。テンプレートは fact を参照し、内容が変わるとファイルが更新されなければなりません。

正解

motd.j2 を書きます。

motd.j2
Welcome to {{ ansible_facts['hostname'] }}
OS: {{ ansible_facts['distribution'] }} {{ ansible_facts['distribution_version'] }}
CPUs: {{ ansible_facts['processor_vcpus'] }}
Managed by Ansible. Do not edit manually.

motd.yml を書きます。

motd.yml
---
- name: Deploy MOTD from template
  hosts: prod
  tasks:
    - name: Template /etc/motd
      ansible.builtin.template:
        src: motd.j2
        dest: /etc/motd
        owner: root
        group: root
        mode: '0644'
実行と冪等性確認
ansible-navigator run -m stdout motd.yml
ansible-navigator run -m stdout motd.yml   # changed=0

解説: template モジュールは control node の .j2 ファイルをレンダリングして managed node に配布し、copy と違って変数と制御フローを処理します。レンダリング結果が同じなら 2 回目の実行で変更がなく冪等です。mode は引用符で文字列 ('0644') にして 8 進数の解釈エラーを避けます。


タスク 6 (20 点): 制御フローとエラー処理、Vault #

プレイブック users_loop.yml を書いて、変数リスト app_users に定義したユーザー 3 名 (alicebobcarol) を loop で一度に作成してください。各ユーザーは補助グループ developers に属し、シェルは /bin/bash です。developers グループはユーザー作成の前に作る必要があります。

正解

users_loop.yml を書きます。

users_loop.yml
---
- name: Create users with loop
  hosts: webservers
  vars:
    app_users:
      - alice
      - bob
      - carol
  tasks:
    - name: Ensure developers group exists
      ansible.builtin.group:
        name: developers
        state: present

    - name: Create application users
      ansible.builtin.user:
        name: "{{ item }}"
        groups: developers
        append: true
        shell: /bin/bash
        state: present
      loop: "{{ app_users }}"
実行と冪等性確認
ansible-navigator run -m stdout users_loop.yml
ansible-navigator run -m stdout users_loop.yml   # changed=0

解説: loop はリストを巡回して item 変数で各値を受け取ります。append: true がないと groups がユーザーの補助グループを丸ごと上書きし、既存のグループが外れる落とし穴があります。グループ作成 task をユーザー作成の前に置いて、補助グループがなくて失敗することを防ぎます。

タスク 7 (20 点): 制御フローとエラー処理、Vault #

プレイブック safe_deploy.yml を書いてください。block でパッケージ mariadb-server をインストールして mariadb サービスを起動しますが、インストール中に失敗したら rescue/var/log/deploy-failed.log に失敗の事実を記録し、always では結果に関係なくディスク使用量を出力します。さらに、サービス状態を確認する command task が出力文字列に active があるときだけ changed と報告されないように changed_when を false にしてください。

正解

safe_deploy.yml を書きます。

safe_deploy.yml
---
- name: Safe deploy with block/rescue/always
  hosts: dbservers
  tasks:
    - name: Deploy database
      block:
        - name: Install mariadb-server
          ansible.builtin.dnf:
            name: mariadb-server
            state: present

        - name: Start mariadb
          ansible.builtin.service:
            name: mariadb
            state: started
            enabled: true

        - name: Check service status
          ansible.builtin.command: systemctl is-active mariadb
          register: svc_status
          changed_when: false
      rescue:
        - name: Record failure
          ansible.builtin.copy:
            content: "mariadb deploy failed on {{ inventory_hostname }}\n"
            dest: /var/log/deploy-failed.log
      always:
        - name: Report disk usage
          ansible.builtin.command: df -h /
          register: disk
          changed_when: false

        - name: Show disk usage
          ansible.builtin.debug:
            var: disk.stdout_lines
実行
ansible-navigator run -m stdout safe_deploy.yml

解説: block の task が失敗すると rescue に移り、always は成功・失敗に関係なく常に実行されます。commandshell は常に changed と報告されるため、状態確認のようにシステムを変えない照会には changed_when: false を付けて冪等性を守ります。rescue が処理するとプレイは失敗で終わらないため、部分的な復旧が可能です。

タスク 8 (20 点): 制御フローとエラー処理、Vault #

Vault で暗号化した変数ファイル secret.yml を作り (変数 db_root_password: S3cret!)、プレイブック vault_use.yml でこの変数を読んで /root/db_credentials.txtmode 0600 で記録してください。実行時に vault パスワードをファイル vault_pass.txt で提供すると仮定します。

正解

暗号化変数ファイルを作ります。

Vault ファイル作成
echo 'changeme' > vault_pass.txt
ansible-vault create --vault-password-file vault_pass.txt secret.yml

エディタが開いたら次を入力して保存します。

secret.yml
db_root_password: "S3cret!"

vault_use.yml を書きます。

vault_use.yml
---
- name: Use a vaulted variable
  hosts: dbservers
  vars_files:
    - secret.yml
  tasks:
    - name: Write credentials file
      ansible.builtin.copy:
        content: "root_password={{ db_root_password }}\n"
        dest: /root/db_credentials.txt
        owner: root
        group: root
        mode: '0600'

vault パスワードファイルとともに実行します。

実行
ansible-navigator run -m stdout vault_use.yml --vault-password-file vault_pass.txt

解説: ansible-vault create は新しい暗号化ファイルを、ansible-vault edit は既存のファイルを編集します。暗号化変数を使うプレイブックは、実行時に --vault-password-file--ask-vault-pass を外すと復号失敗で止まります。資格情報ファイルを mode 0600 にして他のユーザーが読めないようにする点が採点項目です。


タスク 9 (20 点): role と collection、system roles #

role apacheroles/apache の下に直接書いてください。この role は httpd のインストール、サービスの起動、そして変数 apache_port (デフォルト 80) を受け取って /etc/httpd/conf.d/listen.confListen {{ apache_port }} をテンプレートで配布します。ポートが変わると httpd を再起動する handler を role の中に置いてください。プレイブック use_role.ymlwebserversapache_port: 8080 でこの role を適用します。

正解

role の骨組みを作ります。

role の雛形作成
ansible-galaxy init roles/apache

roles/apache/defaults/main.yml を書きます。

roles/apache/defaults/main.yml
apache_port: 80

roles/apache/tasks/main.yml を書きます。

roles/apache/tasks/main.yml
---
- name: Install httpd
  ansible.builtin.dnf:
    name: httpd
    state: present

- name: Configure listen port
  ansible.builtin.template:
    src: listen.conf.j2
    dest: /etc/httpd/conf.d/listen.conf
  notify: Restart httpd

- name: Ensure httpd is running
  ansible.builtin.service:
    name: httpd
    state: started
    enabled: true

roles/apache/templates/listen.conf.j2 を書きます。

roles/apache/templates/listen.conf.j2
Listen {{ apache_port }}

roles/apache/handlers/main.yml を書きます。

roles/apache/handlers/main.yml
---
- name: Restart httpd
  ansible.builtin.service:
    name: httpd
    state: restarted

use_role.yml を書きます。

use_role.yml
---
- name: Apply apache role
  hosts: webservers
  roles:
    - role: apache
      apache_port: 8080
実行と冪等性確認
ansible-navigator run -m stdout use_role.yml
ansible-navigator run -m stdout use_role.yml   # changed=0

解説: ansible-galaxy init で作った role は taskshandlerstemplatesdefaults ディレクトリを標準構造として持ちます。defaults/main.yml の変数は優先順位が最も低いため、プレイブックから渡した apache_port: 8080 が勝ちます。role の中の template モジュールは roles/apache/templates をデフォルトパスとして見るため、src にパスを書かなくてかまいません。

タスク 10 (20 点): role と collection、system roles #

collection を requirements ファイルでインストールしてください。collections/requirements.ymlcommunity.generalansible.posix を明示し、これを作業ディレクトリの下の collections パスにインストールします。インストール後に ansible.posix.firewalld モジュールが使えるかを確認します。

正解

collections/requirements.yml を書きます。

collections/requirements.yml
---
collections:
  - name: community.general
  - name: ansible.posix

作業ディレクトリの下の collections にインストールします。

collection のインストール
ansible-galaxy collection install -r collections/requirements.yml -p ./collections

インストールされた collection とモジュールを確認します。

インストールの確認
ansible-galaxy collection list
ansible-doc ansible.posix.firewalld

解説: ansible-galaxy collection install -r は requirements ファイルに並んだ collection を一度にインストールし、-p でインストールパスを指定します。ansible.cfgcollections_path か作業ディレクトリの下の collections に置くと、プレイブックが自動的に認識します。試験では自動化コンテンツがローカルミラーで提供されることがあるため、server オプションやオフラインパスを確認する点が落とし穴です。

タスク 11 (20 点): role と collection、system roles #

rhel-system-roles の timesync role を使って、すべての prod ホストの NTP を構成してください。NTP サーバーは time.example.com 1 か所を使います。プレイブック timesync.ymlredhat.rhel_system_roles.timesync role を呼び出し、変数 timesync_ntp_servers でサーバーを指定します。

正解

system roles パッケージが入っているかを確認します。

system roles パッケージ確認
sudo dnf install -y rhel-system-roles
ansible-galaxy collection list | grep rhel_system_roles

timesync.yml を書きます。

timesync.yml
---
- name: Configure NTP with timesync system role
  hosts: prod
  vars:
    timesync_ntp_servers:
      - hostname: time.example.com
        iburst: true
  roles:
    - redhat.rhel_system_roles.timesync
実行と冪等性確認
ansible-navigator run -m stdout timesync.yml
ansible-navigator run -m stdout timesync.yml   # changed=0

解説: rhel-system-roles は rhel-system-roles パッケージで control node にインストールされ、redhat.rhel_system_roles collection として公開されます。timesync_ntp_servers は単純な文字列ではなく hostnameiburst キーを持つ辞書のリストである点が落とし穴です。system role は内部で chrony 設定を冪等に管理するため、2 回目の実行で changed が 0 に落ちます。


タスク 12 (24 点): RHCSA タスク自動化 #

プレイブック accounts.yml を書いて、変数ファイルに定義したユーザー一覧をすべての prod ホストに作成してください。各ユーザーは名前・UID・パスワード (すでにハッシュ化された値) を持ち、loop で処理します。パスワードハッシュはタスク 8 と同じ方式の Vault 変数から取ると仮定し、ここでは変数 srv_users リストを直接定義して使ってください。

正解

accounts.yml を書きます。

accounts.yml
---
- name: Provision accounts
  hosts: prod
  vars:
    srv_users:
      - name: deploy
        uid: 2001
        password: "$6$rounds=656000$abcXYZ$hashedvalue1"
      - name: backup
        uid: 2002
        password: "$6$rounds=656000$abcXYZ$hashedvalue2"
  tasks:
    - name: Create service accounts
      ansible.builtin.user:
        name: "{{ item.name }}"
        uid: "{{ item.uid }}"
        password: "{{ item.password }}"
        state: present
      loop: "{{ srv_users }}"
      loop_control:
        label: "{{ item.name }}"
実行と冪等性確認
ansible-navigator run -m stdout accounts.yml
ansible-navigator run -m stdout accounts.yml   # changed=0

解説: user モジュールの password は平文ではなく SHA-512 ハッシュでなければならず、ansible-vault で包んだ変数か password_hash フィルターで生成します。平文を入れるとその文字列自体がハッシュとして保存され、ログインができません。loop_control.label は出力でハッシュのような長い値の代わりにユーザー名だけを見せて可読性を高めます。

タスク 13 (24 点): RHCSA タスク自動化 #

プレイブック storage.yml を書いて、dbservers ホストの空のディスク /dev/vdb にボリュームグループ vg_data を作り、その中に 2G の論理ボリューム lv_data を作成した後、xfs でフォーマットして /data に永続マウントしてください。タスクは冪等でなければなりません。

正解

storage.yml を書きます。

storage.yml
---
- name: Configure LVM storage
  hosts: dbservers
  tasks:
    - name: Create volume group
      community.general.lvg:
        vg: vg_data
        pvs: /dev/vdb

    - name: Create logical volume
      community.general.lvol:
        vg: vg_data
        lv: lv_data
        size: 2G

    - name: Create xfs filesystem
      community.general.filesystem:
        fstype: xfs
        dev: /dev/vg_data/lv_data

    - name: Mount the filesystem
      ansible.posix.mount:
        path: /data
        src: /dev/vg_data/lv_data
        fstype: xfs
        state: mounted
実行と冪等性確認
ansible-navigator run -m stdout storage.yml
ansible-navigator run -m stdout storage.yml   # changed=0

解説: LVM 自動化は community.generallvglvolfilesystemansible.posix.mount を順に繋ぎます。mount モジュールの state: mounted は今マウントしながら /etc/fstab にも登録して永続マウントを作ります (mountedpresent の違いが落とし穴です)。タスク 10 で 2 つの collection を先にインストールしておいた点がここで活きます。

タスク 14 (24 点): RHCSA タスク自動化 #

プレイブック firewall_selinux.yml を書いて、webservers ホストで httpd が非標準ポート 8080 を使えるように許可してください。firewalld に 8080/tcp を永続許可して即時反映し、SELinux で http_port_t に 8080 ポートを追加します。ansible.posix.firewalldcommunity.general.seport を使います。

正解

firewall_selinux.yml を書きます。

firewall_selinux.yml
---
- name: Open port 8080 for httpd
  hosts: webservers
  tasks:
    - name: Allow 8080/tcp in firewalld
      ansible.posix.firewalld:
        port: 8080/tcp
        permanent: true
        immediate: true
        state: enabled

    - name: Add SELinux port label for http
      community.general.seport:
        ports: 8080
        proto: tcp
        setype: http_port_t
        state: present
実行と冪等性確認
ansible-navigator run -m stdout firewall_selinux.yml
ansible-navigator run -m stdout firewall_selinux.yml   # changed=0

解説: firewalld の変更は permanent: true だけだと次の reload まで適用されないため、immediate: true を併せて置いて今すぐ開く必要があります。SELinux は非標準ポートでサービスを立ち上げるとき、http_port_t のようなポートタイプを追加しないとサービスがバインドに失敗するため、seport でポートラベルを先に登録します。2 つのモジュールはどちらも冪等で、2 回目の実行は ok に落ちます。

タスク 15 (20 点): RHCSA タスク自動化 #

プレイブック cron.yml を書いて、すべての prod ホストの root crontab に毎日 02:30 に /usr/local/bin/backup.sh を実行する cron job (名前 daily-backup) を登録してください。job は冪等に管理されなければなりません。

正解

cron.yml を書きます。

cron.yml
---
- name: Schedule daily backup
  hosts: prod
  tasks:
    - name: Add daily backup cron job
      ansible.builtin.cron:
        name: daily-backup
        minute: "30"
        hour: "2"
        job: /usr/local/bin/backup.sh
        user: root
        state: present
実行と冪等性確認
ansible-navigator run -m stdout cron.yml
ansible-navigator run -m stdout cron.yml   # changed=0

解説: cron モジュールの name は crontab にコメントとして記録され、job を識別するキーになるため、同じ name で再び回すと重複なく更新だけされます。name を外すと毎回の実行で同じ行が積み上がり冪等性が壊れるのが最もよくある落とし穴です。minutehour は文字列にしておくほうが安全です。


採点基準 #

各タスクの配点を合算して採点します。合計は 300 点で、210 点以上が合格圏 です。

ドメインタスク・配点小計
環境と inventory、接続1(16) · 2(16)32
プレイブックと変数、テンプレート3(20) · 4(16) · 5(20)56
制御フローとエラー処理、Vault6(20) · 7(20) · 8(20)60
role と collection、system roles9(20) · 10(20) · 11(20)60
RHCSA タスク自動化12(24) · 13(24) · 14(24) · 15(20)92
合計(合計)300

採点は実際の試験と同じく 成果物基準 です。プレイブックをどう書いたかではなく、managed node に実際に作られた状態が要件と一致するかを見ます。特に採点スクリプトはプレイブックを もう一度実行 して冪等性を確認するため、2 回目の実行で changed が残るタスクは減点されます。1 つのタスクの中でもパッケージ・サービス・ファイル・ポートのような項目別に部分点が分かれるため、詰まる項目があっても埋められる部分は最後まで埋めるほうが点数に有利です。

ドメイン別の弱点復習 #

採点後、点数が低いドメインを下表の該当記事に戻って復習してください。

ドメイン関連タスク復習する記事
環境と inventory、接続1, 2#2 · #3 · #4
プレイブックと変数、テンプレート3, 4, 5#5 · #6 · #7
制御フローとエラー処理、Vault6, 7, 8#8 · #9 · #10
role と collection、system roles9, 10, 11#11 · #12 · #13
RHCSA タスク自動化12, 13, 14, 15#14 · #15 · #16 · #17

特定のタスクで時間が足りなかったなら、ドメイン知識より手の速さの問題かもしれません。その場合は #1 セットアップ#18 時間管理 を読み直し、同じ 15 のタスクを時間を計ってもう一度解いてください。LVM 自動化と system roles は一度手に馴染むと、タスクあたりの所要時間が目に見えて減ります。

シリーズを終えて #

#1 の試験の紹介から出発し、inventory・接続・ad-hoc・プレイブック・変数・fact・テンプレート・エラー処理・条件分岐・Vault・role・collection・system roles、そして RHCSA 自動化 4 種まで、RHCE の全ドメインを 19 編で通過しました。この模擬試験で 210 点を越えたなら、実際の試験会場でも十分に合格ラインを越えられる手ができています。おめでとうございます。

RHCSA シリーズ で 1 台のシステムを手で扱う方法を身につけ、この RHCE シリーズで複数台を Ansible で自動化する力まで加えて、RHEL 資格トラックを完走されました。RHCSA の手作業と RHCE の冪等な自動化が一体に繋がった今、システム 1 台を扱う管理者を越えて、複数台をコードで扱う自動化エンジニアの道に上がったことをお祝いします。

X