LPIC を取ってから AWS CLF-C02 の勉強を始めたら、Ch.3 までで 3 回助けられた話

2026 年 4 月に LPIC-1 を取った。その翌月から AWS の Cloud Practitioner（CLF-C02）の勉強を始めた。教科書を Ch.3 まで読んだ段階で、「あれ、これ 1 ヶ月前にやったやつだ」が 3 回起きた。ifconfig、dig、DNS 設定ファイル。Ch.3 は CLF-C02 全体の約 3 分の 1（Domain 3 = 34%）に相当する範囲で、その密度で 3 回引っかかった。受験は 6/29、これは合格記ではなく、Ch.3 までの受験前リアルタイム学習記である。

教科書は『AWS クラウドインフラとネットワーク入門 第 2 版』を使っている。CLF-C02 の出題範囲を Domain ごとにカバーしている定番書で、最寄りの図書館で借りた。受験までに複数冊を読み比べる予定なので、まずは購入コストを抑えたかった。

LPIC-1 を取った 4 月時点では「次は CCNA か AWS か」で迷っていた。最終的に CLF-C02 を選んだのは、AWS の方がキャリアで活用できる場面が幅広く、キャリア形成の選択肢を広げやすいと判断したからだ。Ch.3 を読み終えた段階で、CLF-C02 を選んだのは正解だったかもしれない、と 3 回思った。

なぜ LPIC を先に取ってから AWS に行ったか

正直、最初から「LPIC → AWS が王道」と言われていたから順番を守ったわけではない。今の SES 案件に入って 3 ヶ月、現場で Linux のコマンドは毎日叩いているが、CCNA も持っていなければ Linux 系の資格も持っていなかった。「現場で触っている」と「資格として体系で押さえている」は別の話で、後者をやらないと一段抜けないと感じていた。だから LPIC-1 が先で、AWS は後にした。

仕事で AWS を触る機会も増えてきていて、CLF-C02 はその「先回りの地ならし」だった。クラウドの語彙を一回ちゃんと並べておきたい、というのが受験を決めた理由で、合格自体がゴールではない。

ここで先に断っておくと、本記事は「LPIC を取れば AWS が誰でも簡単になる」という一般化はしない。私の場合、Ch.3 の時点で 3 回引っかかった、というだけの個人体験記である。順序を入れ替えた他人がどうなるかは私には分からない。

CLF-C02 の試験範囲は AWS 公式によると 4 ドメインに分かれていて、

ドメイン 1: クラウドのコンセプト（24%）
ドメイン 2: セキュリティとコンプライアンス（30%）
ドメイン 3: クラウドテクノロジーとサービス（34%）
ドメイン 4: 請求、料金、およびサポート（12%）

（出典: AWS Certified Cloud Practitioner 試験ガイド）

私が今回読んでいる教科書の Ch.3 は、EC2 や VPC、ネットワーク周りを扱う章で、ちょうど Domain 3（34%） にあたる。つまり Ch.3 だけで試験全体の約 3 分の 1 を占める範囲で、ここで 3 回引っかかったというのは、密度として無視できない比率だと思う。

1 回目: EC2 の IP アドレスの話で ifconfig を思い出した

最初に「あ、これやった」と思ったのは、EC2 インスタンスに割り当てられる IP アドレスの説明だった。教科書は ENI（Elastic Network Interface）にプライマリプライベート IP が割り当てられて、必要ならセカンダリプライベート IP も付けられる、という話を淡々と進めていく。

ここで、LPIC 102 試験の Topic 109.2 を勉強していたときの感覚が戻ってきた。LPIC では、Linux のネットワークインターフェースに対して IP アドレスを確認・設定する操作として、ifconfig（旧来コマンド）と ip addr show（現行コマンド）を扱う。

# LPIC 102 で叩いたコマンド（インターフェースに割り当てられた IP を確認）
ip addr show
# 旧来コマンド（試験範囲にはどちらも含まれる）
ifconfig

EC2 で言う「インスタンスに ENI が紐づいていて、ENI に IP が割り当てられている」は、Linux で言う「ホストに NIC が刺さっていて、NIC に IP が割り当てられている」と構造的にほぼ同じ話で、抽象化の階層が物理 NIC から仮想インターフェースに上がっているだけだった。「ENI = AWS が抽象化した仮想 NIC」と言われた瞬間、頭の中で ip addr show の出力イメージに被さって、何の説明も追加で要らなかった。

私自身は今の SES 案件に入って 3 ヶ月、現場で叩いた ifconfig の回数はそれほど多くない。それでも強く感じているのは、現場では「どこを見るか」だけを教わって、その出力がなぜそのフォーマットなのか、なぜそのコマンドがそうなっているのかは説明されない、ということだ。ifconfig も ip addr も、現場では「IP とサブネットマスクの行を見て、状態を判断する」で終わる。LPIC を取って初めて、その出力 1 行 1 行が何の情報を表しているかを体系で押さえた感覚があった。同じコマンドが、使う場面と学ぶ場面で違う深さで入ってくる。

2 回目: Route 53 の説明で dig の手触りが効いた

2 回目は、Ch.3 の中盤で Route 53 が出てきた場面。教科書では「Amazon が提供する DNS サービス」「ホストゾーン」「A / CNAME / MX などのレコードタイプ」と進んでいく。

LPIC 102 の Topic 109.4 では、dig コマンドを使って実際に DNS レコードを引きにいく演習をやる。

# LPIC 102 で叩いたコマンド（DNS レコードを問い合わせる）
dig example.com A
dig example.com MX
dig example.com NS

dig の出力を見ると、ANSWER SECTION にレコードの中身が並んで、TTL が秒で出て、レコードタイプが A / MX / CNAME などで分類されている。この「TTL × レコードタイプ × ANSWER」のフォーマットを一度でも目で追ったことがあると、Route 53 の説明で「ホストゾーンに A レコードを登録します」と書かれていても、頭の中に dig の出力が浮かぶ。Route 53 という名前のサービスが何をやっているのかが、サービス名から抽象的に説明される前に、コマンドの手触りから先に分かる感じがあった。

加えて、Ch.3 には VPC の予約 IP アドレス 5 個の話が出てくる。

サブネットの先頭 2 番目（先頭+2）の IP は、Amazon が提供する DNS サーバーへのマッピング用に予約されている。

これも、LPIC で /etc/resolv.conf の nameserver 行を見たことがあれば、「あ、VPC 内のインスタンスが resolv.conf 経由で参照する DNS サーバーが、先頭+2 にいるんだな」とすぐ繋がる。「予約されている」だけだと丸暗記の対象になるが、resolv.conf の nameserver 行と紐づけば「そりゃ予約しないと困るな」と理由から覚えられる。

3 回目: 「OS 側の設定ファイルに IP を固定化してはいけない」の意味

3 回目が、Ch.3 で一番強く引っかかった場面である。

教科書のこの一節:

EC2 インスタンスにインストールする OS の「IP アドレスの取得方法」に関する設定は、たとえ手動の IP アドレスを利用する場合でも、DHCP を利用するように構成します。OS 側の設定ファイルに、利用する IP アドレスを記述して、固定化してはいけません。

（『AWS クラウドインフラとネットワーク入門 第 2 版』Ch.3 より引用）

これを初見で読むと、「なぜ？」と思う部分が二段ある。

• なぜ DHCP に強制されるのか
• なぜ OS 側で固定化してはいけないのか

LPIC を経由していない人にとっては「AWS のお作法として覚える」項目になりやすいが、LPIC 102 の Topic 109.4 で /etc/resolv.conf と /etc/hosts の役割を一度真面目に押さえていると、この一節の意味が体に届く。/etc/resolv.conf は「自分が参照する DNS サーバー」を OS 側の設定ファイルに書き込むファイルで、/etc/hosts は「名前解決を OS ローカルで固定化する」ファイルである。LPIC では、これらのファイルに何を書いたら何が起きるか、を試験範囲として扱っている。

# /etc/resolv.conf の例（LPIC 102 / Topic 109.4 の出題範囲）
nameserver 10.0.0.2
search example.local

つまり LPIC を通った人は、「OS 側の設定ファイルに書く＝そのホスト固有の状態を OS の内側に持つ」という構図を一度経験している。これが分かっていれば、AWS の Ch.3 の「OS 側に IP を固定化してはいけない」は、ほぼ直感的に通る。

• EC2 はインスタンスが停止 → 起動で別のホストに乗り換わる可能性がある（プライベート IP は維持されることが多いが、ネットワーク構成は AWS 側が管理している）
• OS の中に IP を書き込むと、AWS 側がネットワークを管理しているという前提と矛盾する
• だから DHCP 経由で AWS から受け取れ、と言っている

LPIC を通っていないと「ふーん、AWS はそうなんだ」で終わる。LPIC を通っていると、「設定ファイルで管理する世界」と「DHCP で管理してもらう世界」の境界線がすでに頭の中にあるので、Ch.3 のこの一節を読んだ瞬間に「OS の設定ファイル管理という旧来の方法を、AWS は明示的に禁止しているんだな」と意味が立体的に入る。

知っている人には当然の理由、知らない人には謎の制約。この落差が、Ch.3 までで一番強く感じたところだった。

LPIC では /etc/sysconfig/network-scripts/ifcfg-eth0 の BOOTPROTO を static にして IP を直書きする演習がある。Linux のネットワーク設定として完全に正しい手順で、試験範囲にも入っている。それが AWS では明確に「触ってはいけない」と書かれている。同じファイルパス、同じ書式、それでも運用前提が真逆になる。読んだ瞬間、少し戸惑った。LPIC で覚えた手順そのものが、AWS では否定されている。

「OS で固定化してはいけません」という一文の背後には、「IP の割り当ては VPC のスコープで一元管理する」という設計思想がある。設定ファイルで個別管理する世界から、サブネット単位の DHCP で集合管理する世界への引っ越しで、LPIC で覚えた手順を一度「やってはいけないこと」として持ち直す必要がある。クラウドの設計思想が、ファイル 1 つのルールから漏れてくるのを感じた瞬間だった。

Ch.3 までの時点で言えること（と、まだ言えないこと）

ここまでが、CLF-C02 教科書 Ch.3 までを読んだ時点で、LPIC-1 102 試験の知識に 3 回助けられた具体的な場面だ。

整理すると、

回数	LPIC 側の出所	AWS 側の出会い	落差の種類
1 回目	LPIC 102 Topic 109.2 / ifconfig・ip addr	EC2 / ENI / プライベート IP	抽象化レイヤの読み替え（物理 NIC → 仮想 ENI）
2 回目	LPIC 102 Topic 109.4 / dig	Route 53 / DNS レコード / VPC 予約 IP	「サービス名」より「コマンドの手触り」が先に効く
3 回目	LPIC 102 Topic 109.4 / /etc/resolv.conf・/etc/hosts	EC2 / DHCP 強制 / 「OS 側で固定化禁止」	旧来の方法と AWS の方法の境界線が立体的に分かる

ただし、ここで言えるのは「私の場合、Ch.3 までではこうだった」というところまでで、それ以上に踏み込むのは正直怖い。

言えること:

• Ch.3（教科書の 1 章分・Domain 3 = 34% に該当）の範囲では、LPIC 102 のネットワーク章の知識が、抽象から具象まで複数の解像度で効いた
• 「サービス名を覚える」より「コマンドの手触りで覚える」方が、CLF-C02 の説明文を素直に読める瞬間がある

まだ言えないこと:

• Ch.4 以降（セキュリティ・請求・サポート）で LPIC の知識がどこまで効くかは、まだ読み終わっていないので分からない
• LPIC の中でも、シェルスクリプト・システム管理（cron、systemd、ログ）の章が AWS のどこに効くのかは、現時点では明示的な接続が見つかっていない
• 6/29 が受験本番なので、合格できるかも分からない。本記事は合格記ではない。合否は別途報告予定

次に確認したいのは、

• Ch.4「セキュリティとコンプライアンス」で、LPIC で扱った権限管理（chmod / chown）や PAM の知識が、IAM の説明にどれだけ効くか
• VPC のセキュリティグループ / ネットワーク ACL の説明で、iptables / firewalld の経験がどれだけ効くか

このあたりは Ch.4 を読み終わったら追記するか、別記事にしたい。

Ch.4 で EIP（Elastic IP）の存在理由を読んだら、Ch.3 で見た「停止→開始でパブリック IP が変わる」挙動が腑に落ちるはずだと予想している。仮説が当たっていれば、続編で書く。外れていたら、外れていた理由を書く。受験本番（6/29）までに教科書を Ch.10 まで通したとき、「LPIC が効いた回数」を改めて数え直したい。

---

この LPIC → AWS の順序や、資格を「取って終わり」ではなく「次の資格への助走」として捉える話は、もう少し背景込みで note の方に書く予定です。
→ fumi_ai_202507 の note

毎朝の情報収集を、キーワード登録だけで AI に拾ってもらえないか、と思って自分のために作っているのが DAINews です。開発の進捗は X でよく呟いています。
→ @DAINews_JP