模擬問題集一覧

SOA-C03 模擬問題集（練習問題）

AWS SysOps Administrator – Associate 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

2 練習テスト 100 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

2 テスト · 全 100 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%

説明

SOA-C03（AWS SysOps Administrator – Associate）の合格に向けた、本番形式の模擬問題集です。全 100 問を2 回の練習テストに分割し、 試験モード／演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 100 問＋全解説が受け放題

模試プラン（¥980/月）なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

SOA-C03 の出題範囲（カバーしている分野）

全 100 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はSOA-C03 の学習ガイドにまとめています。

SOA-C03 の無料練習問題（15 問・解説つき）

会員登録なしで、全 100 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1この問題の原因は何ですか。モニタリング、ロギング、分析、修復、パフォーマンス最適化
問題
ある企業は、自社の AWS ワークロードに関連付けられたリソースに、ユーザー定義タグを適用しています。タグを適用してから 20 日後、その企業は AWS Cost Explorer コンソールでビューをフィルタリングするためにそのタグを使用できないことに気づきました。この問題の原因は何ですか。

選択肢と解説

  • 1
    Cost Explorer でビューをフィルタリングするためにタグを使用できるようになるまでには、少なくとも 30 日かかる。
  • ✓
    企業がコスト配分のためにユーザー定義タグを有効化していない。
  • 3
    企業が AWS Cost and Usage Report を作成していない。
  • 4
    企業が AWS Budgets で使用量予算を作成していない。

解説

【正解】B

【0からの解説】
AWS では、リソースに「タグ」を付けるだけでは、そのタグを使ってコストを内訳表示（フィルタリング/グループ化）することはできません。タグをコスト分析に使うには、請求コンソール（Billing and Cost Management）の「コスト配分タグ」画面で、対象のユーザー定義タグを明示的に「有効化（アクティブ化）」する必要があります。有効化すると、それ以降に発生したコストに対してそのタグが Cost Explorer や Cost and Usage Report のディメンションとして利用できるようになります。本問では 20 日経っても使えないのは、単にタグの「有効化」操作を行っていないためです。これが原因 B です。

【誤りの選択肢】
A：「30 日かかる」という仕様は存在しません。コスト配分タグを有効化すると、有効化後の使用分から（通常 24 時間程度で）反映されます。日数が原因ではなく、有効化していないことが原因です。
B はコスト配分タグの有効化が未実施という、まさに正しい原因を述べています。
C：Cost and Usage Report（CUR）はコストの詳細レポートですが、Cost Explorer でタグフィルターを使う前提条件は CUR の作成ではなく、コスト配分タグの有効化です。CUR の有無は本問の症状と無関係です。
D：AWS Budgets で予算を作成しても、Cost Explorer でタグをフィルターに使えるようにはなりません。予算機能とコスト配分タグの有効化は別物です。

【参考】
コスト配分タグの有効化（ユーザー定義タグ）
ユーザー定義のコスト配分タグの使用
この問題のページを開く →
問題 2最も少ない管理作業でこの要件を満たすソリューションはどれですか。ネットワークとコンテンツ配信
問題
ある企業の Web サイトは Amazon EC2 の Linux インスタンス上で稼働しています。この Web サイトは、Amazon S3 バケットから PDF ファイルを配信する必要があります。S3 バケットへのすべてのパブリックアクセスは、アカウントレベルでブロックされています。企業は、Web サイトの利用者が PDF ファイルをダウンロードできるようにする必要があります。最も少ない管理作業でこの要件を満たすソリューションはどれですか。

選択肢と解説

  • 1
    s3:list* と s3:get* の権限を許可するポリシーを持つ IAM ロールを作成する。そのロールを EC2 インスタンスに割り当てる。従業員を割り当てて、要求された PDF ファイルを EC2 インスタンスにダウンロードし、Web サイト利用者に配布させる。ローカルファイルを定期的に削除する AWS Lambda 関数を作成する。
  • ✓
    S3 バケットを指すオリジンアクセスコントロール（OAC）を使用する Amazon CloudFront ディストリビューションを作成する。CloudFront ディストリビューションからの接続を許可するバケットポリシーをバケットに適用する。利用者が PDF ファイルを要求したときに、ディストリビューション URL とオブジェクトパスを含むダウンロード URL を提供する。
  • 3
    ソース S3 バケットの S3 バケット許可を変更してパブリックアクセスを許可する。利用者が PDF ファイルを要求したときに従業員が PDF ファイルの URL を提供する。
  • 4
    IAM インスタンスプロファイルを持つ EC2 インスタンスをパブリックサブネットにデプロイする。EC2 インスタンスからの署名付き URL を使用して、Web サイト利用者に S3 バケットへの一時的なアクセスを提供する。

解説

【正解】B

【0からの解説】
アカウントレベルでパブリックアクセスがブロックされている S3 バケットの中身を、Web サイト利用者に配信したい場合の AWS 標準パターンが「CloudFront + オリジンアクセスコントロール（OAC）」です。CloudFront をバケットの前に置き、バケットポリシーで「この CloudFront ディストリビューションからのアクセスだけ許可する」と設定します。これにより、S3 のパブリックアクセスはブロックしたまま、利用者は CloudFront 経由でファイルをダウンロードできます。一度設定すれば運用は自動化され、サーバー（EC2）の管理も不要なので、管理作業が最も少なくなります。

【誤りの選択肢】
A：従業員が手作業で PDF を EC2 にダウンロードして利用者に配布する、という運用は管理作業が極めて大きく、自動化されていません。最少労力という要件に反します。
B はサーバーレスかつ AWS 推奨の構成で、パブリックアクセスブロックを維持したまま配信でき、管理作業が最小です。
C：パブリックアクセスを許可するのは要件（アカウントレベルでブロック）に明確に反しており、セキュリティ上も不適切です。
D：EC2 と署名付き URL の仕組みを自前で構築・運用する必要があり、サーバー管理・コードの保守が発生します。CloudFront + OAC に比べて管理作業が多くなります。

※補足：Most Voted は D ですが、D は EC2 サーバーの構築・運用が伴い管理作業が大きいのに対し、CloudFront + OAC（B）はパブリックアクセスブロックを維持しつつサーバーレスで配信でき、AWS が公式に推奨する「最少労力」の構成のため B を正解とします。

【参考】
CloudFront のオリジンアクセスコントロール（OAC）による S3 オリジンへのアクセス制限
Amazon S3 のブロックパブリックアクセス
この問題のページを開く →
問題 3この問題の原因として考えられるものはどれですか。信頼性と事業継続性
問題
ある CloudOps エンジニアが、コストを最適化するために Amazon RDS インスタンスの自動バックアップを無効化する必要があります。CloudOps エンジニアがバックアップを無効化しようとすると、保持期間は 1 から 35 の間でなければならないというエラーメッセージが表示されます。この問題の原因として考えられるものはどれですか。

選択肢と解説

  • 1
    RDS インスタンスにバックアップ保持期間を変更するための権限が不足している。
  • ✓
    RDS インスタンスにリードレプリカが構成されている。
  • 3
    RDS インスタンスがデフォルトのバックアップウィンドウを使用している。
  • 4
    RDS インスタンスがマルチ AZ デプロイの一部である。

解説

【正解】B

【0からの解説】
RDS の自動バックアップを無効化するには、バックアップ保持期間を「0」に設定します。しかし、その RDS インスタンスにリードレプリカ（読み取り用の複製）が存在する場合、レプリケーションはソース DB の自動バックアップ（バイナリログ）に依存しているため、保持期間を 0 にすることはできません。このとき「保持期間は 1〜35 の間でなければならない」というエラーが返されます。つまり、リードレプリカが構成されていることが原因です。リードレプリカをすべて削除すれば、保持期間を 0 にして自動バックアップを無効化できるようになります。

【誤りの選択肢】
A：権限不足の場合は「保持期間は 1〜35 でなければならない」という値の制約に関するエラーではなく、アクセス拒否（AccessDenied）系のエラーになります。エラーメッセージの内容と一致しません。
B はリードレプリカ存在時に保持期間 0 を拒否される RDS の仕様に一致し、正しい原因です。
C：バックアップウィンドウ（バックアップが実行される時間帯）はバックアップを無効化できるかどうかとは無関係で、このエラーの原因にはなりません。
D：マルチ AZ 構成自体は自動バックアップの無効化を妨げません。保持期間 0 を禁止する直接の原因はリードレプリカの存在です。

【参考】
自動バックアップの無効化（Amazon RDS）
リードレプリカの操作（Amazon RDS）
この問題のページを開く →
問題 4Sub "${AWS::StackName} Instance"デプロイ、プロビジョニング、自動化
問題
ある CloudOps エンジニアが、次の AWS CloudFormation テンプレートを調べています。なぜスタックの作成は失敗するのでしょうか。 【CloudFormation テンプレート】 AWSTemplateFormatVersion: '2010-09-09' Description: 'Creates an EC2 Instance' Resources: EC2Instance: Type: AWS::EC2::Instance Properties: ImageId: ami-79fd7eee InstanceType: m5n.large SubnetId: subnet-1abc3d3fg PrivateDnsName: ip-10-24-34-0.ec2.internal Tags: - Key: Name Value: !Sub "${AWS::StackName} Instance"

選択肢と解説

  • 1
    CloudFormation テンプレートの Outputs セクションが省略されているため。
  • 2
    CloudFormation テンプレートの Parameters セクションが省略されているため。
  • ✓
    PrivateDnsName は CloudFormation テンプレートから設定できないため。
  • 4
    CloudFormation テンプレートで VPC が指定されていないため。

解説

【正解】C

【0からの解説】
AWS::EC2::Instance リソースの PrivateDnsName は「読み取り専用の属性（出力属性）」であり、ユーザーが入力（指定）できるプロパティではありません。プライベート DNS 名は、インスタンスがサブネットの CIDR から取得したプライベート IP に基づいて AWS が自動的に割り当てます。そのため、テンプレートの Properties に PrivateDnsName を書いて値を渡そうとすると、CloudFormation がこのプロパティを認識できず（無効なプロパティとして）スタック作成が失敗します。これが原因 C です。

【誤りの選択肢】
A：Outputs セクションは任意（オプション）です。省略してもスタック作成は失敗しません。
B：Parameters セクションも任意です。本テンプレートは値をハードコードしており、Parameters がなくても作成は失敗しません。
C は PrivateDnsName が設定不可（読み取り専用）という CloudFormation の仕様に一致し、正しい失敗原因です。
D：EC2 インスタンスは SubnetId を指定しており、サブネットが属する VPC は自動的に決まります。テンプレートに VPC を別途指定する必要はなく、これは失敗原因ではありません。

【参考】
AWS::EC2::Instance（CloudFormation リソースリファレンス）
この問題のページを開く →
問題 5この要件を満たすソリューションはどれですか。信頼性と事業継続性
問題
ある企業は、復元力を提供するために複数の AWS リージョンにまたがるレイテンシーベースのルーティングで Amazon Route 53 を使用しています。企業は Route 53 のレイテンシーベースのルーティングを使用して、最も近いリージョンにトラフィックを誘導しています。各リージョン内では、加重（weighted）A レコードが複数のアベイラビリティーゾーンにトラフィックを分散しています。最近の更新作業中に、一部のアベイラビリティーゾーンのエンドポイントが異常（unhealthy）になりました。Route 53 は異常なエンドポイントにトラフィックをルーティングし続けました。企業は、将来この問題が発生しないようにする必要があります。この要件を満たすソリューションはどれですか。

選択肢と解説

  • ✓
    最近の更新中にトラフィックを受け取った加重レコードのそれぞれに、Route 53 ヘルスチェックを追加する。
  • 2
    更新中にトラフィックを向かわせるべきリージョンの Route 53 レコードの加重を増やす。
  • 3
    すべてのレコードを再構成して、すべてのリージョンで一律にレイテンシーベースのルーティングを使用する。
  • 4
    レイテンシーベースのルーティングの TTL 値を下げて、変更をより速く検出する。

解説

【正解】A

【0からの解説】
Route 53 は、レコードに「ヘルスチェック」を関連付けて初めて、そのエンドポイントが正常かどうかを判断し、異常なエンドポイントを応答対象から外すことができます。本問では加重 A レコードにヘルスチェックが関連付けられていなかったため、AZ のエンドポイントが異常になっても Route 53 はそれを検知できず、ダウンしたエンドポイントへトラフィックを送り続けてしまいました。各加重レコードに Route 53 ヘルスチェックを追加すれば、Route 53 は異常なレコードを自動的に応答から除外し、正常なエンドポイントだけにトラフィックを振り分けるようになります。これが正解 A です。

【誤りの選択肢】
A はヘルスチェック未設定という根本原因を解消し、異常エンドポイントの自動除外を実現するため正しい解決策です。
B：特定リージョンの加重を増やしても、異常なエンドポイント自体の検知・除外はできません。加重を変えるだけでは依然としてダウンしたエンドポイントにトラフィックが流れます。
C：すでにレイテンシーベースルーティングを使っており、「一律に再構成」しても AZ レベルの異常検知の仕組みは追加されません。問題（ヘルスチェック不在）を解決しません。
D：TTL を下げると DNS 変更の伝播は速くなりますが、エンドポイントの正常性を判断する仕組み（ヘルスチェック）がなければ、そもそも Route 53 は異常なエンドポイントを除外できません。原因解決になりません。

【参考】
Route 53 ヘルスチェックと DNS フェイルオーバーの仕組み
ヘルスチェックをレコードに関連付ける際の考慮事項
この問題のページを開く →
問題 6最も運用効率の高い方法でこの要件を満たすソリューションはどれですか。デプロイ、プロビジョニング、自動化
問題
ある企業は、300 台を超える Linux ベースのインスタンスでビジネスアプリケーションを実行しています。各インスタンスには AWS Systems Manager Agent（SSM Agent）がインストールされています。企業は、将来インスタンスの数が増えると見込んでいます。すべてのビジネスアプリケーションインスタンスには、同じユーザー定義タグが付けられています。CloudOps エンジニアは、すべてのビジネスアプリケーションインスタンスでコマンドを実行し、プライベートリポジトリからパッケージをダウンロードしてインストールしたいと考えています。リポジトリに過負荷をかけないように、CloudOps エンジニアは一度に 30 を超えるダウンロードが発生しないようにしたいと考えています。最も運用効率の高い方法でこの要件を満たすソリューションはどれですか。

選択肢と解説

  • 1
    セカンダリタグを使用して、それぞれ 30 台のインスタンスからなる 10 個のバッチを作成する。Systems Manager Run Command ドキュメントを使用してパッケージをダウンロードしてインストールする。セカンダリタグを使用して Run Command ドキュメントの中でターゲットを指定する。各バッチを 1 回ずつ実行する。
  • 2
    AWS Lambda 関数を使用して、ユーザー定義タグを持つインスタンス ID のリストを読み取る Systems Manager Run Command ドキュメントを自動的に実行する。Lambda 関数の予約済み同時実行数を 30 に設定する。
  • ✓
    Systems Manager Run Command ドキュメントを使用してパッケージをダウンロードしてインストールする。レート制御を使用して同時実行数（concurrency）を 30 に設定する。Run Command ドキュメントの中でユーザー定義タグを使用してターゲットを指定する。
  • 4
    AWS Step Functions の並列ワークフローステートを使用して、ユーザー定義タグを持つインスタンス ID のリストを読み取る Systems Manager Run Command ドキュメントを自動的に実行する。並列ステートの数を 30 に設定する。Step Functions ワークフローを 10 回実行する。

解説

【正解】C

【0からの解説】
Systems Manager Run Command には「レート制御（rate control）」という機能が標準で備わっており、同時実行数（concurrency）の上限を「台数」や「割合（％）」で指定できます。ここで concurrency を 30 に設定すれば、SSM が自動的に一度に最大 30 台ずつコマンドを実行し、それ以上は順番待ちになります。ターゲットはユーザー定義タグで指定できるため、インスタンスが増えても同じタグが付いていれば自動的に対象に含まれます。バッチ分けやコード作成が不要で、AWS のネイティブ機能だけで要件（同時 30 ダウンロード以下、将来の拡張に追従）を満たせるため、最も運用効率が高い C が正解です。

【誤りの選択肢】
A：セカンダリタグで手動で 10 バッチに分け、各バッチを個別に実行する方法は、インスタンスが増えるたびにタグの貼り直しとバッチ再編成が必要で運用負荷が高く、最も効率的とは言えません。
B：Lambda の予約済み同時実行数は Lambda 関数自体の並列起動数を制御するもので、Run Command が一度に実行するインスタンス数（ダウンロード数）を 30 に制限するものではありません。要件を確実には満たせず、Lambda コードの保守も発生します。
C は Run Command のレート制御という標準機能でそのまま要件を満たし、タグ指定で自動拡張にも対応するため最適です。
D：Step Functions のワークフローを自作・運用するのは、Run Command の組み込みレート制御に比べて余計な構築・保守が必要で、運用効率が劣ります。

【参考】
Run Command で同時実行数とエラーのしきい値を制御する（レート制御）
AWS Systems Manager Run Command
この問題のページを開く →
問題 7これらの要件を満たすソリューションはどれですか。セキュリティとコンプライアンス
問題
ある企業は AWS Organizations を使用して一連の AWS アカウントを管理しています。企業は組織内に組織単位（OU）を設定しています。アプリケーション用の OU（application OU）は、さまざまなアプリケーションをサポートしています。CloudOps エンジニアは、application OU 内のいずれのアカウントでも、CostCenter-Project タグが付いていない Amazon EC2 インスタンスをユーザーが起動できないようにする必要があります。この制限は application OU 内のアカウントにのみ適用されなければなりません。これらの要件を満たすソリューションはどれですか。

選択肢と解説

  • 1
    CostCenter-Project タグが存在するときに ec2:RunInstances アクションを許可するポリシーを持つ IAM グループを作成する。アプリケーションアカウントへのアクセスが必要なすべての IAM ユーザーをその IAM グループに入れる。
  • ✓
    CostCenter-Project タグが欠けているときに ec2:RunInstances アクションを拒否するサービスコントロールポリシー（SCP）を作成する。その SCP を application OU にアタッチする。
  • 3
    CostCenter-Project タグが存在するときに ec2:RunInstances アクションを許可するポリシーを持つ IAM ロールを作成する。その IAM ロールを application OU のアカウント内の IAM ユーザーにアタッチする。
  • 4
    CostCenter-Project タグが欠けているときに ec2:RunInstances アクションを拒否するサービスコントロールポリシー（SCP）を作成する。その SCP をルート OU にアタッチする。

解説

【正解】B

【0からの解説】
「組織内の特定の OU に属するすべてのアカウントに対して、一律に操作を制限したい」という要件には、AWS Organizations のサービスコントロールポリシー（SCP）が最適です。SCP は、アタッチした OU 配下のすべてのアカウントの権限の上限（ガードレール）を定義します。本問では「CostCenter-Project タグが付いていない場合に ec2:RunInstances を拒否する」SCP を作り、それを application OU にアタッチします。これにより、application OU 内のアカウントだけにタグ必須のルールが強制され、他の OU には影響しません。条件キー（例：aws:RequestTag）を使ってタグの有無を判定します。これが正解 B です。

【誤りの選択肢】
A：IAM グループの許可ポリシーは、そのグループのユーザーにのみ作用し、アカウント全体・OU 全体の起動を確実に制限できません。グループに属さないユーザーやロールには適用されず、OU 単位の強制になりません。
B は SCP を application OU にアタッチし、対象 OU のアカウントだけにタグ必須を強制するため要件に完全に一致します。
C：IAM ロールをユーザーにアタッチするという表現自体が不自然で、許可ポリシーでは「タグなし起動の禁止」を組織全体に強制できません。OU 範囲の制御にもなりません。
D：SCP をルート OU にアタッチすると、組織内のすべてのアカウント（application OU 以外も含む）に制限が及びます。「application OU のみに適用」という要件に反します。

【参考】
サービスコントロールポリシー（SCP）
タグによる EC2 リソースへのアクセス制御
この問題のページを開く →
問題 8この要件を満たすために CloudOps エンジニアは何をすべきですか。デプロイ、プロビジョニング、自動化
問題
ある CloudOps エンジニアが、失敗した AWS CloudFormation スタックの作成をトラブルシューティングしています。エンジニアが問題を特定できる前に、スタックとそのリソースが削除されてしまいました。今後のデプロイのために、CloudOps エンジニアは CloudFormation が正常に作成したリソースを保持しておく必要があります。この要件を満たすために CloudOps エンジニアは何をすべきですか。

選択肢と解説

  • 1
    スタック作成時に DisableRollback パラメーターの値を False に設定する。
  • ✓
    スタック作成時に OnFailure パラメーターの値を DO_NOTHING に設定する。
  • 3
    スタック作成時に DO_NOTHING のロールバックトリガーを持つロールバック構成を指定する。
  • 4
    スタック作成時に OnFailure パラメーターの値を ROLLBACK に設定する。

解説

【正解】B

【0からの解説】
CloudFormation のスタック作成（CreateStack）には、失敗時の動作を制御する OnFailure パラメーターがあり、ROLLBACK（デフォルト：失敗時にロールバックして作成済みリソースを削除）、DELETE（スタックごと削除）、DO_NOTHING（何もしない＝作成済みリソースをそのまま残す）の 3 つから選べます。本問では「正常に作成されたリソースを保持し、後から問題を調査したい」ので、OnFailure を DO_NOTHING に設定します。これにより、スタックは失敗状態のまま残り、作成済みリソースも削除されないため、原因調査ができます。これが正解 B です。

【誤りの選択肢】
A：DisableRollback を False にすると、ロールバックが有効（=失敗時に作成済みリソースが削除される）になります。これは要件と逆で、リソースが消えてしまいます。リソースを残すなら DisableRollback は True にする必要があります。
B は で作成済みリソースを保持でき、要件に一致します。
C：「ロールバック構成（rollback configuration）」は CloudWatch アラームによる監視ベースのロールバックを設定するもので、DO_NOTHING というロールバックトリガーは存在しません。架空の設定です。
D：OnFailure=ROLLBACK はデフォルト動作で、失敗時に作成済みリソースを削除します。今回の「リソースが消えてしまった」状況そのものであり、要件を満たしません。

【参考】
CloudFormation スタック作成失敗時の動作（OnFailure）
スタック作成エラーのトラブルシューティング
この問題のページを開く →
問題 9これらの要件を満たすソリューションはどれですか。信頼性と事業継続性
問題
ある企業は、ポイントインタイムリカバリ、バックトラッキング、自動バックアップが有効になっている Amazon Aurora MySQL DB クラスターを使用しています。CloudOps エンジニアは、DB クラスターを過去 72 時間以内の特定のリカバリポイントにロールバックできる必要があります。復元は同じ本番 DB クラスターの中で完了させる必要があります。これらの要件を満たすソリューションはどれですか。

選択肢と解説

  • 1
    Aurora レプリカを作成する。そのレプリカを昇格させてプライマリ DB インスタンスを置き換える。
  • 2
    AWS Lambda 関数を作成して、自動バックアップを既存の DB クラスターに復元する。
  • ✓
    バックトラッキングを使用して既存の DB クラスターを目的のリカバリポイントまで巻き戻す。
  • 4
    ポイントインタイムリカバリを使用して既存の DB クラスターを目的のリカバリポイントに復元する。

解説

【正解】C

【0からの解説】
Aurora MySQL の「バックトラッキング（Backtrack）」は、新しいクラスターを作らずに、既存の（同じ）DB クラスターを指定した過去の時点まで「巻き戻す」機能です。ポイントインタイムリカバリ（PITR）が新しいクラスターを作成して復元するのに対し、バックトラックは現行クラスターをその場で巻き戻すため、本問の「同じ本番 DB クラスターの中で完了させる」という要件にぴったり合致します。バックトラックウィンドウ（最大 72 時間まで設定可能）の範囲内であれば、迅速に特定時点へ戻せます。これが正解 C です。

【誤りの選択肢】
A：Aurora レプリカを昇格させるのはフェイルオーバー（読み取りレプリカを新しいプライマリにする）操作であり、特定の過去時点へ巻き戻す手段ではありません。要件を満たしません。
B：Aurora の自動バックアップを「既存のクラスターに上書き復元する」ことはできません。バックアップからの復元は新しいクラスターの作成になります。Lambda を使っても同じクラスターへの in-place 復元は実現できません。
C はバックトラックで同一クラスターをその場で巻き戻せるため、要件に完全に一致します。
D：ポイントインタイムリカバリは「新しい DB クラスター」を作成して復元する方式です。同じ本番クラスター内で完了させるという要件に反します。

【参考】
Aurora DB クラスターのバックトラック（Amazon Aurora MySQL）
この問題のページを開く →
問題 10この要件を満たすソリューションはどれですか。ネットワークとコンテンツ配信
問題
ある企業がレガシーアプリケーションを AWS に移行しています。企業は複数のアベイラビリティーゾーンにまたがる Amazon EC2 インスタンスに、レガシーアプリケーションを手動でインストール・構成しています。企業はそのアプリケーションのために Application Load Balancer（ALB）をセットアップしました。企業はターゲットグループのルーティングアルゴリズムを weighted random（加重ランダム）に設定しています。アプリケーションはセッションアフィニティを必要とします。デプロイ後、利用者からはレガシー版には存在しなかったランダムなアプリケーションエラーが報告されています。ターゲットグループのヘルスチェックには何の失敗も表示されていません。企業はこのアプリケーションエラーを解決する必要があります。この要件を満たすソリューションはどれですか。

選択肢と解説

  • ✓
    ターゲットグループのルーティングアルゴリズムを least outstanding requests（未処理リクエスト数が最小）に設定する。
  • 2
    ターゲットグループの異常緩和（anomaly mitigation）を有効にする。
  • 3
    ターゲットグループのクロスゾーン負荷分散属性をオフにする。
  • 4
    ターゲットグループの登録解除遅延（deregistration delay）属性を増やす。

解説

【正解】A

【0からの解説】
このアプリケーションは「セッションアフィニティ（セッション維持＝スティッキーセッション）」を必要とします。ところが、ターゲットグループのルーティングアルゴリズムが「weighted random（加重ランダム）」に設定されています。
AWS の仕様上、ALB の weighted random アルゴリズムはスティッキーセッション（セッションアフィニティ）をサポートしていません。そのため、本来は同じインスタンスへ送られ続けるべき同一ユーザーのリクエストが毎回別々のインスタンスに分散してしまい、セッション情報が引き継がれず「ランダムなエラー」として現れます。ヘルスチェックはインスタンスの健全性を見るだけなので、この種のセッション不整合は検知されず「ヘルスチェックは合格しているのにエラー」という症状になります。
解決策は、スティッキーセッションをサポートするルーティングアルゴリズムに変更することです。ALB では「round robin（ラウンドロビン）」と「least outstanding requests（未処理リクエスト数最小）」がスティッキーセッションに対応しています。したがって、ルーティングアルゴリズムを least outstanding requests に変更する選択肢 A が正解です。これによりスティッキーセッションが正しく機能し、セッションアフィニティが回復してエラーが解消します。

【誤りの選択肢】
B：異常緩和（anomaly mitigation）はweighted random アルゴリズムでのみ利用可能な機能です。有効化しても weighted random のままであり、スティッキーセッション非対応という根本原因は解消しません。むしろ weighted random を使い続けることになるため、セッションアフィニティの問題は残ります。
C：クロスゾーン負荷分散をオフにすると、トラフィックは同一 AZ 内のターゲットにのみ分散されますが、AZ 内に複数インスタンスがあればやはりセッションは分散され、セッションアフィニティの欠如という原因は解決しません。
D：登録解除遅延（deregistration delay／コネクションドレイン）は、インスタンスをターゲットから外す際に処理中のリクエストを完了させるための待ち時間設定です。新規リクエストのセッション維持とは無関係で、ランダムエラーの原因に対処しません。

【参考】
ターゲットグループのルーティングアルゴリズム - Application Load Balancer
スティッキーセッション - Application Load Balancer
この問題のページを開く →
問題 11VPC フローログが CloudWatch Logs に発行されるのを妨げている可能性があるものはどれですか？ネットワークとコンテンツ配信
問題
ある企業の CloudOps エンジニアが、アプリケーションのコンポーネント間の通信のトラブルシューティングをしています。同社は VPC フローログを Amazon CloudWatch Logs に発行するよう構成しました。しかし、CloudWatch Logs にログが存在しません。 VPC フローログが CloudWatch Logs に発行されるのを妨げている可能性があるものはどれですか？

選択肢と解説

  • ✓
    フローログ用の IAM ロールにアタッチされた IAM ポリシーに、logs:CreateLogGroup 権限が不足している。
  • 2
    フローログ用の IAM ロールにアタッチされた IAM ポリシーに、logs:CreateExportTask 権限が不足している。
  • 3
    VPC が IPv6 アドレス用に構成されている。
  • 4
    VPC が AWS アカウント内の別の VPC とピアリングされている。

解説

【正解】A

【0からの解説】
VPC フローログを CloudWatch Logs に発行するには、VPC フローログサービスがあなたのアカウントの CloudWatch Logs にログを書き込めるよう、IAM ロール（フローログ配信用ロール）が必要です。このロールにアタッチするポリシーには、ロググループを作成する logs:CreateLogGroup、ログストリームを作成する logs:CreateLogStream、ログを書き込む logs:PutLogEvents、さらに logs:DescribeLogGroups と logs:DescribeLogStreams の権限が必要です。
これらのうち1つでも欠けるとフローログは正しく配信されず、結果として CloudWatch Logs にログが1件も現れません。設問では「ログが全く存在しない」状態なので、ロググループ自体を作成できない logs:CreateLogGroup の不足が最も典型的な原因です。
また、ロールの信頼ポリシーで vpc-flow-logs.amazonaws.com がこのロールを引き受けられるようになっている必要があります。

【誤りの選択肢】
B：logs:CreateExportTask は、CloudWatch Logs のログを S3 へエクスポートする操作の権限であり、フローログを CloudWatch Logs へ発行する動作とは無関係です。
C：VPC が IPv6 を使用していてもフローログは記録できます。IPv6 トラフィックもフローログでキャプチャ可能で、発行を妨げません。
D：VPC ピアリングの有無はフローログの発行とは無関係です。むしろピア間のトラフィックもフローログに記録対象となります。

【参考】
Amazon VPC フローログを CloudWatch Logs に発行する
CloudWatch Logs へのフローログ発行に必要な IAM ロール
この問題のページを開く →
問題 12この要件を満たすために CloudOps エンジニアは何をすべきですか？信頼性と事業継続性
問題
ある企業が Amazon S3 バケットにバックアップを保存しています。バックアップは作成後、少なくとも3か月間は削除できないようにする必要があります。 この要件を満たすために CloudOps エンジニアは何をすべきですか？

選択肢と解説

  • 1
    すべてのユーザーに対して s3:DeleteObject アクションを拒否する IAM ポリシーを構成する。オブジェクトが書き込まれてから3か月後にそのポリシーを削除する。
  • ✓
    新しい S3 バケットでコンプライアンスモードの S3 Object Lock を有効にする。すべてのバックアップを保持期間3か月でその新しい S3 バケットに配置する。
  • 3
    既存の S3 バケットで S3 バージョニングを有効にする。S3 ライフサイクルルールを構成してバックアップを保護する。
  • 4
    新しい S3 バケットでガバナンスモードの S3 Object Lock を有効にする。すべてのバックアップを保持期間3か月でその新しい S3 バケットに配置する。

解説

【正解】B

【0からの解説】
「一定期間、誰にも削除させない」という WORM（Write Once Read Many）要件には S3 Object Lock を使います。Object Lock には2つのモードがあります。
・コンプライアンスモード：保持期間中は、ルートユーザーを含む誰もオブジェクトバージョンを削除・上書きできず、保持期間自体を短縮することもできません。規制対応の厳格な保護に使います。
・ガバナンスモード：s3:BypassGovernanceRetention 権限を持つ特権ユーザーは保護を解除して削除できます。
設問は「少なくとも3か月間は削除できないようにする」という確実な保護が要件なので、誰も削除できないコンプライアンスモードで保持期間3か月を設定するのが正解です。なお Object Lock はバケット作成時に有効化する必要があり（既存バケットでは原則 AWS サポート経由）、バージョニングも自動的に有効になるため、新しいバケットを使う選択肢が妥当です。

【誤りの選択肢】
A：IAM ポリシーによる拒否はあくまで権限ベースの制御で、ポリシーの変更・削除や別の権限を持つ主体によって回避できます。確実な削除防止にはなりません。
C：バージョニングとライフサイクルだけでは削除を防げません。バージョニングは削除マーカーを付けるだけで、誰でも DeleteObject を実行でき、特定バージョンの完全削除も可能です。
D：ガバナンスモードは BypassGovernanceRetention 権限を持つユーザーが保護を解除できるため、「少なくとも3か月削除できない」を厳密には保証できません。確実性を求める本設問ではコンプライアンスモードが正解です。

【参考】
S3 Object Lock の使用
S3 Object Lock の保持モード（コンプライアンス／ガバナンス）
この問題のページを開く →
問題 13この新しい要件を満たす最も運用効率の高い方法はどれですか？モニタリング、ロギング、分析、修復、パフォーマンス最適化
問題
ある環境は 100 台の Amazon EC2 Windows インスタンスで構成されています。Amazon CloudWatch エージェントがすべての EC2 インスタンスにデプロイされ、ログファイルをキャプチャするためのベースライン構成ファイルとともに実行されています。新たに、そのうち 50 台のインスタンスに存在する DHCP ログファイルをキャプチャするという要件が追加されました。 この新しい要件を満たす最も運用効率の高い方法はどれですか？

選択肢と解説

  • ✓
    DHCP ログをキャプチャするための追加の CloudWatch エージェント構成ファイルを作成する。AWS Systems Manager の Run Command を使用し、append-config オプションを付けて各 EC2 インスタンスで CloudWatch エージェントを再起動し、追加の構成ファイルを適用する。
  • 2
    各 EC2 インスタンスに管理者権限でログインする。必要なベースラインログファイルと DHCP ログファイルを CloudWatch にプッシュする PowerShell スクリプトを作成する。
  • 3
    各 EC2 インスタンスで CloudWatch エージェント構成ファイルウィザードを実行する。ベースラインログファイルが含まれていることを確認し、ウィザード作成プロセス中に DHCP ログファイルを追加する。
  • 4
    各 EC2 インスタンスで CloudWatch エージェント構成ファイルウィザードを実行し、詳細レベルで advanced を選択する。これによりオペレーティングシステムのログファイルがキャプチャされる。

解説

【正解】A

【0からの解説】
CloudWatch エージェントは複数の構成ファイルを「追記（append）」して適用できます。amazon-cloudwatch-agent-ctl コマンドや SSM 経由で append-config を指定すると、既存のベースライン構成を維持したまま、新しい構成ファイルの内容を上乗せできます。
さらに、対象が 50 台と多いため、各インスタンスに手作業でログインするのは非効率です。AWS Systems Manager の Run Command を使えば、対象インスタンスをタグなどでまとめて選択し、エージェントへの追加構成の適用と再起動を一括・リモートで実行できます。これが最も運用効率の高い（手作業が少なく自動化できる）方法です。

【誤りの選択肢】
B：50 台すべてに管理者でログインして個別にスクリプトを作るのは手作業が多く、運用効率が著しく低いです。せっかくの CloudWatch エージェントを使わず独自実装する点も非効率です。
C：構成ファイルウィザードを各インスタンスで個別に実行するのは手作業で、100/50 台規模ではスケールしません。Run Command による一括適用に劣ります。
D：ウィザードの advanced 詳細レベルはメトリクスの収集粒度に関するもので、特定の DHCP ログファイルを狙ってキャプチャする手段ではありません。要件を満たしません。

【参考】
CloudWatch エージェント構成ファイルの複数適用（append-config）
Systems Manager Run Command で CloudWatch エージェントを管理する
この問題のページを開く →
問題 14オブジェクトがレプリケートされない可能性が高い理由はどれですか？信頼性と事業継続性
問題
ある企業が自社の Amazon S3 バケットに対してクロスリージョンレプリケーション（CRR）を実装しています。S3 バケットは us-east-1 リージョンにあります。同社はバケット内のデータを保護するために、Amazon S3 マネージドキーによるサーバー側暗号化（SSE-S3）を使用しています。 CloudOps エンジニアは、バックアップを S3 バケットに保存するための新しい AWS アカウントを作成します。すべてのバックアップ用バケットは us-west-2 リージョンにあります。CloudOps エンジニアはソースバケットと宛先バケットの両方でバージョニングを有効にします。CloudOps エンジニアはソースアカウントで s3.amazonaws.com 用の IAM ロールを作成します。CloudOps エンジニアはその IAM ロールに、ソースバケットでの読み取りアクション、宛先バケットでのレプリケートアクション、および宛先バケットのキーを使用する暗号化アクションを実行する権限を付与します。宛先バケットのポリシーは、その IAM ロールがレプリケートおよび読み取りアクションを実行することを許可しています。 レプリケーション構成が完了した後、CloudOps エンジニアはオブジェクトがレプリケートされていないことに気づきます。 オブジェクトがレプリケートされない可能性が高い理由はどれですか？

選択肢と解説

  • 1
    IAM ロールとバケットポリシーに ObjectOwnerOverrideToBucketOwner 権限が必要である。
  • 2
    ソースバケットと宛先バケットのオブジェクトはマルチリージョンキーで暗号化されている必要がある。
  • 3
    Amazon S3 用のゲートウェイ VPC エンドポイントをソースアカウントと宛先アカウントに作成する必要がある。
  • ✓
    宛先バケットは AWS KMS キーによるサーバー側暗号化（SSE-KMS）を使用する必要がある。

解説

【正解】D

【0からの解説】
ここでの最大の手がかりは、CloudOps エンジニアが IAM ロールに「宛先バケットのキーを使用する暗号化アクション（KMS の Encrypt 等）」を付与した、という記述です。これは宛先側が KMS キー（SSE-KMS）で暗号化されていることを前提とした権限設定です。
ところがソースバケットは SSE-S3（S3 マネージドキー）を使用しています。レプリケーション構成と権限が「宛先は KMS キーで暗号化する」前提で組まれているのに、宛先バケットが SSE-KMS で構成されていなければ、設定の整合が取れずレプリケーションが期待どおり機能しません。したがって宛先バケットを SSE-KMS で構成する必要がある、というのが最も妥当な理由です。
S3 レプリケーションでは、KMS で暗号化されたオブジェクトを扱う場合、レプリケーションロールにソースキーの kms:Decrypt と宛先キーの kms:Encrypt を付与し、宛先を SSE-KMS にするのが定石です。

【誤りの選択肢】
A：ObjectOwnerOverrideToBucketOwner は、クロスアカウントで宛先バケット所有者にオブジェクト所有権を移すための任意設定です。これが無くてもレプリケーション自体は動作するため、「レプリケートされない」直接の原因ではありません。
B：マルチリージョンキー（MRK）はレプリケーションの必須要件ではありません。各リージョンで個別の KMS キーを使ってもレプリケーションは可能です。
C：S3 レプリケーションは AWS のマネージドサービス間でリージョンをまたいで行われ、VPC のゲートウェイエンドポイントは不要です。エンドポイントは VPC 内リソースから S3 へのプライベート接続用で、本件とは無関係です。

【参考】
KMS で暗号化されたオブジェクトのレプリケーション
レプリケーションの設定とトラブルシューティング
この問題のページを開く →
問題 15この要件を満たすソリューションはどれですか？信頼性と事業継続性
問題
あるアプリケーションが Application Load Balancer（ALB）の背後にある Amazon EC2 インスタンス上で実行されています。このアプリケーションは起動後、ローカルキャッシュを満たすのに最大 2 分かかります。アプリケーションは起動の数秒後にはターゲットグループのヘルスチェックで正常（healthy）と報告します。 CloudOps エンジニアは、一部のインスタンスを再起動した後、各インスタンスが正常と報告した直後に等しい割合のトラフィックを受け取ることを観察しました。アプリケーションは、キャッシュが満たされる間、徐々に増加する割合のトラフィックを受け取る必要があります。 この要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    ターゲットグループの属性 slow_start.duration_seconds を 120 秒に変更する。インスタンスを再起動する前にターゲットグループから登録解除し、再起動後にターゲットグループに登録する。
  • 2
    ターゲットグループの HealthCheckTimeoutSeconds パラメータを 120 秒に変更する。インスタンスを再起動する前にターゲットグループから登録解除し、再起動後にターゲットグループに登録する。
  • 3
    ヘルスチェックステータスを監視する Amazon CloudWatch アラームを構成する。ヘルスチェックが失敗した場合に EC2 インスタンスを再起動するようアラームのアクションを構成する。ターゲットグループの属性 loadbalancing.algorithm.type を weighted_random に変更する。
  • 4
    Amazon EC2 Auto Scaling グループを作成する。既存の EC2 インスタンスを Auto Scaling グループにアタッチする。起動中のインスタンスを Pending:Wait 状態に移行する EC2 Auto Scaling ライフサイクルフックを構成する。ローカルキャッシュが満たされたらライフサイクルフックを完了するようアプリケーションを更新する。

解説

【正解】A

【0からの解説】
ALB のターゲットグループには「スロースタート（slow start）」という機能があります。slow_start.duration_seconds を設定すると、新しく正常になったターゲットへ、いきなり均等なトラフィックを送るのではなく、指定した秒数をかけてトラフィック割合を 0% から徐々に 100% まで増やしていきます。
本設問は「キャッシュが満たされる最大 2 分（120 秒）の間、徐々に増加する割合のトラフィックを受け取りたい」という、まさにスロースタートが解決する要件です。slow_start.duration_seconds を 120 秒に設定すれば、ターゲットが healthy になっても 120 秒かけて段階的にトラフィックが増えます。
なお、スロースタートはターゲットが「新規登録」または「ヘルスチェックで正常になった」タイミングで作動するため、再起動の前後で登録解除・再登録を行うことで確実にスロースタート期間を発動させられます。

【誤りの選択肢】
B：HealthCheckTimeoutSeconds は1回のヘルスチェック応答を待つ秒数で、しかも上限は 120 秒ほどあっても用途が異なります。これを延ばしてもトラフィックを段階的に増やすことはできず、要件を満たしません。
C：weighted_random アルゴリズムはターゲット間の重み付けランダム分散であり、起動直後に段階的に増やす仕組みではありません。さらにヘルスチェック失敗で再起動するアクションも本要件（段階的トラフィック増加）とは無関係です。
D：ライフサイクルフックでキャッシュ完了まで待たせる方式は、Auto Scaling による新規起動には有効ですが、設問は既存インスタンスの「再起動」シナリオです。再起動はスケーリングイベントではないためライフサイクルフックは発火せず、要件に合致しません。slow start の方が直接的で簡潔です。

【参考】
ターゲットグループのスロースタートモード
Application Load Balancer のターゲットグループ
この問題のページを開く →

SOA-C03 模擬問題集についてよくある質問

SOA-C03 の練習問題は無料で試せますか？

はい。SOA-C03 は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン（月額 ¥980）または Pro プラン（月額 ¥4,980）でご利用ください。

問題は何問ありますか？

SOA-C03 は本番形式の練習テスト 2 回・全 100 問を収録しています。全問に解説が付いています。

解説は付いていますか？

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン（出題分野）別の正答率も受験後に確認できます。