AWS SAP サンプル問題

正解：C

A　SCPが管理アカウントに効かないのはアタッチ先の問題ではない。どの階層にアタッチしても管理アカウントは評価対象外のままであり、症状は変わらない。

B　許可境界はプリンシパル単位のため新規作成分への適用漏れが起きるうえ、ルートユーザーには適用できない。アカウント全体の恒久的な上限にはならない。

C（正解）　正解。SCPは組織の管理アカウントには一切適用されない仕様であり、設定では変えられない。管理アカウントは請求と組織管理に用途を限定し、ワークロードはメンバーアカウントへ移すのが原則である。

D　管理アカウントはOUに配置してもSCPの対象外である。そもそも管理アカウントを他のOUへ移す運用は統制上も推奨されない。

正解：A

A（正解）　正解。SCPは階層に沿って継承され、各階層の評価結果の積集合が有効な上限になる。事業部共通の統制を親OUに残したまま、環境差分だけを子OUで表現できる。

B　事業部共通の統制をSCPで表現できなくなる。タグはSCPのアタッチ単位にならないため、既存統制の粒度が失われる。

C　動作はするがアカウント数に比例してアタッチ作業と棚卸しが増える。階層継承を活用しないため管理コストが最小にならない。

D　許可境界はプリンシパル単位で、新たに作成されたロールへの適用漏れを防げない。アカウント全体の上限を定める用途には向かない。

正解：B

A　階層をまたぐSCPは積集合で評価されるため、ルート側にFullAWSAccessが残っていても下位の許可リストは有効になるはずである。原因の理解が誤っている。

B（正解）　正解。同一階層に複数のSCPがある場合はその和集合が評価結果になり、FullAWSAccessが許可リストを打ち消してしまう。許可リスト戦略では、許可リストを付けた階層のFullAWSAccessを必ず外す。

C　SCPが権限を付与しないという原則自体は正しいが、承認外サービスを使えてしまう原因の説明にならない。既存のIAM許可がある以上、上限側を正しく絞る必要がある。

D　許可リスト戦略はSCPでサポートされている。列挙方式は運用が重く、新サービスの追加にも追随できない。

正解：D

A　タグポリシーの強制は対応するサービスとリソースタイプが限定されており、全サービスを網羅しない。値の標準化には有効だが、作成時点の網羅的なブロックにはならない。

B　発見的統制であり作成そのものは許してしまう。自動付与する値も推測になるため、部門コードの正確性を担保できない。

C　請求上の分類はできるが、1アカウントに複数部門が同居する場合に分解できない。リソース単位でタグを強制するという要件を満たさない。

D（正解）　正解。SCPは条件キーで作成リクエストを予防的にブロックでき、タグポリシーは許容される値の定義と非準拠の可視化を担う。両者の組み合わせが定石である。

正解：A

A（正解）　正解。Control Towerは既存組織に対して有効化でき、OUの登録によって既存アカウントを段階的に取り込める。Account Factoryは新規発行用であり、既存アカウントは登録で扱う。

B　組織の作り直しは請求の分断や大掛かりな移行作業を招く。既存組織のままControl Towerを有効化できるため不要である。

C　本番の再構築は停止と大きなリスクを伴い現実的でない。Account Factoryは新規アカウントのプロビジョニング機能である。

D　Control Towerは既存組織でも利用できるため前提が誤っている。自作は可能だが、標準機能を使わない理由にはならない。

正解：D

A　手作業は新規アカウントで漏れが生じ、設定を戻されても検知できない。組織的な恒久性が担保されない。

B　検出と修復の仕組みであり、一時的に公開状態が発生する。共有が不可能な状態を維持するという要件を満たさない。

C　社内の正当な共有設定や説明文の変更まで一律に止まる。サービスのアカウント設定そのものを固定するわけでもない。

D（正解）　正解。宣言型ポリシーはサービスのアカウント設定を組織で固定するため、新規アカウントや以後の設定変更に対しても意図した状態が維持される。

正解：A・C

A（正解）　正解。Account Factoryは事前定義されたベースライン（ネットワーク、ログ記録、コントロール）を適用した状態で新規アカウントを払い出せるため、手作業を排除できる。

B　管理アカウントのルート認証情報の共有はセキュリティ上あり得ず、ベースラインの自動適用も標準化も実現できない。

C（正解）　正解。組織全体の集約器により、複数アカウント・複数リージョンの構成と準拠状況を単一のビューで継続的に可視化できる。

D　Amazon InspectorはEC2、ECRイメージ、Lambdaの脆弱性を評価するサービスであり、アカウント作成イベントの検査やガバナンス評価は行わない。

E　Trusted Advisorはクォータ使用状況などの推奨事項を提示するサービスであり、アカウント払い出しのトリガーやベースライン配布の機能は持たない。

正解：B・D

A　アカウント内のIAMポリシーはそのアカウントの管理者が自由に変更・削除できるため予防的統制として機能しない。個別に作成した証跡もメンバーアカウント側で停止できてしまう。

B（正解）　正解。組織の証跡は管理アカウントまたはCloudTrailの委任管理者アカウントでのみ管理でき、メンバーアカウント側からは停止・削除・変更ができない。

C　AWS Configはリソースが作成された後に評価する発見的統制であり、作成そのものを拒否する予防的統制ではない。設問の要件を満たさない。

D（正解）　正解。SCPはメンバーアカウントの管理者にも権限の上限として作用するため、承認外リージョンへのAPI呼び出しを事前に拒否できる。

E　VPCエンドポイントポリシーはそのエンドポイントを経由する通信にしか作用しない。マネジメントコンソールやVPC外からの呼び出しには効かないため統制として不十分である。

正解：A

A（正解）　正解。静的安定性の考え方であり、フェイルオーバー時に新規のEC2起動というコントロールプレーンのAPI呼び出しへ依存しないため、起動遅延やAPIの逼迫の影響を受けない。3AZ構成では各AZ50%（合計150%）の事前プロビジョニングが定石となる。

B　ウォームプールは起動時間を短縮するが、障害検知後に起動APIを呼ぶ点は変わらず、コントロールプレーンへの依存とタイムラグが残る。「一切のスケーリング動作を待たない」という要件を満たさない。

C　反応を早めるだけで、障害検知から起動、ヘルスチェック通過までの時間は依然として必要になる。障害時のAPI逼迫にも脆弱なままである。

D　クロスゾーン負荷分散の設定は容量不足を解決しない。むしろ無効化するとAZごとのターゲット数の偏りが負荷の偏りに直結し、状況を悪化させうる。

正解：C

A　ネットワークACLは通信を遮断するだけで、ALBが当該AZのターゲットを健全と判断し続ける限りリクエストは送られ、接続失敗として顕在化する。手作業のため誤設定のリスクも高い。

B　インスタンスの終了と再作成を伴うため復帰に時間がかかり、可逆性が低い。一時的なグレー障害への退避手段としては重すぎる。

C（正解）　正解。ゾーンシフトはロードバランサーのゾーン単位のDNSレコードを外し、数分以内に該当AZへのトラフィックを止める。期限付きで開始でき、キャンセルすれば元に戻るため、グレー障害の一時退避に適する。

D　ALBはAZごとのDNS名を公開しないためRoute 53だけでこの構成を組むのは実質的に困難であり、ヘルスチェックがグレー障害を検知できないという根本問題も未解決のまま残る。

正解：B

A　デッドレターキューは毒メッセージの隔離に有効だが、占有が起きている間の他テナントへの影響は防げない。フリートの増強はコストが線形に増えるだけで分離にならない。

B（正解）　正解。シャッフルシャーディングではテナントごとに割り当てられるセルの組み合わせが異なるため、あるテナントが自分の担当セルを壊しても、他テナントと組み合わせが完全に重なる確率は極めて低い。少ないセル数で多数の仮想的な分離境界を作れる。

C　分離の強度は最も高いが、テナント数に比例してリソースと運用負荷が増える。リソースを線形に増やさないという設問の制約に反する。

D　メッセージグループにより順序は保たれるが、ワーカープール自体は共有のままである。長時間実行のリクエストがフリート全体を占有する問題は解決しない。

正解：D

A　Route 53のレコード変更はコントロールプレーンの操作であり、広域障害時には可用性が下がりうる。両リージョンが同時にアクティブになるのを防ぐ仕組みも別途作り込む必要がある。

B　ヘルスチェックはグレー障害やデータ層の問題を検知できないことがあり、切り替えを人が保留する余地もない。排他制御の安全策も持たない。

C　トラフィックダイヤルの操作は有効な手段だが、これもコントロールプレーンのAPI操作であり、相互に排他的な状態を強制するルールを備えていない。

D（正解）　正解。ルーティングコントロールはデータプレーンで動作し、5つのリージョンに分散したクラスターエンドポイントから操作できるため、障害時でも高い可用性を保つ。アサーションルールにより「常に1リージョンのみオン」といった安全策を強制できる。

正解：A

A（正解）　正解。準備状況チェックは両リージョンのAuto Scalingの上限やDynamoDBの設定などを比較し、容量・設定・クォータのドリフトを継続的に可視化する。訓練時ではなく日常的に差分を検出できる。

B架空　このようなAWSサービスは存在しない。それらしい名称に見えるが架空であり、選択してはならない。

C　実現は可能だが、リージョン間の対応関係やクォータ、容量の観点を自前で表現する必要があり、開発と保守の負担が大きい。マネージドな手段がある場面では最適とは言えない。

D　Resilience Hubはアーキテクチャ上のRTO/RPO到達可能性を評価するものであり、スタンバイ環境の容量やクォータの一致を継続的に監視する用途には焦点が合っていない。

正解：C

A　偏りは解消するが、あるAZの障害が全AZのターゲットへ波及しうるうえ、AZ間のデータ転送も発生する。設問はAZの分離境界を維持することを求めている。

B　スロースタートは新規ターゲットの暖機のための機能で、NLBのターゲットグループでは利用できない。恒常的な台数差による偏りにも効果がない。

C（正解）　正解。クロスゾーン負荷分散が無効のとき、NLBは各AZへ概ね均等にトラフィックを配分するため、AZごとのターゲット数が同じであればインスタンスあたりの負荷も均される。分離境界も保たれる。

D　DNSレイヤーで比率を制御するとリゾルバーのキャッシュの影響で精度が出ず、構成も複雑になる。台数を揃えるだけで解決する問題に対して過剰である。

正解：B

A　リトライは一時的なエラーには有効だが、長時間の全面障害では待ち時間を増やしてスレッドを枯渇させ、かえって影響を拡大させる。ハード依存であること自体は変わらない。

B（正解）　正解。検証をリクエストパスから外し、鍵の取得に失敗しても直近の値で動作を続ける「フェイルスタティック」により、外部依存をフォールバック不可のハード依存からソフト依存へ格下げできる。静的安定性の典型的な適用例である。

C　障害の波及やリソース枯渇は抑えられるが、リクエストが拒否される点は同じでサービスは停止したままである。可用性の回復にはならない。

D　キャッシュミスや新規セッションでは外部依存が残るため、障害時の全面停止は避けられない。依存の性質を変えない部分的な緩和にとどまる。

正解：D

A　検知の遅延を招くだけで、「7台以上が健全か」という台数ベースの条件は表現できない。フラッピングの緩和にすぎない。

B　1つのレコードに関連付けられるヘルスチェックは1つであり、この構成は組めない。仮に組めても全滅時のみの切り替えとなり要件と異なる。

C　メトリクスベースの判定は代替になりうるが、複合アラームは他のアラームの状態を論理結合するものであり、健全な台数のカウントには数式を用いたメトリクスアラームが別途必要になる。Route 53だけで完結する方法がある。

D（正解）　正解。計算されたヘルスチェックは複数の子ヘルスチェックを集約し、指定した数以上が健全であれば全体を健全とみなす。台数ベースの判定をRoute 53だけで表現できる。

正解：C

A　リードレプリカは読み取りのオフロードには有効だが、同期スタンバイへのフェイルオーバー時間そのものは短縮されない。フェイルオーバー優先度はマルチAZ DBインスタンスの概念でもない。

B　性能の向上はフェイルオーバー時間の主要因ではない。切り替えはDNSの更新と復旧処理に依存しており、ストレージ変更では35秒未満を保証できない。

C（正解）　正解。マルチAZ DBクラスターは2つの読み取り可能なスタンバイを持ち、通常35秒未満でフェイルオーバーする。スタンバイが読み取りを受けられるためオフロードの要件も同時に満たせる。

D　要件は満たせるが、エンジン移行に伴う検証やカットオーバーの作業量が大きい。検証を最小限にしたいという制約に照らすと最適ではない。

正解：C

A　ポーリング方式は取得位置の管理や失敗時の再開処理を自前で実装する必要があり、実行間隔の分だけ遅延も発生する。サブスクリプションフィルターを使えばこの作り込みは不要になる。

B　エージェントの配布と権限管理という運用が全アカウントに増える。またLambdaやFargateなどEC2以外のログは収集できず、既にCloudWatch Logsに集まっている資産を活かせない。

C（正解）　正解。サブスクリプションフィルターはクロスアカウント送信に対応しており、Amazon Data Firehoseがバッファリングとバックアップ用S3への配信、OpenSearchへの取り込みをマネージドで行う。アプリケーションの変更は不要である。

D　CloudTrailが記録するのはAWS APIの呼び出し履歴であり、アプリケーションが出力するログは対象外である。監査基盤の一部にはなるが今回の要件は満たせない。

正解：A

A（正解）　正解。分散トレースはリクエスト単位でサービス間の呼び出しを相関付けるため、外部API呼び出しやDynamoDBクエリなど時間を消費している区間を特定できる。間欠的な外れ値も個別のトレースとして追跡できる。

B　平均値は少数の外れ値を打ち消すため、間欠的な遅延の検出には不向きである。またサービス単体の数値からは、どの呼び出し経路で時間を消費したかまでは分からない。

C　遅いリクエストが存在することは分かるが内訳が得られない。ALBが記録するのは最前段のターゲットまでで、その先のサービス間呼び出しの時間は含まれない。

D　フローログはIPとポート単位のメタデータであり、アプリケーションの処理時間は含まれない。アプリ層のボトルネック特定には使えない。

正解：B

A　鍵の常設配布は不要になるが、記録されるのは接続APIの呼び出しのみで、セッション内で実行したコマンドは残らない。監査要件を満たせない。

B（正解）　正解。Session Managerは受信ポートも踏み台もSSH鍵も不要である。ssm・ssmmessages・ec2messagesのインターフェースエンドポイントを用意すればインターネット接続なしで到達でき、セッションログをS3やCloudWatch Logsに保存すれば操作内容の記録も残せる。

C　踏み台とSSH鍵の運用が残るため負担は減らない。NATゲートウェイは外向き通信のためのもので、運用者からの接続経路にはならない。

D　回線の敷設コストと期間が大きく、鍵管理の運用も社内製品側に残る。要件に対して過大な変更であり最小の運用負荷とは言えない。

正解：D

A　誤報は減るが実際の異常の検知も遅れ、見逃しのリスクが増える。複数のアラームが個別に飛ぶという問題にも手が入っていない。

B　実現は可能だが、判定ロジックとスケジューラを自前で保守することになり運用負荷はむしろ増える。マネージドの機能で代替できる。

C　宛先が減るだけで通知の本数も誤報も変わらない。判定方法と相関付けという根本原因が手つかずのままである。

D（正解）　正解。異常検出は曜日や時間帯の周期性を学習した予測バンドで判定するため、夜間バッチの正常な上昇を誤報にしない。複合アラームは子アラームの論理式で評価し、通知を代表アラームに集約できる。

正解：C

A　いずれもサーバー側の指標であり、クライアント側のJavaScriptエラーや描画時間、地域ごとの回線品質は分からない。画面が白くなる事象も捉えられない。

B　バックエンド内部の分析には有効だが、ブラウザ側の体感や地域差の可視化はできない。無トラフィック時の外形監視にもならない。

C（正解）　正解。RUMは実ユーザーの表示速度やJSエラーを地域・ブラウザ別に収集し、Syntheticsはトラフィックの有無に関係なく合成トランザクションで可用性とレイテンシーを継続測定する。

D　到達性と応答コードの確認にとどまる。ログインのような複数ステップの導線や、ブラウザ上の描画時間の計測はできない。

正解：B

A　テナント数が数千あるためメトリクスとアラームの数が爆発し、コストも管理も破綻する。メトリクスは高カーディナリティの軸には向かない。

B（正解）　正解。Contributor Insightsはログのフィールドを軸に上位N件を時系列で継続集計する仕組みで、高カーディナリティな軸でも偏りをほぼリアルタイムに把握できる。DynamoDB向けの組み込み機能も併用できる。

C　事後のアドホック分析としては有効だが、人が気づいて実行するまで状況が分からず、常時の可視化という要件を満たさない。

D　日次バッチでは悪化している最中の把握に間に合わない。長期傾向の分析には使えるが、リアルタイムの上位特定という目的には合わない。

正解：D

A　レイテンシーは改善するが、キューと集約関数という新しい構成要素の運用が増える。埋め込みメトリクスを使えば追加のコンポーネントは不要である。

B　呼び出し回数は減るが同期呼び出しは残る。加盟店IDのような軸を落とすと分析の目的そのものを満たせなくなる。

C　メモリ増強で計算は速くなるが、外部API呼び出しのネットワーク待ち時間は基本的に短縮されない。単価が上がるためコストも改善しない。

D（正解）　正解。EMFはログ出力だけで済むため同期API呼び出しが不要になり、実行時間とPutMetricDataのコストを削減できる。ログには全ディメンションが残るので、後からLogs Insightsで詳細に分析できる。

正解：A

A（正解）　正解。Patch Managerは承認ルールに沿って対象を判定し、メンテナンスウィンドウで自動適用してコンプライアンスとして集計する。ハイブリッドアクティベーションを使えばオンプレミスのサーバーも同じ仕組みで管理できる。

B　イミュータブルな更新自体は有効だが、オンプレミスと状態を持つサーバーは手作業のまま残る。統一したコンプライアンスレポートも得られない。

C　スケジューラとログ集計を全台で保守することになり、承認ルールや凍結期間の制御もすべて作り込みが必要になる。運用負荷は下がらない。

D　Inspectorは検出までを担い、適用は行わない。手作業のパッチ運用が残るため負荷とばらつきの問題は解決しない。

正解：C

A　リホストは最速だが、OSパッチ適用・製品バージョンアップ・バックアップといった運用作業がそのまま残る。要員2名・製品知識なしという制約下では運用負荷が下がらず、ライセンス保守費も継続して発生する。

B　リプラットフォームは内部構造の理解と動作検証を前提とする。製品知識を持つ技術者がおらず6か月しかない状況では、ベンダーサポート外の構成になるリスクもあり現実的でない。

C（正解）　正解。カスタマイズがなく同等機能のSaaSが存在する場合、リパーチェス（Drop and Shop）が最短かつ運用負荷が最小になる。インフラ・パッチ・可用性の責任がベンダー側へ移り、少人数体制でも維持できる。

D　リファクタは7つの戦略の中で最も工数と期間を要し、業務要件の再定義も必要になる。6か月の期限と要員2名という制約に対して明らかに過剰な選択で、期限内に完了できない。

正解：A

A（正解）　正解。AWS Application Discovery Service の Agentless Collector はOVAとしてvCenterに配置され、ゲストOSへ何も入れずにVM単位の構成情報・CPU/メモリ使用率・通信状況を収集できるため、変更管理の制約を回避できる。AWS Migration Hub はアカウントごとにホームリージョンを1つだけ設定し、そこへ検出データと全リージョンの移行進捗が集約される仕組みになっている。

B　エージェントは最も詳細なデータを得られるが、導入自体に3か月以上かかるという前提の制約を無視している。評価フェーズが移行全体のクリティカルパスになってしまう。

C　Migration Hub のホームリージョンはアカウントにつき1つだけで、複数設定はできない。集約の前提が成立せず、俯瞰したいという要件も満たせない。

D　AWS Config はAWSリソースの構成管理サービスでオンプレミスのVMインベントリ収集用途ではない。CloudWatchエージェントも結局ゲストOSへの導入が必要で、変更管理の制約を解決しない。

正解：B

A　イメージ取得のたびにサーバー停止が必要で、300台分の取得と変換にも時間がかかる。取得時点以降の更新データが失われるため、停止時間15分以内という要件を満たせない。

B（正解）　正解。MGNは各サーバーへ導入したレプリケーションエージェントがブロックレベルで継続的に差分を送り続けるため、カットオーバー時の作業は最終同期とインスタンス起動のみとなり、分単位の停止時間に収まる。テスト起動は隔離サブネット上でレプリケーションを継続したまま何度でも実行でき、ソース環境にも本番にも影響を与えない。アプリケーションの改修も不要である。

C　AWS Server Migration Service は提供を終了しており、後継の AWS Application Migration Service (MGN) に統合されている。現在は新規の移行に利用できない。

D　DataSyncはファイル/オブジェクト転送のサービスで、OS設定やレジストリを含むサーバー全体のリフト＆シフトには向かない。300台分の環境再構築は工数も停止時間も膨らむ。

正解：D

A　Transfer Acceleration はエッジロケーション経由で長距離の遅延を改善する機能であり、拠点側の物理帯域100Mbpsそのものは増えない。所要日数は依然として500日規模のままとなる。

B　1Gbpsであれば計算上40日前後で転送できるが、専用線の敷設には予算も開通リードタイムも必要という前提条件に反する。一度きりの移行のために回線を新設するのはコスト面でも妥当でない。

C　VPNは物理回線100Mbpsの上に構成されるため、トンネルを増やしても総帯域の上限は変わらない。暗号化オーバーヘッドの分だけ実効スループットはむしろ低下する。

D（正解）　正解。500TB = 500 × 1024^4 × 8 ≒ 4.4×10^15 ビット、100Mbps = 1×10^8 bps で割ると約4.4×10^7 秒 ≒ 509日となり、3か月では到底終わらない。物理搬送するSnowball Edgeが唯一現実的で、複数台を並行して使えば数週間で完了する。

正解：B

A　600台分の実使用率を反映しない手入力の見積もりは過大サイジングになりやすく、オンプレミス側も減価償却・電力・保守・ライセンスを網羅できない。比較の妥当性を役員に説明できない。

B（正解）　正解。Migration Evaluator（旧TSO Logic）は実測の使用率とライセンス状況をもとに、オンプレミスの総保有コストとAWS上の推奨インスタンス・想定コストを並べたビジネスケースレポートを生成する。経営層向けの投資判断資料を短期間で用意する用途に合致する。

C　Compute Optimizer はすでにAWS上で稼働しているEC2やLambdaなどのメトリクスを分析するサービスで、まだ移行していないオンプレミスサーバーの評価には使えない。

D　Trusted Advisor は既存のAWSアカウント内の未使用リソースなどを指摘するもので、オンプレミスのTCOは対象外。移行前の比較資料の根拠にはならない。