AWS認定クラウドプラクティショナー（CLF-C02）の出題分野1「クラウドのコンセプト」から、練習問題10問を無料で公開します。
この分野の出題割合は24%です。4つの分野のうち2番目に大きく、65問のうちおよそ15〜16問がこの分野から出ます。
分野1で問われるのは、個々のAWSサービスの使い方ではなく、クラウドを使うと何が変わるのかという考え方です。具体的には、クラウドの利点（固定費が変動費になる、キャパシティの推測が不要になる、など）、システム設計を評価する AWS Well-Architected Framework の6つの柱、組織としての導入準備を整理する AWS Cloud Adoption Framework（AWS CAF）の6つのパースペクティブが中心になります。
この分野でつまずきやすいのは、Well-Architected Framework の「柱」と AWS CAF の「パースペクティブ」の取り違えです。どちらも6つの観点で構成されていて、「セキュリティ」という同じ名前の観点を持っています。試験では両者を入れ替えた選択肢が並ぶので、「システムの設計を評価するのが Well-Architected、組織の準備を整理するのが CAF」という役割の違いで見分けられるようにしておく必要があります。今回の10問には、この取り違えを狙った問題を複数入れています。
まず問題文と選択肢だけを読んで答えを決め、それから「解答と解説を見る」を開いてください。10問中3問は複数選択（2つ選択）です。
問題1単一選択
ある企業が、AWS上に新しいアプリケーションを構築するにあたり、AWS Well-Architected Frameworkの設計原則に沿った方針を決めようとしています。次のうち、このフレームワークが推奨している設計原則に該当するものはどれですか。
- 本番より小さな環境で性能を検証すれば十分だとみなします
- 需要が最も高くなる時点に合わせて、リソースを事前に用意しておきます
- 障害が起きても自動で復旧できるように、あらかじめ設計しておきます
- 構成要素どうしを密接に結びつけて、一体のものとして動かします
解答と解説を見る
正解：回答 3
回答 1 不正解 縮小した環境で動作を確かめれば足りるとする考え方です。AWS Well-Architected Frameworkは「本稼働スケールでシステムをテストする」ことを一般的な設計原則に挙げています。クラウドでは本番規模の環境を必要な時間だけ用意できるため、縮小環境で妥協する理由がありません。本番規模のテストは、負荷や障害時の挙動を事前に確かめるものです。
回答 2 不正解 ピーク時の需要を見込んでリソースを先に確保しておく考え方です。これはオンプレミスの発想で、AWS Well-Architected Frameworkは「容量ニーズの推測をやめる」ことを設計原則に挙げています。需要を監視しながらリソースを自動で増減させれば、余分な費用を払わずに済みます。事前確保は、自社設備で機器を買い切るときの考え方です。
回答 3 正解 障害からの自動復旧は、AWS Well-Architected Frameworkの信頼性の柱に含まれる設計原則です。主要な指標を監視し、しきい値を超えたら自動で通知や復旧処理を実行するように作っておけば、人が気づいて手作業で直すよりも早く、確実に回復できます。障害は起きるものと考え、起きても自動で立て直せる構成にすることが求められています。
回答 4 不正解 コンポーネント同士を強く依存させる、いわゆる密結合の考え方です。AWS Well-Architected Frameworkの信頼性の柱では、キューなどの中間層を挟んで依存関係を弱める疎結合を勧めています。密結合では1つの部品の障害がそのまま全体の停止につながり、部品ごとの変更もしにくくなります。疎結合は、障害の影響範囲を小さく抑えるために使います。
問われている要件
- AWS Well-Architected Frameworkが推奨する設計原則を知っていること
- オンプレミス時代の発想（事前確保・密結合・縮小テスト）と、クラウドの設計原則を区別すること
- 障害を前提にして自動復旧を組み込む考え方を理解していること
前提知識
AWS Well-Architected Frameworkとは
- AWS上でシステムを設計・運用するときの考え方を、AWSがまとめたガイドラインです。運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の6つの柱で構成され、柱ごとに設計原則とベストプラクティスが書かれています。
- 自動車の定期点検の項目表のようなもので、「この観点は満たせているか」を設計の前に確認するために使います。
信頼性の柱の設計原則
- 信頼性の柱には、障害から自動的に復旧する、リカバリ手順をテストする、水平方向にスケールして可用性を高める、容量の推測をやめる、変更を自動化で管理する、という5つの設計原則があります。
- 「障害から自動的に復旧する」は、主要な指標を監視し、しきい値を超えたときに自動で復旧処理を動かす考え方です。障害を完全に防ぐのではなく、起きても自動で立て直せることを目指します。
クラウドで変わる設計の前提
- 一般的な設計原則には「容量ニーズの推測をやめる」「本稼働スケールでシステムをテストする」も含まれます。クラウドではリソースを必要な分だけ、必要な時間だけ使えるため、ピークに合わせた事前確保や縮小環境でのテストといった妥協が不要になります。
- 構成要素の間はキューなどを挟んで疎結合にし、1つの部品の障害が全体へ広がらないようにするのが基本です。
解くための考え方
問題文の「AWS Well-Architected Frameworkが推奨している設計原則」という言葉に注目します。問われているのは、クラウドならではの設計の考え方として公式に挙げられているものはどれか、という点です。
選択肢を読むときは、「オンプレミスで機器を買い切る時代の発想か、クラウドの特徴を活かした発想か」という観点で見ます。ピークに合わせた事前確保は容量の推測そのもので、縮小環境で十分とみなす検証は本番規模でテストできるクラウドの利点を捨てています。密結合は障害の影響を全体に広げる構成で、いずれも推奨とは逆の内容です。
障害が起きても自動で復旧するように設計する、という内容だけが、信頼性の柱に書かれている設計原則に一致します。
「推測をやめる」「自動化する」「本番規模で試す」「疎結合にする」「自動で復旧する」が出てきたら推奨側、「事前に確保する」「手作業で」「密に結合する」が出てきたら避けるべき側、と対応づけて判断すると確実です。
参考資料：一般的な設計原則 – AWS Well-Architected フレームワーク、設計原則 – 信頼性の柱、REL04-BP02 疎結合の依存関係を実装する – 信頼性の柱、AWS Well-Architected フレームワーク – AWS Well-Architected フレームワーク、AWS Well-Architected – 安全で効率的なクラウドアプリケーション
問題2単一選択
ある企業が、クラウド導入の計画を立てるにあたりAWS Cloud Adoption Framework（AWS CAF）を参照しています。AWS CAFがクラウド導入に必要な機能をまとめている6つのパースペクティブに含まれるものはどれですか。
- コスト最適化
- パフォーマンス効率
- ガバナンス
- 信頼性
解答と解説を見る
正解：回答 3
回答 1 不正解 コスト最適化は、AWS Well-Architected Frameworkの6つの柱の1つで、無駄な支出を避けて費用対効果の高い構成にするための観点です。個々のシステムの設計を評価する枠組みであり、組織全体の導入準備を整理するAWS CAFのパースペクティブには含まれません。構築したシステムの料金を見直すときに使う観点です。
回答 2 不正解 パフォーマンス効率は、AWS Well-Architected Frameworkの柱の1つで、需要の変化に応じてコンピューティングリソースを効率よく使うための観点です。システムの構成を評価する枠組みなので、AWS CAFのパースペクティブではありません。インスタンスやストレージの選び方を点検するときに使います。
回答 3 正解 ガバナンスは、AWS CAFの6つのパースペクティブの1つです。クラウドの取り組みを組織として統制し、投資の効果を高めてリスクを抑えるための観点で、プロジェクト管理、リスク管理、クラウドの財務管理、データガバナンスなどが含まれます。ビジネス、人材、プラットフォーム、セキュリティ、オペレーションと並ぶ観点です。
回答 4 不正解 信頼性は、AWS Well-Architected Frameworkの柱の1つで、障害が起きても期待どおりに動き続け、自動で復旧できるシステムにするための観点です。技術的な設計を評価する枠組みであり、組織の体制を整理するAWS CAFのパースペクティブには当たりません。複数のアベイラビリティーゾーンへの分散を検討するときに使います。
問われている要件
- AWS CAFの6つのパースペクティブの名前を知っていること
- AWS CAFのパースペクティブと、AWS Well-Architected Frameworkの柱を混同しないこと
- どちらが「組織の準備」を扱い、どちらが「システムの設計」を扱うかを区別すること
前提知識
AWS Cloud Adoption Framework（AWS CAF）とは
- AWS CAFは、企業がクラウドを導入するときに組織として何を整えるべきかをまとめた枠組みです。ビジネス、人材、ガバナンス、プラットフォーム、セキュリティ、オペレーションの6つのパースペクティブ（観点）に分かれています。
- 会社の部門に置き換えると、ビジネスは経営企画、人材は人事、ガバナンスは経営管理や監査、プラットフォームは情報システム、オペレーションは運用部門にあたります。
ガバナンスのパースペクティブとは
- クラウドの取り組みを組織として統制し、利益を最大化しながらリスクを抑えるための観点です。プログラム・プロジェクト管理、リスク管理、クラウドの財務管理、データガバナンスといった機能が含まれ、CIOやCFOなどの経営層が関わります。
AWS Well-Architected Frameworkの柱との違い
- AWS Well-Architected Frameworkは、AWS上に作る個々のシステムの設計を評価する枠組みで、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の6つの柱があります。
- セキュリティはどちらにも登場しますが、信頼性やコスト最適化などはWell-Architectedの柱だけにあり、ガバナンスやビジネス、人材はAWS CAFだけにあります。
図による解説
解くための考え方
問題文の「AWS Cloud Adoption Framework（AWS CAF）」と「6つのパースペクティブ」という言葉に注目します。問われているのはAWS CAF側の観点の名前であり、AWS Well-Architected Frameworkの柱ではありません。
AWS CAFの6つのパースペクティブは、ビジネス、人材、ガバナンス、プラットフォーム、セキュリティ、オペレーションです。この中にある名前を選択肢から探すと、ガバナンスだけが該当します。
コスト最適化、パフォーマンス効率、信頼性は、いずれもAWS Well-Architected Frameworkの柱の名前です。システムの性質を表す言葉で、組織の体制を整理するAWS CAFの観点ではありません。
「組織の準備ならAWS CAF、システム設計の評価ならWell-Architected」と役割で覚え、それぞれ6つの名前を言えるようにしておくと、名前を入れ替えた出題にも対応できます。
参考資料：基本的な機能 – AWS クラウド導入フレームワークの概要、ガバナンスのパースペクティブ: 統制と監視 – AWS クラウド導入フレームワークの概要、AWS クラウド導入フレームワーク、フレームワークの柱 – AWS Well-Architected フレームワーク
問題3複数選択
ある企業が、自社で運用しているサーバー群をAWSへ移すことで費用を抑えられるかどうかを検討しています。AWSクラウドを利用することで費用が下がる理由として正しいものはどれですか。（2つ選択してください）
- どのリージョンでも同じ料金でサービスを利用できます
- 必要な処理能力を需要に応じて増減できます
- オンデマンドで長期間使い続けたインスタンスが自動的に割引の対象になります
- AWSからインターネットへ送信するデータの転送には料金がかかりません
- 自社でデータセンターを構築・維持する費用が不要になります
解答と解説を見る
正解：回答 2・5
回答 1 不正解 AWSの料金は、サービスごとにリージョン単位で定められています。各リージョンは土地代や電気代、税金といった現地の条件のもとで運用されているため、同じサービスでもリージョンによって料金は異なります。費用を抑えたいときは、要件を満たす範囲でリージョンの料金差を比べて選びます。
回答 2 正解 AWSでは、サーバーの台数や性能を需要に合わせて増やしたり減らしたりできます。自社設備のように将来のピークを見込んで機器を先に買う必要がなく、使わない時間帯はリソースを止めて料金の発生を抑えられます。この「キャパシティの推測が不要になる」という点が、クラウドで費用が下がる代表的な理由です。
回答 3 不正解 オンデマンドインスタンスは、使った時間に応じて定価で請求される購入方法です。長く使い続けても自動で単価が下がることはなく、割引を受けるにはSavings Plansやリザーブドインスタンスのように、1年または3年の利用を事前に約束する必要があります。オンデマンドは、利用期間が読めない短期の作業に向いた選び方です。
回答 4 不正解 データ転送料金は、AWSの内外を移動するデータ量に応じて発生する料金です。インターネットからAWSへ受信する通信は原則無料ですが、AWSからインターネットへ送信する通信は、月ごとの無料分を超えると送信量に応じて課金されます。転送料金は、大量のデータを外へ送るシステムで特に注意する項目です。
回答 5 正解 自社でサーバーを運用するには、建物や電源、空調、ネットワーク機器の購入と保守、それらを管理する人員の費用がかかります。AWSではこれらの設備をAWSが用意して運用するため、利用者はサービスの利用料を払うだけで済みます。「データセンターの運用と保守にコストを費やす必要がなくなる」ことは、クラウドの利点の1つです。
問われている要件
- AWSクラウドで費用が下がる本当の理由を、クラウドの利点として知っていること
- 需要に応じたキャパシティの増減と、データセンター設備の費用の削減を理解していること
- AWSの料金についてよくある誤解（全リージョン同一料金、送信データが無料、自動割引）を見分けること
前提知識
クラウドコンピューティングの6つの利点
- AWSはクラウドの利点として、固定費が変動費に置き換わる、大幅なスケールメリット、キャパシティの推測が不要になる、スピードと俊敏性の向上、データセンターの運用と保守にコストを費やす必要がなくなる、数分でグローバル展開できる、の6つを挙げています。
- 賃貸オフィスに例えると、自社ビルを建てる代わりに必要な広さの部屋を必要な期間だけ借りるのがクラウドで、建物の建設費や設備の点検費はビルのオーナーであるAWSが持ちます。
費用が下がる2つの仕組み
- 需要に応じた増減は、ピークに合わせて機器を先に買っておく必要をなくします。使わない時間帯はリソースを止めれば料金は発生しません。
- データセンター費用の削減は、建物・電源・空調・機器の購入と保守、管理する人員といった固定費をなくします。
図による解説
解くための考え方
問題文の「AWSクラウドを利用することで費用が下がる理由」という言葉に注目します。問われているのは、AWSが公式に挙げているクラウドの利点のうち、費用に関わるものです。
費用に関わる利点は、需要に応じてキャパシティを増減できることと、データセンターの設備や保守にお金をかけなくてよくなることの2つで、この2つが正解になります。
残りの3つは、AWSの料金の仕組みと合いません。料金はリージョンごとに異なり、オンデマンドの単価は長く使っても自動では下がらず、インターネットへの送信データは無料分を超えると課金されます。
「需要に合わせて増減」「データセンターの費用をなくす」はクラウドの利点、「全リージョン同じ料金」「送信が無料」「自動で割引」は料金の誤解、と対応づけて判断します。
参考資料：クラウドコンピューティングの 6 つの利点 – Amazon Web Services の概要、主要な原則 – AWS 料金体系の仕組み、オンデマンドインスタンス – Amazon EC2 の料金、COST07-BP02 コストに基づいてリージョンを選択する – コスト最適化の柱
問題4単一選択
ある企業の運用チームが、AWS上のシステムの運用方針を見直すにあたり、AWS Well-Architected Frameworkの設計原則を参考にすることにしました。次のうち、このフレームワークで推奨されている設計原則はどれですか。
- 変更はまとめて大きな単位にし、実施する回数を減らします
- インフラの構築手順は文書化し、担当者が手順どおりに手作業で設定します
- 運用上の失敗が起きたら、そこから学んで改善につなげます
- アーキテクチャは最初に決めた設計を固定し、後から変えません
解答と解説を見る
正解：回答 3
回答 1 不正解 変更をまとめて大きな単位で、回数を絞って行う考え方です。AWS Well-Architected Frameworkの運用上の優秀性の柱では「小規模かつ可逆的な変更を頻繁に行う」ことを勧めています。大きな変更は影響範囲が広く、問題が出たときに原因の特定と切り戻しが難しくなります。小さな変更を頻繁に行うのは、失敗しても素早く戻せる状態を保つためです。
回答 2 不正解 手順書を整えたうえで、人がその手順を手作業で実行する考え方です。運用上の優秀性の柱では「可能な場合は安全に自動化する」ことを勧めており、構築や変更の手順はコードにして自動で実行します。手順書があっても手作業では担当者によって結果が変わり、同じ環境を再現できません。自動化は、人によるミスをなくし、同じ環境を何度でも作れるようにするために行います。
回答 3 正解 「運用上のイベントとメトリクスから学ぶ」は、AWS Well-Architected Frameworkの運用上の優秀性の柱に含まれる設計原則で、障害から学ぶことを求めています。障害や運用上の失敗が起きたときに、その原因と対応を振り返って手順や仕組みを改善し、同じ失敗を繰り返さないようにします。失敗を改善のための情報として活かす姿勢が求められています。
回答 4 不正解 最初に決めた設計を固定して変えない考え方です。AWS Well-Architected Frameworkの一般的な設計原則には「発展するアーキテクチャを検討する」があり、ビジネスの変化に合わせて構成を継続的に見直すことを勧めています。クラウドでは自動化とテストによって構成を安全に変えられるため、設計を固定する理由がありません。
問われている要件
- AWS Well-Architected Frameworkの運用上の優秀性の柱にある設計原則を知っていること
- 変更・構築・設計に関するオンプレミス時代の慣習と、クラウドの設計原則を区別すること
- 障害や失敗を改善の材料にするという考え方を理解していること
前提知識
AWS Well-Architected Frameworkとは
- AWS上でシステムを設計・運用するための考え方をAWSがまとめたガイドラインで、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の6つの柱からなります。
- ビルの定期点検の項目表にあたるもので、設計や運用の方針が項目から外れていないかを確認するために使います。
運用上の優秀性の柱の設計原則
- 運用上の優秀性の柱の設計原則には、可能な場合は安全に自動化する、小規模かつ可逆的な変更を頻繁に行う、オペレーション手順を頻繁に改善する、障害を予測する、運用上のイベントとメトリクスから学ぶ、マネージドサービスを使用する、などがあります。
- 「運用上のイベントとメトリクスから学ぶ」は、障害や失敗が起きたときに原因と対応を振り返り、手順や仕組みの改善につなげる考え方です。柱ごとの資料では「運用上の障害すべてから学ぶ」とも書かれています。
一般的な設計原則との関係
- 柱ごとの原則とは別に、フレームワーク全体に共通する一般的な設計原則があり、「発展するアーキテクチャを検討する」「容量ニーズの推測が不要」などが含まれます。設計を固定する考え方はこの原則と逆です。
図による解説
解くための考え方
問題文の「AWS Well-Architected Frameworkで推奨されている設計原則」という言葉に注目します。問われているのは、クラウドでの運用の考え方として公式に挙げられているものはどれか、という点です。
選択肢を「クラウドの特徴を活かした考え方か、変更や自動化を避ける考え方か」という観点で見ます。変更をまとめて大きくする、手作業で構築する、設計を固定する、の3つは、いずれも変更を減らしたり自動化を避けたりする方向で、小さな変更を頻繁に行う、可能な場合は安全に自動化する、発展するアーキテクチャを検討する、という原則と逆です。
運用上の失敗から学んで改善につなげる、という内容だけが、運用上の優秀性の柱に書かれている「運用上のイベントとメトリクスから学ぶ」に一致します。
「小さく頻繁に」「安全に自動化」「失敗から学ぶ」「発展させる」が出てきたら推奨側、「大きくまとめて」「手作業で」「固定して変えない」が出てきたら避けるべき側、と対応づけて判断すると、言い回しを変えた出題にも対応できます。
参考資料：設計原則 – 運用上の優秀性の柱、設計原則 – AWS Well-Architected フレームワーク、一般的な設計原則 – AWS Well-Architected フレームワーク、フレームワークの柱 – AWS Well-Architected フレームワーク
問題5複数選択
ある企業が、自社の設備で運用しているシステムをAWSクラウドへ移行するべきかを社内で検討しています。移行によって得られる利点として正しいものはどれですか。（2つ選択してください）
- セキュリティ対策の大半をAWSが実施するため、利用者側の設定が不要になります
- 使った分だけ支払う従量課金を利用できます
- AWSのデータセンター内での物理サーバーの配置や交換の時期を利用者が指定できます
- 必要になるキャパシティを事前に推測しなくて済みます
- 変動していた費用を固定費に置き換えられます
解答と解説を見る
正解：回答 2・4
回答 1 不正解 AWSのセキュリティは、AWSと利用者が範囲を分けて担う責任共有モデルで成り立っています。AWSが担うのは設備やハードウェア、仮想化基盤といった「クラウド自体」の保護で、データの暗号化やアクセス権の設定、ゲストOSの管理といった「クラウド内」の保護は利用者が設定します。責任共有モデルは、利用者側の設定がどこまで残るかを確認するために使う考え方です。
回答 2 正解 AWSでは、利用したサービスの量や時間に応じて料金を払う従量課金が基本です。自社設備のように、使うかどうか分からないうちに機器へ多額の先行投資をする必要がなく、固定費が変動費に置き換わります。使わないリソースを止めれば料金も止まり、費用を実際の利用に合わせられます。
回答 3 不正解 AWSのデータセンターの建物や物理サーバー、ネットワーク機器といった設備は、AWSが所有して管理します。利用者はその中で物理サーバーをどこに置くか、いつ交換するかを決めることはできず、サービスを通じて仮想的なリソースを操作します。物理設備の管理から解放されることが、クラウドへ移る理由の1つです。
回答 4 正解 自社設備では、システムを動かす前に将来の需要を見積もって機器を用意する必要があり、多すぎれば無駄に、少なすぎれば不足になります。AWSでは必要な分のキャパシティを必要なときに確保し、数分で増減できるため、事前の推測が不要になります。これは「クラウドコンピューティングの6つの利点」の1つです。
回答 5 不正解 固定費は使用量に関係なく毎月同じ額がかかる費用で、変動費は使った量に応じて増減する費用です。自社設備では機器の購入費や保守費が固定費になりますが、AWSでは使った分に応じた変動費になります。クラウドの利点として挙げられているのは「固定費が変動費に置き換わる」ことで、この選択肢はその逆です。
問われている要件
- AWSが挙げる「クラウドコンピューティングの6つの利点」を知っていること
- 従量課金とキャパシティ推測の不要をクラウドの利点として理解していること
- セキュリティや物理設備の責任がどちらにあるかを区別すること
前提知識
クラウドコンピューティングの6つの利点
- AWSはクラウドの利点として、固定費が変動費に置き換わる、大幅なスケールメリット、キャパシティの推測が不要になる、スピードと俊敏性の向上、データセンターの運用と保守にコストを費やす必要がなくなる、数分でグローバル展開できる、の6つを挙げています。
- 自社ビルを建てて設備を全部そろえるのが自社設備で、必要な広さの部屋を必要な期間だけ借りるのがクラウドです。
従量課金とキャパシティの推測
- 従量課金は、使ったサービスの量や時間に応じて支払う仕組みで、機器への先行投資が要らないため固定費が変動費に置き換わります。
- キャパシティの推測が不要になるとは、需要を事前に見積もって機器を用意しなくてよいということです。
責任共有モデルと物理設備
- セキュリティは責任共有モデルでAWSと利用者が分担し、データセンターの建物や物理サーバーはAWSが所有して管理します。利用者は物理設備に直接触れることなく、仮想的なリソースを操作します。
図による解説
解くための考え方
問題文の「移行によって得られる利点」という言葉に注目します。問われているのは、AWSが公式に挙げているクラウドの利点に当てはまるものです。
従量課金と、キャパシティを事前に推測しなくてよいことは、「固定費が変動費に置き換わる」「キャパシティの推測が不要になる」という利点に対応し、この2つが正解になります。
残りの3つは、利点に見えて内容が事実と違います。セキュリティは責任共有モデルで利用者側の設定が残り、物理設備はAWSが管理するので利用者は設置や交換を決められません。費用は固定費から変動費へ変わるのであって、変動費を固定費にするのは逆です。
「使った分だけ」「推測が不要」「固定費を変動費に」はクラウドの利点、「利用者側の設定が不要」「物理設備を利用者が指定」「変動費を固定費に」は責任共有や利点の取り違え、と対応づけて判断します。
参考資料：クラウドコンピューティングの 6 つの利点 – Amazon Web Services の概要、責任共有モデル – Amazon Web Services (AWS)、主要な原則 – AWS 料金体系の仕組み、AWS 製品およびサービス料金
問題6単一選択
ある企業が、AWS上で動かすWebシステムを複数のアベイラビリティーゾーンにまたがる構成にしました。一部のサーバーやゾーンに障害が起きても、業務への影響を小さくできます。この設計が示しているAWSクラウドの利点はどれですか。
- 俊敏性
- 耐久性
- スケーラビリティ
- 高可用性
解答と解説を見る
正解：回答 4
回答 1 不正解 俊敏性は、新しいITリソースを数分で用意でき、試したり作り直したりする速さが上がることを指す利点です。障害が起きたときにサービスが止まらないかどうかとは関係がなく、開発や実験のスピードを表す言葉です。新しいアイデアをすぐ試せる、開発期間を短くできる、という文脈で使います。
回答 2 不正解 耐久性は、保存したデータが失われたり壊れたりせずに残り続ける性質を指す言葉です。Amazon S3のイレブンナインのように、データを守る強さを表すものであり、システムが停止せずに動き続けるかどうかを表す言葉ではありません。データを長期間安全に保管したいときに注目する性質です。
回答 3 不正解 スケーラビリティは、利用者や処理量が増えたときにサーバーの台数や性能を増やして対応できる性質です。負荷の増減に合わせて規模を変える話であり、障害が起きても止まらないという話ではありません。アクセス数の伸びに合わせて構成を大きくできるかを考えるときに使います。
回答 4 正解 高可用性は、サーバーやアベイラビリティーゾーンの一部に障害が起きても、システム全体としては停止時間を最小限に抑えて動き続けられる性質です。問題文の「障害が起きても業務への影響を小さくできる」という設計は、この性質を実現する構成です。複数のアベイラビリティーゾーンに分散する構成が代表的な実現方法です。
問われている要件
- 障害が起きても停止時間を最小限にしてサービスを続けられる性質を表す言葉を選ぶこと
- 高可用性・スケーラビリティ・俊敏性・耐久性という似た言葉を区別すること
- 複数のアベイラビリティーゾーンを使う構成がどの利点に結びつくかを知っていること
前提知識
高可用性とは
- 高可用性（High Availability）は、システムが使える状態にある時間の割合を高く保つことです。一部の機器やゾーンが壊れても別の機器が処理を引き継ぎ、利用者から見た停止時間を最小限に抑えます。
- AWSでは、リージョンの中にある複数のアベイラビリティーゾーン（AZ、電源や回線が独立したデータセンター群）にサーバーを分けて置き、Elastic Load Balancingで正常なサーバーへだけ通信を振り分けることで実現します。
- 賃貸オフィスに例えると、AZは同じ都市内の離れた場所にある別々のビルで、1棟が停電しても別のビルの部屋で業務を続けられる関係です。
似た言葉との違い
- スケーラビリティは、負荷の増減に合わせてサーバーの台数や性能を増減できる性質です。処理量が増えたときの話であり、障害への強さとは別の観点です。
- 俊敏性は、新しいリソースを数分で用意できることで、開発や実験のスピードが上がるという利点です。AWSが公式に挙げる「クラウドコンピューティングの6つの利点」の1つです。
- 耐久性は、保存したデータが失われずに保たれる性質です。可用性が「今すぐ使えるか」を表すのに対し、耐久性は「データが傷まず残っているか」を表します。
図による解説
解くための考え方
問題文の「複数のアベイラビリティーゾーンにまたがる」「障害が起きても」「業務への影響を小さく」という言葉に注目します。問われているのは、負荷への対応でも開発の速さでもなく、障害に対してシステムが止まらないという性質です。
障害が起きても止まらない、使える時間の割合が高い、という性質を表す言葉が高可用性です。複数のアベイラビリティーゾーンにまたがる構成は、高可用性を実現する代表的な方法なので、問題文の設計と結びつきます。
スケーラビリティは「アクセスが増えたら台数を増やす」という負荷の話、俊敏性は「数分でリソースを用意して素早く試せる」という速さの話で、どちらも障害の話ではありません。耐久性は「データが失われない」という話で、システムが動き続けるかどうかとは別の性質です。
「障害・停止時間・動き続ける」と読めたら高可用性、「負荷・台数を増やす」ならスケーラビリティ、「素早く試す・数分で用意」なら俊敏性、「データが失われない」なら耐久性、という対応で判断します。
参考資料：可用性 – 信頼性の柱、グローバルインフラストラクチャ – Amazon Web Services の概要、クラウドコンピューティングの 6 つの利点 – Amazon Web Services の概要、Elastic Load Balancing とは? – Elastic Load Balancing、Amazon S3 におけるデータ保護 – Amazon Simple Storage Service
問題7単一選択
ある企業が、クラウド導入に向けた組織の準備状況をAWS Cloud Adoption Framework（AWS CAF）に沿って点検しています。AWS CAFは必要な機能を6つのパースペクティブに分けて整理していますが、このうち人材（People）パースペクティブに含まれる機能はどれですか。
- クラウドの財務管理
- 変更およびリリース管理
- クラウドフルエンシー
- 戦略的パートナーシップ
解答と解説を見る
正解：回答 3
回答 1 不正解 クラウドの財務管理は、クラウドの利用料金を計画・測定・最適化し、費用に対する説明責任を果たせるようにする機能です。組織の統制と監視を扱うガバナンスパースペクティブに属し、社員の文化やスキルを扱う人材パースペクティブの機能ではありません。予算の管理や部門ごとの費用配分を整えるときに使う考え方です。
回答 2 不正解 変更およびリリース管理は、本番環境へのリスクを抑えながらシステムの変更や新しいリリースを導入する機能です。システムの正常性と可用性を扱うオペレーションパースペクティブに属し、人材パースペクティブの「変革の促進」とは名前が似ていても対象が違います。CI/CDで小さな変更を頻繁に安全にリリースしたいときに関わる考え方です。
回答 3 正解 クラウドフルエンシーは、社員がクラウドを自信を持って効果的に使いこなし、ビジネスの成果を加速できるデジタル能力を高める機能です。人材パースペクティブは文化の進化、トランスフォーメーションのリーダーシップ、ワークフォースのトランスフォーメーション、変革の促進、組織設計、組織の連携とともにこの機能を含み、組織の人と文化の側面を扱います。
回答 4 不正解 戦略的パートナーシップは、クラウドプロバイダーと提携してソリューションの提供や顧客との関係を広げ、ビジネスを創出・拡大する機能です。経営戦略と成果を扱うビジネスパースペクティブに属し、社員のスキルや組織文化を扱う人材パースペクティブの機能ではありません。クラウド関連の製品やサービスを事業として伸ばしたいときに関わる考え方です。
問われている要件
- AWS CAFの6つのパースペクティブの名前と、それぞれが扱う範囲を知っていること
- 人材（People）パースペクティブがどのような機能を含むかを知っていること
- 似た名前の機能が別のパースペクティブに属することを区別すること
前提知識
AWS Cloud Adoption Framework（AWS CAF）とは
- AWS CAFは、企業がクラウドを導入するときに組織として何を整えるべきかをまとめた枠組みです。必要な機能をビジネス、人材、ガバナンス、プラットフォーム、セキュリティ、オペレーションの6つのパースペクティブ（観点）に分けて整理しています。
- 会社の部門に置き換えると、ビジネスは経営企画、人材は人事、ガバナンスは経営管理や監査、プラットフォームは情報システム、セキュリティは情報セキュリティ、オペレーションは運用部門にあたります。
人材（People）パースペクティブとは
- クラウド導入を「技術の話」ではなく「人と文化の変革」としてとらえる観点です。公式の日本語ドキュメントでは「人員のパースペクティブ」と表記されています。
- 含まれる機能は、文化の進化、トランスフォーメーションのリーダーシップ、クラウドフルエンシー、ワークフォースのトランスフォーメーション、変革の促進、組織設計、組織の連携の7つで、クラウドフルエンシーは試験で最もよく問われる名前です。
他のパースペクティブに属する機能
- ガバナンスはクラウドの財務管理やリスク管理など組織の統制を、オペレーションは変更およびリリース管理やインシデント管理などシステムの安定運用を、ビジネスは戦略的パートナーシップやポートフォリオ管理など事業の成果を扱います。
解くための考え方
問題文の「AWS CAF」「6つのパースペクティブ」「人材（People）パースペクティブ」という言葉に注目します。問われているのは、人材パースペクティブという「人と文化」を扱う観点に、どの機能が属するかです。
人材パースペクティブの機能は、文化の進化、トランスフォーメーションのリーダーシップ、クラウドフルエンシー、ワークフォースのトランスフォーメーション、変革の促進、組織設計、組織の連携です。選択肢の中でこの一覧にあるのはクラウドフルエンシーだけで、社員のクラウドスキルを育てるという内容も「人」の観点に合っています。
クラウドの財務管理は費用を統制するガバナンスの機能、変更およびリリース管理はシステムを安定して動かすオペレーションの機能、戦略的パートナーシップは事業を伸ばすビジネスの機能で、いずれも人や文化ではなく、費用・運用・経営を対象にしています。
「人・スキル・文化・リーダーシップ」に関わる名前なら人材パースペクティブ、「統制・財務・リスク」ならガバナンス、「運用・変更・インシデント」ならオペレーション、「戦略・提携・事業」ならビジネス、という対応で見分けます。
参考資料：人員のパースペクティブ: 文化と変革 – AWS クラウド導入フレームワークの概要、ガバナンスのパースペクティブ: 統制と監視 – AWS クラウド導入フレームワークの概要、オペレーションのパースペクティブ: 正常性と可用性 – AWS クラウド導入フレームワークの概要、ビジネスのパースペクティブ: 戦略と成果 – AWS クラウド導入フレームワークの概要、AWS クラウド導入フレームワーク
問題8複数選択
ある企業が、クラウドの利点としてよく挙げられる「俊敏性」という言葉の意味を社内で整理しています。AWSクラウドにおける俊敏性の説明として正しいものはどれですか。（2つ選択してください）
- 必要なITリソースを数分で用意して、すぐ使い始められることです
- 使った分だけ支払う従量課金によって、固定費を変動費に変えられることです
- 新しいアイデアをすぐ試し、うまくいかなければ短時間で作り直せることです
- 使われずに余っていたサーバーの容量を、需要に合わせてなくせることです
- 世界中のリージョンへすぐシステムを展開し、利用者の近くで動かせることです
解答と解説を見る
正解：回答 1・3
回答 1 正解 俊敏性の中心は、サーバーやストレージなどのリソースを数週間ではなく数分で調達できることです。物理的な機器の発注や設置を待たずに開発を始められるため、アイデアを形にするまでの時間が大幅に短くなります。AWSが公式に説明する俊敏性の定義そのものです。
回答 2 不正解 従量課金は、事前に設備へ投資する代わりに使った分だけ料金を払う仕組みです。これは「固定費が変動費に置き換わる」という費用面の利点であり、素早く試せるという俊敏性の説明ではありません。初期投資を抑えたい、費用を利用量に連動させたい、という文脈で使う言葉です。
回答 3 正解 俊敏性のもう1つの側面は、実験のしやすさです。リソースをすぐ用意してすぐ手放せるため、試作を作って検証し、うまくいかなければ捨ててやり直す、という繰り返しを低いコストと短い時間で行えます。実験や開発にかかる時間と費用が減ることで組織の俊敏性が高まる、とAWSは説明しています。
回答 4 不正解 余った容量をなくすことは、需要に合わせてリソースを増減する弾力性や、キャパシティの推測が不要になるという利点の説明です。無駄な設備を持たなくて済むという資源の効率の話であり、開発や実験の速さを表す俊敏性とは観点が違います。需要の変動に合わせて台数を増減する文脈で使う言葉です。
回答 5 不正解 世界各地のリージョンへ短時間でシステムを配置できることは、公式の6つの利点では「数分でグローバル展開できる」として俊敏性とは別に数えられている利点です。利用者に近い場所で動かして応答を速くする地理的な広がりの話であり、アイデアをすぐ試せるという俊敏性の説明ではありません。海外の利用者向けにサービスを広げる文脈で使う言葉です。
問われている要件
- クラウドの利点としての「俊敏性」が何を指すかを知っていること
- 俊敏性を、従量課金・弾力性・グローバル展開といった他の利点と区別すること
- 俊敏性の2つの側面（リソース調達の速さ、実験のしやすさ）を両方選ぶこと
前提知識
クラウドコンピューティングの6つの利点
- AWSは、クラウドの利点として「固定費が変動費に置き換わる」「大幅なスケールメリットが得られる」「キャパシティの推測が不要になる」「スピードと俊敏性が向上する」「データセンターの運用と保守にコストを費やす必要がなくなる」「数分でグローバル展開できる」の6つを挙げています。
- 試験では、この6つのうちどれを説明した文なのかを見分ける形で出題されます。似た言葉が別の利点を指していることが多いので、それぞれの中心となる内容を押さえておく必要があります。
俊敏性とは
- 俊敏性（アジリティ）は、新しいITリソースをクリック1つで数分のうちに利用でき、開発者がリソースを待つ時間が数週間から数分に縮まることです。その結果、実験や開発にかかるコストと時間が減り、新しいアイデアをすぐ試して、合わなければすぐやり直せるようになります。
- 賃貸オフィスに例えると、必要になったその日に部屋を借りて仕事を始め、合わなければ翌日には解約できる身軽さが俊敏性です。
似た利点との違い
- 従量課金は「使った分だけ払う」という費用の話、弾力性やキャパシティ推測の不要は「余った容量を持たなくて済む」という資源の話、グローバル展開は「世界中のリージョンへ数分で配置できる」という場所の話です。いずれもクラウドの利点ですが、俊敏性が指す「速く試せること」とは別の観点です。
解くための考え方
問題文の「俊敏性の説明として正しいもの」という言葉に注目します。問われているのは俊敏性という1つの利点の中身であり、クラウドの利点全般ではありません。
俊敏性は「リソースを数分で調達できる速さ」と「その速さのおかげで実験や試行錯誤を低コストで繰り返せること」の2つの側面から説明されます。必要なITリソースを数分で用意できるという選択肢と、アイデアをすぐ試して短時間で作り直せるという選択肢が、この2つにそれぞれ対応します。
従量課金で固定費を変動費に変えるという選択肢は費用面の利点、余った容量をなくすという選択肢は弾力性やキャパシティ推測の不要という資源面の利点、世界中のリージョンへすぐ展開するという選択肢はグローバル展開の利点で、どれも正しいクラウドの利点ですが俊敏性の説明ではありません。
「数分で用意」「すぐ試す」「やり直す」と読めたら俊敏性、「使った分だけ払う」なら従量課金、「余った容量」なら弾力性、「世界中のリージョン」ならグローバル展開、という対応で見分けます。
参考資料：クラウドコンピューティングの 6 つの利点 – Amazon Web Services の概要、クラウドとは – クラウドコンピューティングのサービス、利点、タイプ – AWS、AWS 製品およびサービス料金、グローバルインフラストラクチャ – AWS
問題9単一選択
ある企業が、オンプレミスの1つの大きなアプリケーションをAWSへ移行します。移行にあわせて機能ごとに独立した小さなサービスへ分割し、サービス間はキューを介してやり取りする構成に変える方針です。この方針が従っているAWS Well-Architected Frameworkのベストプラクティスはどれですか。
- デプロイの手順の中に機能テストを組み込みます
- 変更の反映を自動化された仕組みで行います
- 需要に合わせてリソースを自動的に増減させます
- 構成要素の間の依存関係を疎結合にします
解答と解説を見る
正解：回答 4
回答 1 不正解 デプロイの一部として機能テストを統合することは、変更を本番へ反映する前に動作を確かめて失敗を早く見つけるためのベストプラクティスです。テストのやり方に関する内容であり、アプリケーションを小さなサービスへ分割してつなぎ方を変えるという構造の話ではありません。変更を安全にリリースする手順を整えるときに当てはまります。
回答 2 不正解 自動化を使って変更をデプロイすることは、人手の作業による誤りを減らし、同じ手順を繰り返し再現できるようにするためのベストプラクティスです。リリース作業の進め方に関する内容であり、サービス同士の結びつきを弱めるという設計の話ではありません。デプロイを頻繁かつ安全に行いたいときに当てはまります。
回答 3 不正解 需要の変化を検出してリソースを自動的に取得・解放することは、負荷の増減に追従してシステムを止めないためのベストプラクティスです。台数や性能の調整に関する内容であり、機能を分割してキューでつなぐという構造の変更を指すものではありません。アクセスの波が大きいシステムで容量を確保するときに当てはまります。
回答 4 正解 疎結合の依存関係を実装することは、信頼性の柱に含まれるベストプラクティスです。1つの大きなアプリケーションを独立した小さなサービスに分割し、Amazon SQSのようなキューを間に置いて直接の依存をなくすことで、一部の障害が全体へ広がらず、各サービスを別々に変更・拡張できるようになります。問題文の方針はこの考え方そのものです。
問われている要件
- 1つの大きなアプリケーションを小さなサービスに分割し、キューでつなぐ方針がどのベストプラクティスに当たるかを知っていること
- 「疎結合」という言葉が構成要素同士の依存を弱める設計を指すことを理解していること
- テスト・自動化・スケーリングといった別のベストプラクティスと区別すること
前提知識
AWS Well-Architected Frameworkとは
- AWS上に作るシステムの設計を、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の6つの柱で評価する枠組みです。柱ごとに、守るとよい具体的なベストプラクティスが列挙されています。
- ビルの定期点検の項目表にあたり、設計のどこを見直せばよいかを一覧にしたものです。
疎結合の依存関係とは
- 疎結合とは、構成要素同士が互いの中身や状態に直接依存せず、決められた窓口だけを通してやり取りする設計です。信頼性の柱に「疎結合の依存関係を実装する」というベストプラクティスとして挙げられています。
- 1つの大きなアプリケーション（モノリス）を機能ごとの小さなサービス（マイクロサービス）に分け、間をAmazon SQS（Simple Queue Service、メッセージを一時的に預かるキュー）でつなぐのが典型です。受け取る側が一時的に止まっても送る側は処理を続けられ、障害の影響範囲が小さくなります。
似たベストプラクティスとの違い
- 機能テストの統合と自動化によるデプロイは「変更をどう実装するか」というリリース手順の話、需要に応じたリソースの自動取得は「需要の変化にどう対応するか」という容量の話で、いずれも構成要素のつなぎ方を変えるものではありません。
図による解説
解くための考え方
問題文の「1つの大きなアプリケーション」「機能ごとに独立した小さなサービスへ分割」「キューを介してやり取り」という言葉に注目します。問われているのは、構成要素の分け方とつなぎ方に関する設計の方針です。
モノリスをマイクロサービスに分け、間にキューを置いて直接の依存をなくす設計は、Well-Architected Frameworkの信頼性の柱にある「疎結合の依存関係を実装する」というベストプラクティスに対応します。
機能テストの統合と変更の自動デプロイは、いずれもリリース手順に関するベストプラクティスで、構成の分割とは関係がありません。需要に合わせたリソースの自動増減は容量に関するベストプラクティスで、こちらもサービスの分け方やつなぎ方の話ではありません。
「分割」「独立」「キュー」「直接依存しない」と読めたら疎結合、「テスト」「自動デプロイ」なら変更の実装、「需要」「自動的に増減」ならスケーリング、という対応で見分けます。
参考資料：REL04-BP02 疎結合の依存関係を実装する – 信頼性の柱、REL 4. 障害を防ぐために、分散システムの操作をどのように設計しますか?、REL 8. どのように変更を実装するのですか?、Amazon Simple Queue Service とは? – Amazon Simple Queue Service
問題10単一選択
ある企業が、AWS上のシステムや資産に対するリスクを評価し、対策を講じる取り組みを進めています。この取り組みが目標としている内容を扱うAWS Well-Architected Frameworkの柱はどれですか。
- 信頼性
- セキュリティ
- 運用上の優秀性
- 持続可能性
解答と解説を見る
正解：回答 2
回答 1 不正解 信頼性は、システムが期待どおりの機能を実行し、障害が起きても素早く回復して動き続けられるようにするための柱です。扱うのは可用性や復旧の速さであり、データを不正なアクセスから守ることやアクセス権の管理は対象ではありません。複数のアベイラビリティーゾーンへの分散やバックアップからの復旧を検討するときに使う観点です。
回答 2 正解 セキュリティは、データ、システム、資産を保護し、クラウドの技術を活用してセキュリティを強化する能力に焦点を当てた柱です。データの機密性と完全性の確保、ユーザー権限の管理、セキュリティイベントの検出と対応などが主な内容で、システムや資産へのリスクを評価して対策を講じる取り組みは、この柱が扱う内容に当たります。
回答 3 不正解 運用上の優秀性は、システムを日々動かして監視し、手順やプロセスを継続的に改善していくための柱です。運用の進め方や変更の管理が対象であり、データの機密性やアクセス権を守るという目標を直接扱うものではありません。運用手順をコード化したり、小さな変更を頻繁に行ったりするときに使う観点です。
回答 4 不正解 持続可能性は、クラウド上でシステムを動かすことによる環境への影響を最小限に抑えるための柱です。エネルギーや資源の使い方が対象であり、データやシステムを脅威から守るという目標とは無関係です。使っていないリソースを減らしたり、効率のよいリージョンやインスタンスを選んだりするときに使う観点です。
問われている要件
- 「システムや資産に対するリスクの評価と対策」がどの柱の内容かを知っていること
- AWS Well-Architected Frameworkの6つの柱の名前と、それぞれが扱う範囲を区別すること
- 似た言葉に見える信頼性と運用上の優秀性を、セキュリティと取り違えないこと
前提知識
AWS Well-Architected Frameworkとは
- AWS上に作るシステムの設計を評価するための枠組みで、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の6つの柱で構成されています。
- 自動車の定期点検の項目表のように、設計を見直すときの観点を一覧にしたものです。柱ごとに設計原則とベストプラクティスがまとめられています。
セキュリティの柱とは
- データ、システム、資産を保護し、クラウドの技術を活用してセキュリティを強化する能力に焦点を当てた柱です。主なトピックは、データの機密性と完全性、ユーザー権限の管理、セキュリティイベントの検出と対応です。
- リスクを評価して対策を講じ、アクセスを制御し、セキュリティイベントに自動的に対応できるアーキテクチャを作ることを目指します。
他の柱が扱う範囲
- 信頼性は「期待どおりに動き、障害から素早く回復すること」、運用上の優秀性は「システムの実行と監視、手順の継続的な改善」、持続可能性は「環境への影響を最小限に抑えること」を扱います。
- パフォーマンス効率は「リソースを効率よく使うこと」、コスト最適化は「不要な費用を避けること」を扱います。同じシステムでも、どの目標を語っているかで当てはまる柱が変わります。
図による解説
解くための考え方
問題文の「システムや資産に対するリスクを評価し、対策を講じる」という言葉に注目します。問われているのは、脅威からシステムや資産を守るという目標がどの柱に当たるかです。
データ、システム、資産を保護し、リスクの評価と緩和を行うことは、セキュリティの柱のホワイトペーパーで掲げられている内容です。機密性、完全性、アクセス権の管理、脅威への備えという言葉が出てきたら、セキュリティの柱と結びつけます。
信頼性は障害が起きても動き続けて回復することが目標で、守る対象は可用性です。運用上の優秀性は運用手順の改善が目標で、持続可能性は環境への影響を減らすことが目標です。いずれも「データを脅威から守る」という目標を扱っていません。
「機密性・完全性・アクセス管理・脅威」ならセキュリティ、「障害・回復・可用性」なら信頼性、「運用手順・監視・改善」なら運用上の優秀性、「環境・エネルギー」なら持続可能性、という対応で見分けます。
参考資料：セキュリティ – AWS Well-Architected フレームワーク、フレームワークの柱 – AWS Well-Architected フレームワーク、セキュリティの柱 – AWS Well-Architected フレームワーク、持続可能性の柱 – AWS Well Architected フレームワーク、AWS Well-Architected – 安全で効率的なクラウドアプリケーション
この問題を無料アプリで解く
同じ40問を、順番と選択肢をシャッフルして解けます。採点と正誤の記録、ブックマーク、途中で中断しての再開ができます。登録は不要で、記録はお使いの端末の中だけに保存されます。
他の分野の問題も解く
分野1が終わったら、出題割合の大きい分野2・分野3へ進むのが効率的です。
- 分野2 セキュリティとコンプライアンス 9問（出題割合30%）
- 分野3 クラウドテクノロジーとサービス 15問（出題割合34%）
- 分野4 請求、料金、サポート 6問（出題割合12%）
- 無料40問のトップページに戻る
この無料40問は、当サイトの有料講座（本番形式 65問×6セット）とは別に作った問題です。同じ問題は含まれていません。解説はAWS公式ドキュメントおよびCLF-C02試験ガイドの記載を基に作成しており、各問題の末尾に参考にした公式ドキュメントのリンクを載せています。AWSのサービス仕様は更新されることがあるため、受験前には公式ドキュメントもあわせてご確認ください。
本番形式の390問で仕上げる
無料40問で手応えがつかめたら、次は本番と同じ形式で時間を計って解く練習に進みます。CLF-C02は65問を90分で解く試験なので、通しで解く経験があるかどうかで当日の余裕が変わります。
【図解付き】AWS CLF-C02 クラウドプラクティショナー 本番同等模擬試験390問＋初学者向け解説
本番と同じ65問×6セット。全問に日本語の解説と図をつけ、不正解の選択肢についても1つずつ理由を書いています。この無料40問とは別の問題です。
当ブログ限定クーポン：通常 2,600円 → 1,500円
関連記事
以上です。
この記事がお役に立ちましたら、コーヒー1杯分（300円）の応援をいただけると嬉しいです。いただいた支援は、より良い記事作成のための時間確保や情報収集に活用させていただきます。