AWS 認定資格 ラボ
CLF（Cloud Practitioner）攻略 ・

CLF 試験のひっかけ問題パターン 10 選｜CLF-C02 で落とさないための見抜き方

AWS Certified Cloud Practitioner（CLF-C02）で多くの受験者が取りこぼす「ひっかけ問題」を 10 パターンに整理した。CLF の不正解選択肢は、知識が曖昧な人ほど選んでしまう“もっともらしい誤答”として作られている。似たサービスの混同（CloudWatch／CloudTrail／Config、WAF／Shield／GuardDuty）、最上級・絶対表現（「常に」「最も安い」「すべて」）の罠、責任共有モデルの境界線、ストレージクラスとアーカイブの取り出しコスト、料金モデル（On-Demand／Reserved／Spot／Savings Plans）の使い分け、サポートプランの機能境界、Well-Architected 6 本柱の取り違え、グローバルインフラ（Region／AZ／Edge）の混同、IAM 用語（ユーザー／ロール／ポリシー／ルートユーザー）、そして「2 つ選べ」の複数選択でのキーワード読み落とし——この 10 型を、例題・なぜひっかかるのか・見抜き方の 3 点セットで解説する。各論点は関連記事と模擬試験に直結させ、間違えたその場で弱点を潰せる構成にした。本番直前の「最終チェックリスト」として使ってほしい。

#AWS #CLF #CLF-C02 #クラウドプラクティショナー #ひっかけ問題 #試験対策 #練習問題 #AWS認定資格

CLF-C02 で落ちる人の多くは「知らなかった」のではなく「ひっかかった」。CLF の不正解選択肢は、知識が曖昧な受験者ほど選んでしまう“もっともらしい誤答”として設計されている（出題形式は CLF 試験完全ガイド と 4 ドメイン完全マップ のとおり、択一は正解 1・誤答 3、複数選択は「2 つ選べ」）。だからこそ、「どこで引っかけてくるか」を型として知っておくだけで正答率は跳ね上がる。本記事は頻出のひっかけを 10 パターンに整理し、各型を 「例題 → なぜひっかかるのか → 見抜き方」 の 3 点セットで解説する。第 1 回（基礎）・第 2 回（応用）・第 3 回（本番 65 問） で間違えた問題の“傾向”を、この 10 型で言語化してから本番に臨もう。

📑 目次

  1. そもそも CLF の「ひっかけ」とは何か
  2. 型①：似たサービスの混同（CloudWatch／CloudTrail／Config）
  3. 型②：最上級・絶対表現の罠（「常に」「最も安い」「すべて」）
  4. 型③：責任共有モデルの境界線
  5. 型④：ストレージクラスと「取り出しコスト」
  6. 型⑤：料金モデルの使い分け
  7. 型⑥：サポートプランの機能境界
  8. 型⑦：Well-Architected 6 本柱の取り違え
  9. 型⑧：グローバルインフラ（Region／AZ／Edge）の混同
  10. 型⑨：IAM 用語のすり替え
  11. 型⑩：「2 つ選べ」とキーワード読み落とし
  12. 本番直前チェックリスト
  13. 関連記事
  14. 関連サイト

1. そもそも CLF の「ひっかけ」とは何か

裏を返せば、ひっかけは パターンが有限ということだ。本記事の 10 型を頭に入れておけば、選択肢を見た瞬間に「これは型①の混同狙いだな」とメタ的に見抜ける。知識の暗記量を増やすより、まずは間違えさせ方の型を覚えるほうが、CLF では費用対効果が高い。

2. 型①：似たサービスの混同（CloudWatch／CloudTrail／Config）

CLF で最も多いひっかけが、役割の似た監視・ガバナンス系サービスの差し替えだ。

なぜひっかかるのか： CloudWatch（メトリクス・ログの監視）と CloudTrail（API 呼び出しの証跡）はどちらも「ログ」を扱うため混同しやすい。正解は B. CloudTrail。CloudWatch を選ばせるのが狙いだ。

混同しやすい監視・ガバナンス 3 兄弟
評価項目
担当する問い
代表的なキーワード
CloudWatch（監視） リソースは元気か？ メトリクス・アラーム・ダッシュボード
CloudTrail（証跡） 誰が何をしたか？ API 呼び出し・操作履歴・監査
Config（構成） 設定はどう変わったか？ リソース構成・変更履歴・準拠
「監視＝CloudWatch／操作の証跡＝CloudTrail／構成変更＝Config」の対応を丸暗記する

見抜き方： 設問の主語を確認する。「誰が」なら CloudTrail、「元気か」なら CloudWatch、「設定変更」なら Config。詳しくは CloudWatch・CloudTrail・AWS Config を対比して読むと一発で定着する。同じ構図は WAF（アプリ層）／Shield（DDoS）／GuardDuty（脅威検知） でも頻出する（ドメイン 2：セキュリティ 参照）。

3. 型②：最上級・絶対表現の罠（「常に」「最も安い」「すべて」）

選択肢に 「常に（always）」「すべて（all）」「決して〜ない（never）」「最も（most）」 といった断定が含まれていたら警戒する。

なぜひっかかるのか： A・B・D はどれも「AWS が全部やってくれる」という心地よい断定で、初学者ほど選びたくなる。正解は C。

見抜き方： AWS の世界に 「常に・すべて・絶対」はほぼ無い（モデルや条件で変わるのが普通）。断定表現は誤答のサインと覚え、逆に「〜できる」「〜に役立つ」といった控えめな表現の選択肢が正解になりやすい。ただし「ルートユーザーは MFA を有効化すべき」のようなベストプラクティス系の“べき”は正しいので、断定＝即不正解と機械的にしないこと。

4. 型③：責任共有モデルの境界線

「これは AWS の責任か、利用者の責任か」を問う設問は、サービス種別（IaaS／PaaS／マネージド）で境界が動くことを突いてくる。

なぜひっかかるのか： マネージドサービスの RDS は OS やエンジンのパッチを AWS が代行するため、「A. パッチ適用」を利用者責任だと誤答させたい。正解は C。「データ・IAM 権限・ネットワーク設定（セキュリティグループ）」は常に利用者側だ。

見抜き方： 「データと、それへのアクセス制御は常にお客様の責任」という軸を持つ。EC2（IaaS）なら OS パッチも利用者責任だが、RDS や Lambda などマネージド度が上がるほど AWS 側に寄る——このスライドが論点。境界の全体像は 責任共有モデルを完全理解 で図解している。

5. 型④：ストレージクラスと「取り出しコスト」

S3 のコスト最適化問題は、「保管料金の安さ」だけを見せて「取り出し料金・取り出し時間」を隠すのが定番のひっかけだ。

なぜひっかかるのか： 「とにかく安い＝標準 -IA」と早合点させたい。正解は C. Glacier Deep Archive。アクセス頻度と許容できる取り出し時間が条件にある時点で、アーカイブ階層が答えになる。

アクセス頻度で選ぶ S3 ストレージクラス
評価項目
想定アクセス
取り出し
S3 標準 頻繁 即時・取り出し料なし
S3 標準 -IA / One Zone-IA 月数回 即時・取り出し料あり
S3 Glacier Flexible / Instant 四半期〜年数回 数分〜数時間
S3 Glacier Deep Archive 年 1 回未満 最大 12 時間・最安
「保管が安い＝総コストが安い」ではない。取り出し頻度と時間を必ず読む

見抜き方： 設問に 「ほとんどアクセスしない」「数時間かかってよい」「長期保存」 が出たら Glacier 系を疑う。逆に「即座にアクセス」が条件なら -IA まで。詳細は S3 ストレージクラス と S3 Glacier 3 階層 を参照。「アクセス頻度が読めない」なら自動で階層を動かす Intelligent-Tiering が正解になるパターンもある。

6. 型⑤：料金モデルの使い分け

EC2 の購入オプションは 「安さ」と「中断耐性／コミット期間」のトレードオフを問う形で出る。

なぜひっかかるのか： 「安い＝リザーブド or Savings Plans」と刷り込まれていると、最安の C. スポットを見落とす。**「中断されてもよい」**という条件こそがスポットを指す決定打だ。

EC2 購入オプションの使い分けキーワード
評価項目
向くワークロード
決め手のフレーズ
オンデマンド 短期・予測不能 「コミットしたくない」
リザーブド／Savings Plans 1〜3 年の定常利用 「常時稼働」「長期割引」
スポット 中断 OK のバッチ・耐障害ジョブ 「中断されてもよい」「最安」
“最安”だけで Savings Plans に飛びつかない。中断可否がスポットの分かれ目

見抜き方： 「中断・再実行 OK」＝スポット、「常時稼働で長期割引」＝Savings Plans／リザーブド、「縛られたくない」＝オンデマンド。料金モデルの全体像は AWS の料金モデル、スポットの仕組みは EC2 スポットインスタンス、コミット型割引は Savings Plans で深掘りできる。

7. 型⑥：サポートプランの機能境界

サポートプランは 「どのプランから何が使えるようになるか」の境界をピンポイントで突く。

なぜひっかかるのか： 「本番停止 1 時間以内対応＝Business」までは合っていても、TAM が付くのは Enterprise（および Enterprise On-Ramp）だけという上乗せ条件を見落とす。正解は D。

見抜き方： TAM・Infrastructure Event Management が出たら Enterprise、本番停止 1 時間応答・電話/チャットが出たら Business 以上、Developer はビジネス時間のみ・メール中心、Basic は課金/アカウント問い合わせのみ。境界の表は AWS サポートプラン 4 種の違い にまとめてある。

8. 型⑦：Well-Architected 6 本柱の取り違え

シナリオがどの「柱」に当たるかを問い、似た柱（信頼性 vs パフォーマンス効率）で誤答させる。

なぜひっかかるのか： 「自動でスケール」という語感から A. パフォーマンス効率に引っ張られる。だが「障害からの回復・可用性」は **B. 信頼性（Reliability）**の領域だ。

見抜き方： 柱ごとのキーワードを紐づける——信頼性＝障害復旧/冗長化、パフォーマンス効率＝適材適所のリソース選択、運用上の優秀性＝自動化/監視/改善、セキュリティ＝最小権限/暗号化、コスト最適化＝無駄の排除、持続可能性＝環境負荷。6 本柱の整理は Well-Architected 6 つの柱 を参照。

9. 型⑧：グローバルインフラ（Region／AZ／Edge）の混同

「どの粒度の話か」を リージョン／アベイラビリティーゾーン（AZ）／エッジロケーションで取り違えさせる。

なぜひっかかるのか： 「世界中・近い拠点」で A. リージョンを選ばせたい。CDN のキャッシュ拠点は C. エッジロケーションだ。

見抜き方： 高可用性のための物理分離＝AZ（1 リージョン内に複数）、法令/レイテンシで選ぶ地理単位＝リージョン、CDN/DNS のユーザー近接配信＝エッジロケーション。この 3 段の入れ子構造は AWS のグローバルインフラ で図解している。

10. 型⑨：IAM 用語のすり替え

IAM は ユーザー／グループ／ロール／ポリシー／ルートユーザーの用語をすり替えて誤答を作る。

なぜひっかかるのか： 「キーを安全な場所に保存すれば OK」という発想で B. アクセスキーを保存を選ばせたい。だがアクセスキーの埋め込み自体が非推奨で、正解は C. IAM ロールのアタッチ。ロールは一時的な認証情報を自動でローテーションするため、キー漏洩リスクがない。

見抜き方： 用語の役割を固定する——ユーザー＝人間の長期 ID、グループ＝ユーザーへの権限の束、ロール＝一時的に“なりすます”権限（サービス間・クロスアカウント）、ポリシー＝許可/拒否の中身（JSON）、ルートユーザー＝最強だが日常利用禁止・MFA 必須。「アプリやサービスに権限を渡す＝ロール」は鉄板パターン。詳細は IAM 完全ガイド を参照。なお「機密情報を安全に保存」が論点なら KMS との組み合わせも問われる。

11. 型⑩：「2 つ選べ」とキーワード読み落とし

最後は知識ではなく読み方のひっかけ。CLF-C02 には 「2 つ選べ（Choose TWO）」の複数選択があり、両方正解で 1 問正解だ。

なぜひっかかるのか： ① 「2 つ」を見落として 1 つだけ選ぶ、② もっともらしい誤答 B（オンデマンドは割高）に引っかかる——の二段構え。正解は A と C。

見抜き方： 設問の 数量指定（TWO/THREE）と評価軸（コスト/可用性/セキュリティ）を最初に確定してから選択肢に入る。本番は英語原文に切り替えられるので、訳が曖昧な設問は原文で「MUST」「MOST cost-effective」などのキーワードを確認しよう。

12. 本番直前チェックリスト

ひっかけは「型」さえ知っていれば、本番で選択肢を見た瞬間にメタ視点で警戒できる。あとは 3 回分の模擬試験 で、間違えた問題がどの型だったかをメモしながら復習すれば、弱点は急速に埋まる。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

教材選びに迷ったら： 本番形式に近い問題量をこなすほどひっかけ耐性は上がる。市販の問題集や Udemy 講座、AWS 公式の模擬試験を組み合わせ、「間違えた論点を関連記事で潰す」サイクルを回すのが最短ルートだ（教材比較は今後の記事で詳説予定）。

13. 関連記事

14. 関連サイト

AWS 公式