1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@lab8010(Yamato Sakai)

【2026年9月】RHCA保有者のKubestronaut挑戦記(2) CKS編 〜40点→87点、3回目で気づいた「凡ミス」という敵〜

1
Last updated at Posted at 2026-09-24

【2026年9月】RHCA保有者のKubestronaut挑戦記(2) CKS編 〜40点→87点、3回目で気づいた「凡ミス」という敵〜

皆さんこんにちは、Red Hat Global Learning ServicesでLearning Solution Architectを担当している坂井 大和(@lab8010)です。

本記事は「RHCA保有者のKubestronaut挑戦記」シリーズの第2弾であり、完結編です。

第1弾では、バウチャーを11ヶ月放置してしまったところからCKA・CKADに合格するまでをお話ししました。本記事では、Kubestronaut挑戦の最終関門となった CKS(Certified Kubernetes Security Specialist) の顛末を扱います。

結論から申し上げると、CKSは3回受験してようやく合格しました。そして40点から87点へと点数が変わった理由は、私が当初思っていたものとはまったく違いました。

CKS試験も受験にあたり守秘義務契約(Candidate Agreement)への同意が必要です。そのため、この記事では実際の出題内容には一切触れず、あくまでも公式に公開されている情報と、私自身の準備プロセスや心構えについてのみ扱います。

この記事でカバーすること・しないこと

  • カバーすること
    • 本番でやりがちな「凡ミス」の具体例と、その対策
    • 3回の受験記録と、それぞれの敗因の振り返り
    • 試験環境のトラブルに遭遇したときに私が取った対応
    • 私が使った練習環境と、その使い方の所感
  • カバーしないこと
    • 本番で出題された具体的な問題
    • Linux Foundation/CNCFが公式に公開していない情報
    • 出題範囲の網羅的な技術解説 —— 既に優れた解説記事が多数あります
    • CKA・CKADの受験記 —— こちらは第1弾で扱っています

1. 結論：40点と87点を分けたのは、知識量ではなかった

まず、CKSの受験記録です。合格ラインは67点でした。

日付 試験 結果 スコア
2026/8/25 CKS(1回目) 不合格 40点
2026/9/4 CKS(2回目) 不合格 55点
2026/9/17 CKS(3回目) 合格 87点

KCNAからCKSまでのKubestronaut挑戦の全記録は、第1弾に一覧表として掲載しています。

まず、CKSという試験の本体はどこにあるか

本題に入る前に、大前提を確認させてください。

CKSは、Kubernetes環境をより安全にするための試験です。CKA・CKADのような「Kubernetesというプラットフォームそのものを扱えるか」を問う試験とは、性質が異なります。問われるのは、Kubernetesを取り巻く主要なセキュリティ機能群を理解し、適切に使えるかです。

ホストOSのカーネルセキュリティ機構、コンテナイメージとサプライチェーン、ランタイムの振る舞い検知、監査ログ —— Kubernetesの上下左右に広がるこれらの領域が出題範囲に含まれます。私も1回目の受験直後、率直にこう感じました。

これはKubernetesの試験というよりは、Linuxやセキュリティを含めた幅広い知識が問われる試験である

CKSが「CKA・CKADと比べて最難関」と言われる理由は、まさにここにあります。Kubernetesには精通しているが、Linuxやセキュリティの実務経験は少ないという方にとっては、新しい領域そのものの理解から始める必要があるためです。

この点については既に詳しい解説記事が多数ありますので、本記事では深追いしません。ただ、CKSの中心にあるのはあくまでセキュリティ機能群の理解であり、そこが最大の学習コストであることは、最初に強調しておきます。

さらに、CKA・CKAD相当の操作スキルは「前提」です

そのうえで、CKSではKubernetesのマニフェストを過不足なく正しく書けることが最低限必須のスキルです。セキュリティ設定の多くは、最終的にマニフェストのどこかにフィールドを足す・直すという形で実現されます。そこで手が止まっているようでは、本題であるセキュリティの設問にたどり着けません。

つまりCKSは、CKA・CKAD相当の操作スキルを土台として持ったうえで、その上にセキュリティの理解を積む試験です。実際、CKSの受験にはCKAの合格が必須要件として定められています。

参考：Certified Kubernetes Security Specialist (CKS) | Linux Foundation公式

そのうえで —— 積み上げた理解を、凡ミスが台無しにする

ここからが本記事の主題です。

40点 → 55点 → 87点という推移だけを見ると、3回目で何か特別な知識を身につけたように見えるかもしれません。しかし、実際に変わったのはそこではありませんでした。

3回目で変わったのは、身につけた理解を、凡ミスなく本番で出し切れるかどうかでした

CKSは2時間で15〜20問を処理する試験です。第1弾でも「CKA・CKADの2時間は、未知を調べる時間ではなくミスをリカバリーする時間だ」と書きましたが、CKSはその2時間がさらに忙しい試験でした。

この密度の中では、セキュリティ機能を正しく理解していても、ほんの些細な操作ミスひとつでその設問の点数がまるごと消えます。そして厄介なことに、実技試験の凡ミスにはその場では気づけない種類のものがあります。

念のため申し添えると、「凡ミスさえ防げば合格できる試験」ではありません。
セキュリティ機能群への理解があることは大前提です。本記事がお伝えしたいのは、せっかく積み上げたその理解が、初歩的なミスひとつで致命傷になりうるという点です。学習の総仕上げとして読んでいただければと思います。

2. 点を落とす「凡ミス」の正体

ここからが本題です。私が1回目・2回目でおそらくやってしまったであろう凡ミスを共有します。

以下は出題内容ではなく、**実技試験全般で起こり得る「操作上のミスの類型」**です。私自身、採点の内訳を見られるわけではないため、あくまで「落とした点数の内訳として、これが原因だったはずだ」という振り返りである点をご承知おきください。

Kubernetes操作でのミス

まず、私が最も強調したいのはこの一点です。

kubectl apply が成功することと、設問に正しく答えられていることは、まったく別である

以下に挙げるミスに共通する厄介な性質は、リソースを展開した際に、リソース自体は正常に作成されてしまうことです。コマンドは成功し、画面には created と表示されます。つまり、自分で設定後の動作確認までしないと、正しく回答できたかどうかがわからないのです。

  • namespaceの指定忘れ —— 指定されたnamespaceではなく default にリソースをデプロイしてしまう
  • サイドカーコンテナの見落とし —— Pod内に複数のコンテナがあることに気づかず、メインコンテナにだけ設定を施して安心してしまう
  • annotationの記載漏れ —— 必要なannotationが抜けたままリソースを展開してしまう

どれも、言われてみれば当たり前のことばかりです。しかし2時間という時間に追われ、「よし、次の問題へ」と気持ちが前のめりになっているときほど起こります。

対策：確認までを1問とする

対策はシンプルで、設定した内容を自分の目で確認するまでを1問とすることです。そのために、確認のための手札を事前に用意しておくことをおすすめします。

  • kubectl get <resource> -A で、意図しないnamespaceに作られていないかを確認する
  • kubectl get <resource> <name> -n <ns> -o yaml で、実際に反映された内容を読む
  • Pod内のコンテナ構成を kubectl get pod <name> -o jsonpath='{.spec.containers[*].name}' などで把握する
  • 設定が「効いている」ことを、実際の挙動(通信可否やログ)で確かめる

この確認作業は時間を消費します。しかし、確認せずに次へ進んだ結果、その問題の点数がまるごと失われることと比べれば、遥かに安い投資です。

Linux OS操作でのミス

CKSはKubernetesだけで完結しません。ホストOS側の操作も必要になります。私がやってしまったであろうミスは次の2つです。

  • 単純な sudo 漏れ による、いくつかのコマンド実行の失敗
  • 特定のサービスやソフトウェアの設定ファイルの保存パスに不慣れだったこと

前者について、なぜこんな初歩的なミスをしたのかという原因もはっきりしています。

試験対策に使っていた練習環境が、常にrootで実行される環境だったためです。練習の中で sudo を打つ習慣そのものが欠落していました。

さらに厄介だったのは、試験中にsudo漏れに気づけなかったことです。権限不足のときに Permission denied のような一目でそれとわかるエラーが出れば良いのですが、実際には作業によってはかなりの長文エラーが出力され、それを読んでもなお「権限が足りていないのだ」と気づけませんでした。

練習環境と本番環境の「実行ユーザーの違い」は、意外に見落とされがちな落とし穴です。
普段rootで演習している方は、意識的に一般ユーザー + sudo で練習する時間を作ることをおすすめします。

設定ファイルのパスについても同様です。「どこに何を書くか」を毎回ドキュメントで探しているようでは、2時間はあっという間に溶けます。

3. 3回目に向けて変えたこと

3回目に向けて私が最も時間を使ったのは、新しい知識のインプットではなく、「自分の手が止まる場所」の潰し込みでした。前章の「確認までを1問とする」習慣づけに加えて、次の2つに取り組みました。

対策1. 自己学習中に遭遇したエラーを一つ残らず理解する

実技試験では、自分の操作が原因で発生するエラーやトラブルへの対処も、試験時間の中で行わなければなりません。第1弾でも「誤って作成したリソースを削除・訂正するスキル」に触れましたが、CKSではその重要度がさらに上がります。

そして、それ以上に重要なのが次の点です。

自己学習の中で「いつもこの操作をやるとエラーが出るなあ」と感じているものさえも、エラーの意味・原因・対処を確実に身につけておく

本番中に「あ、これ自己学習中に遭遇したエラーだ……でも解決方法がわからないんだよな」となるのは、非常にもったいないことです。「あのとき調べておけばよかった」と本番で思うのは、何としても避けたいものです。

幸い、今は生成AIという強力な学習パートナーがあります。エラーメッセージを貼り付けて「なぜこれが起きるのか」「どう直すのか」「そもそもどうすれば起こさずに済むのか」を掘り下げる作業は、以前と比べて圧倒的に低コストになりました。「後で調べよう」を作らないことをおすすめします。

対策2. 環境差分に慣れる

1回目で自覚した「見慣れていない出力に一瞬止まる」問題への対策として、普段の業務環境とは別に、試験環境に近い構成を手元に用意して手を動かしました。この「環境差分」が具体的に何だったのかは、後述の6章でお話しします。

「知っている」と「手が覚えている」の間には明確な差があります。2時間の試験では、後者だけが得点になります。

4. 私が使った練習環境と、その使い方

学習教材は相性が大きく出る領域ですので、あくまで私個人の感想としてお読みください。

主に使ったもの：KodeKloud と KillerCoda

私が主に使用した練習環境は KodeKloud と KillerCoda です。どちらも素晴らしい演習環境で、とても良い経験を得られました。ブラウザだけで手を動かせるため、隙間時間の学習とも相性が良かったです。

Killer.sh について —— 第1弾での紹介を踏まえて

第1弾では、公式の模擬試験環境として Killer.sh を紹介しました。CKA・CKADの受験にあたっては、試験当日の感覚をつかむうえで有用だと今でも考えています。

ただ、CKSに関して受験後の感想も含めて正直に書くと、私の学習段階には合っていませんでした。

Killer.shは本番より難易度を高めに作られていると言われます。その狙い自体は理解できるのですが、基礎が固まりきっていない段階で難問に触れると、得られるものより「不安」のほうが大きくなるというのが私の実感でした。解けば解くほど「CKSはこんなに難しいのか」という気持ちが膨らみ、そこで削られたメンタルのコストのほうが大きかったのです。

一方で、「本番より難しい環境で鍛えられたおかげで自信を持って臨めた」という評価も数多く見かけます。おそらくこれは、使うタイミングの問題です。受験料に含まれている以上、まずは1回試してみて、自分の現在地に対して有効かどうかを判断するのが良いと思います。

私にとって効果的だった時間の使い方

振り返ると、私にとって費用対効果が高かったのは次の配分でした。

  1. KodeKloud・KillerCodaで、各機能や性質の概念と基本操作を身につける
  2. そのうえで、それらをいかに本番で凡ミスなくコントロールできるかに時間を費やす

つまり、より難しい問題を解けるようにすることよりも、すでに解ける問題を確実に落とさない状態を作ることに時間を使いました。2章で書いた「applyが通っただけで安心しない」という習慣づけは、まさにこの時間の中で身につけたものです。

模擬試験は「満点を取るため」に使わなかった

KodeKloudの章末にある3つの模擬試験(Mock Exam)は反復しましたが、すべての問題を時間内に完答する、という使い方はしていません。苦手な箇所や、出題されそうだと感じた問題だけにフォーカスし、そこだけを練習する目的で使いました。

そのため、私はMock Examで一度も満点を取っていません。それでも本番は87点でした。

模擬試験を「本番のリハーサル」として使うのか、「弱点を探すための道具」として使うのかは、人によって、また学習段階によって変わってよいと思います。満点が取れないことに落ち込む必要はありません。

5. 試験要項は、必ず自分で公式サイトを読んでおく

凡ミスと並んで時間を奪うのが、試験環境そのものへの不慣れです。

そして私が声を大にしてお伝えしたいのは、ここを他人のブログで済ませてはいけないということです。本記事も含め、受験記に書かれた試験環境の情報は、書かれた時点のスナップショットにすぎません。

なぜ自分で読むべきなのか

CKSの試験環境や受験要件については、Linux Foundationが公式ドキュメントとして公開しています。そこには、作業をどのホストで行うのか、どのツールがどこに用意されているのか、受験マシンに求められる要件は何か、といったことが具体的に書かれています。

これらは改定されます。 バージョンの更新、環境構成の変更、参照可能ドキュメントの見直し —— いずれも運営側の判断で変わりうるものです。

にもかかわらず、こうした情報は「ブログに書いてあった内容」として口コミで流通しがちです。古い情報のまま本番に臨むと、想定と違う環境に戸惑い、そこで時間を失います。 これは知識不足とはまったく別種の、もったいない失点です。

受験申込みをしたら、まず以下の公式ドキュメントを一通り読んでください。

特に参照が許可されているドキュメントの範囲については、「この記事に書いてあったから」という理由で許可外のサイトを開くことのないよう、必ずご自身で最新の内容をご確認ください。

事前のシステムチェックは面倒でも必ず

受験マシンが要件を満たしているかは、PSI Online Proctoring System Check で事前に確認できます。

要件の詳細は公式ドキュメントに譲りますが、ネットワークは有線接続を優先する、同一回線で帯域を消費する活動を止めておく、ノートPCは電源に接続しておくといった基本は、当日になって慌てないよう前日までに整えておくことをおすすめします。

配点比率は、学習計画のためのもの

出題領域と配点比率も公式サイトに記載されていますので、学習計画を立てる際にはぜひ確認してください。

但し、実際に受験してみると、受験中は「この問題がどのカテゴリなんだ」などと意識しながら解けるほど(時間的にも気持ち的にも)余裕はありません。私は「一問でも多く問題を解く！」というマインドで挑んでいました。配点比率は学習計画を立てる段階で使うもの、と割り切るのが良さそうです。

6. 1回目：CKAD合格の5日後に受験した結果

ここからは、私の3回の受験の顛末です。

なぜ準備不足のまま受験したのか

第1弾でお話しした通り、私はバウチャーの有効期限切れが迫るなかで、CKA再挑戦・CKADと駆け抜けていました。その勢いのまま、CKAD合格からわずか5日後にCKSの1回目を受験しています。

理由は単純で、手元のCKSバウチャーの有効期限が、残り10日ほどに迫っていたためです。CKSの学習を始めたのは、CKAD合格発表の翌日である8月20日でした。

「CKAD合格から1回目受験まで5日間」とだけ聞くと、多少なりとも詰め込む時間があったように見えるかもしれません。ですが実態はもう少し厳しいものでした。この時期、我が家の子どもたちは夏休みの真っ只中です。まとまった学習時間はほとんど確保できず、断片的な時間をかき集めての5日間というのが正直なところでした。

そのため当初から「1回目は試験の内容と雰囲気を知るための受験、2回目で合格する」というプランを立てていました。……とはいえ、正直に告白すると、密かに1回目での合格も狙っていました。結果はご覧の通り、40点です。知識不足が素直に点数に出ました。

CKSの受験資格(Exam Eligibility)は購入から12ヶ月間です。第1弾でも書きましたが、購入のタイミングと学習計画はセットで考えることを、重ねて強くおすすめします。

1回目で見えた「私固有の弱点」

1回目を受けて痛感したのは、知識量以前の問題として、私自身のこれまでの経歴が試験での時間ロスを生んでいるという事実でした。

① 第1弾で書いたOpenShift差分は、CKSでも同じように効いた

第1弾で、CKA1回目の敗因としてOpenShiftとの差分を挙げました。Namespaceを明示しなくても操作が完結してしまうこと、IngressではなくRouteを使う場面が多いこと、状態確認をWebコンソールに頼りがちなこと —— この3点です。

これらはCKSでもそのまま効きました。特にお気づきかと思いますが、2章で挙げた「namespace指定忘れ」という凡ミスの根っこは、まさにここにあります。 普段namespaceを明示せずに操作していれば、-n を書く習慣そのものが身についていません。

つまり私の場合、ベースとなる知識がRed Hat製品寄りに最適化されているがゆえに、Kubernetesディストリビューション間の差分を脳内で変換するタイムラグが生じていたわけです。

② CKSで新たに突きつけられた差分：OSとコンテナエンジン

CKA・CKADではさほど表面化しなかったものの、CKSで明確にハンデとなったのがここです。

私はRed Hatに勤務しているため、日頃触るOSはRHELです。一方、CKSの試験環境はUbuntuベースです。CKSはホストOS側の操作を伴う設問が含まれる試験であるため、コマンドの体系、エラーや実行結果として返ってくるメッセージの見た目、設定ファイルの配置場所といった差分が、CKA・CKADのとき以上に直撃しました。

コンテナ操作についても同様で、日頃使っているのはDockerではなくPodmanです。コマンド体系が近いため大きな混乱はありませんが、それでも**「一度頭の中で読み替える」という処理が挟まります**。

「知らない」わけではないのです。ただ、見慣れていない。この差は机上では小さく見えますが、2時間の試験では、出力を一瞬で読み取れるか、一度立ち止まって読むかの差がそのまま点数に効いてきます。

③ 2時間という試験時間が、私にとってはやはり短い

第1弾で、Red Hat認定資格(3〜4時間)とCKA・CKAD(2時間)の「時間の使い方の性質の違い」について書きました。マラソンのつもりで練習してきた人間が、いきなり短距離走に放り込まれたような感覚です。

CKSでは、この感覚がさらに強まりました。CKA・CKADと同じ2時間でありながら、設問ごとにホストOSとKubernetesを行き来する必要があるぶん、体感の忙しさは明らかに上でした。

この弱点をどう捉えるか

裏を返せば、普段からUbuntuやDockerに触れている方であれば、私より良い点数を取れるはずです。これは能力差ではなく、単純に慣れの差です。

そして、もしあなたがベンダー固有の製品に深く習熟している立場なら、その習熟が試験では一時的にハンデになりうることを、あらかじめコストとして見積もっておくことをおすすめします。「知っている」ことと「その環境の作法で手が動く」ことは別物です。

7. 2回目：バウチャー最終日に起きたアクシデント

その日は、バウチャー有効期限の最終日でした

2回目の受験日は2026年9月4日。実はこの日は、私のバウチャーの有効期限が失効する、まさにその日でした。

1回目の受験時点で残り10日ほどだった期限は、この日で尽きます。つまり、この2回目が文字通りの最後のチャンスでした。「最後の最後で合格を勝ち取る」——そんな意気込みで試験に臨んだことを覚えています。

その思いが、予想もしないトラブルによって思わぬ結果になってしまうわけです。

何が起きたか

2回目の受験では、受験の途中で試験が一時的に進行不能な状態になりました。

具体的な事象は、プロクター(試験監督)側から私の画面を遠隔でモニターできなくなったというものです。監督ができない以上、試験を続行することはできません。

一方で、私自身は試験環境の操作自体は問題なく行えていました。そのため、私の端末やネットワークに起因するものではなく、監督システム側で発生した事象だったのだろうと推測しています。

復旧後も試験時間の延長は行われず、結果として約30分のハンデを負ったまま残りを解き進めることになりました。

ただでさえ忙しい2時間から30分が失われるインパクトは決して小さくなく、時間切れで手を付けられない設問が残りました。結果は55点。合格ラインには届きませんでした。

試験後に取った対応 —— クレームではなく「相談」として

試験終了後、Linux Foundationのサポート窓口(trainingsupport.linuxfoundation.org)に問い合わせを行いました。

ここで意識したのは、これは苦情ではなく相談であるという姿勢です。起きた事象を事実として整理し、それによって受験時間が不足したこと、その影響がどうだったかを説明したうえで、何らかの救済措置が可能かを尋ねる、という組み立てにしました。

実際に伝えた内容として、特に効いたと感じているのは次の3点です。

  1. CKA・CKADの受験時とまったく同じ環境で受験していたこと。 過去2回は同じ環境で問題なく完走できており、私の側に環境変更がなかったことを明示しました。
  2. その環境がThe Linux Foundationの推奨要件を満たしていること。 推奨環境で受験していた以上、受験者側の準備不足に起因する事象ではない、という切り分けの材料になります。
  3. 試験環境の操作自体は継続できていたこと。 事象が監督システム側で発生したものであることを示す材料です。

そしてもう一つ、正直に書いておきたいことがあります。

問い合わせの文面は、生成AI(私の場合はGemini)と一緒に作成しました。

英語でのやりとりであったこともありますが、それ以上に大きかったのは、感情を排して、丁寧かつ建設的な文章に整えられたことです。試験直後というのは、どうしても気持ちが昂っています。その状態で自分だけで文章を書いていたら、事実の説明よりも不満の表明が前に出た文面になっていたかもしれません。

相手も人です。受け取った側が「この人の状況を確認してみよう」と思える文章になっているかどうかは、結果を左右する要素だと思います。

結果として、無償での3回目の受験機会を割り当てていただきました。丁寧に対応いただいたサポート担当の方には感謝しています。

そして私にとって重要だったのは、付与されたバウチャーが、本来の期限である9月4日を越えて受験可能なものだったことです。

その場では「最後のチャンスを潰された」という気持ちでいっぱいでしたが、結果だけを見れば、このトラブルがあったからこそ期限の壁が外れ、首の皮一枚がつながったとも言えます。もしあの日、トラブルなく受験して55点だったとしたら、そこで私のKubestronaut挑戦は終わっていたかもしれません。

物事の評価は、その瞬間には決まらないものだなと思わされた出来事でした。

この章で一番お伝えしたいのは、「最初から諦めない」という選択肢を持っておいてほしい、ということです。

試験でトラブルに遭遇したとき、「まあ仕方ないか」と飲み込んでしまう方は少なくないと思います。ですが、事実を整理して丁寧に相談すれば、道が開ける可能性はあります。

相談の際に意識すると良いと感じた点は次の通りです。

  • 発生日時・発生した事象・中断していたおおよその時間・それによる影響を、具体的かつ事実ベースで伝える
  • 自分の環境側では何が正常に動いていたかをあわせて伝える(原因の切り分け材料になります)
  • 過去の受験実績や、推奨要件を満たしている環境であることなど、自分側に問題がなかった根拠を添える
  • 感情を排し、丁寧で建設的な文面に整える(生成AIに推敲を手伝ってもらうのは有効です)

ただし、対応内容は個別の状況に応じた判断であり、必ず同じ結果になることを保証するものではありません。 あくまで「私のケースではこうだった」という一例としてお読みください。

8. これからCKSを受験する方へ

私の3回の経験から、お伝えしたいポイントをまとめます。

  • 学習の本体は、セキュリティ機能群の理解です。ここを飛ばして小手先の対策に走っても点数にはなりません。まずは正攻法で積み上げてください
  • CKA・CKAD相当の操作スキルは前提です。マニフェストを正しく書けることは最低ラインであり、そこで手が止まるとセキュリティの本題にたどり着けません
  • そのうえで、「applyが通った」を正解と思わないこと。namespace指定忘れ、サイドカーの見落とし、annotation漏れ。いずれもコマンドは成功します。設定後の確認までを1問としてください
  • 練習環境と本番の実行ユーザーの違いを意識すること。常にrootの環境で練習していると、sudo を打つ習慣が失われます
  • 自己学習中のエラーを一つも放置しないこと。本番の2時間は、未知を調べる時間でも、既知のエラーに悩む時間でもありません
  • 難問を解けるようにするより、解ける問題を落とさない練習に時間を使うこと。少なくとも私の場合は、こちらのほうが点数に直結しました
  • 試験要項は、必ず自分で公式サイトを読むこと。試験環境や参照可能ドキュメントの範囲は改定されます。ブログの情報を鵜呑みにしないでください(本記事も含めて、です)
  • 時間感覚をCKA・CKAD以上に引き締めること。ホストOSとKubernetesを行き来するぶん、体感の忙しさは上です
  • 受験環境の事前チェックを必ず行うこと。それでもトラブルが起きたときは、諦める前に公式サポート窓口へ。クレームではなく相談として、事実を整理して丁寧に伝えるという選択肢を持っておいてください
  • バウチャーの有効期限に学習計画を振り回されないこと。12ヶ月あります。私のように追い詰められる必要はありません
  • 特定ベンダーの環境に習熟している方は、その差分をコストとして見積もること。「知っている」ことと「その環境の作法で手が動く」ことは別物です

9. モチベーションの維持について

技術的な話から少し離れた、個人的な話をさせてください。

正直なところ、CKSの学習期間中はモチベーションの維持が少しつらい時期がありました。

理由は明確で、CKSで扱う内容は、私が普段扱っているRed Hat製品に直接関わる箇所が多くはないからです。「これを学んでも、業務で活かせる場面は限られるかもしれないな」という思いが、どうしても頭をよぎりました。加えて、上司から取得を指示されているわけでもありません。動機は純粋に、これまで認定資格を取得し続けてきた者としての意地やプライドのようなものだけでした。

それでも学習を続けられたのは、途中で見方が変わったからです。

Red Hat製品と直接関係がなかったとしても、業界全体を知るきっかけにはなる

この視点を持てたことが、後半の原動力になりました。

そして実際、その通りでした。FalcoやTrivy、kube-benchをはじめ、Kubernetes界隈で当たり前のように名前が挙がるツール群に、体系立てて触れる機会を得ることができました。自分の技術的な視野が確実に広がったという意味で、大変良い経験だったと思っています。

ベンダー資格とベンダーニュートラル資格の両方を持つ意味は、まさにここにあるのかもしれません。

10. あとがき —— Kubestronautへ

2026年9月17日、CKSに87点で合格し、KCNA・KCSA・CKA・CKAD・CKSの5資格が揃いました。Kubestronautの条件を満たした瞬間です。

参考：Kubestronaut | CNCF公式

第1弾の冒頭に掲げた全記録を振り返ると、KCNA受験から実に1年。そのうち11ヶ月はバウチャーを放置していた期間でしたので、実質的な挑戦期間はわずか1ヶ月ほどということになります。あまり褒められた進め方ではありません。

そしてCKSは3回の受験を要しました。決して自慢できる回数ではありませんが、振り返ってみると、それぞれの不合格には明確に異なる意味がありました。

1回目は、単純な準備不足という自分の責任。2回目は、自分ではコントロールできない事象。そして3回目でようやく、「準備すべきことを準備したうえで臨む」という当たり前の状態を作ることができました。

結局、CKSにはどれくらいの学習時間をかけたのか

最後に、これから挑戦される方が一番気になるであろう数字にも触れておきます。

CKSの学習を開始したのは8月20日、合格したのは9月17日です。期間としてはほぼ1ヶ月でした。ただし、この間ずっと勉強漬けだったわけではありません。1日あたりの学習時間は、平均すると2時間前後です。単純計算すると、トータルではおよそ50時間ほどの学習で合格した計算になります。

正直なところ、この時間が「多い」のか「少ない」のかは、比較対象次第だと思います。ただ、少なくとも私にとっては、まとまった時間を一気に確保するより、毎日2時間程度を積み重ねるほうが現実的でした。特に1回目の受験までの5日間のように、夏休み中の子どもの世話でまとまった時間が取れない時期があっても、それでも前へ進められるという意味で、この積み上げ方には再現性があると感じています。

第1弾では、CKA1回目の敗因が「知識不足ではなく、試験という土俵の違いへの準備不足だった」と書きました。CKSで得た結論も、実はよく似ています。

40点と87点を分けたのは、知識量ではありませんでした。 実技試験において点数を左右するのは、身につけたものを取りこぼさずに出し切れるかという、案外地味な部分なのだと思います。

これからCKSに挑戦される方、そしてKubestronautを目指される方の準備の一助になれば幸いです。

記事の内容でわかりにくい点や、追記してほしい点がありましたら、ぜひコメント欄でお知らせください。

参考(公式情報)

関連記事

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?