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

正解：C

A　パブリック公開は防げるが、特定の組織外アカウントへ明示的に許可されたクロスアカウントアクセスは遮断できない。

B　発見的で事後対応になるため、遮断の網羅性と即時性を保証できない。数千バケットの継続運用としても負荷が高い。

C（正解）　正解。SCPは自組織のプリンシパルにしか効かないが、RCPは組織内のリソース側に上限を課すため、組織外プリンシパルからのアクセスも一括で遮断できる。

D　既存のバケットポリシーを上書きして影響が出るうえ、新規作成バケットへの追随や手動変更の差し戻しに弱い。

正解：B

A　設定漏れが最長で四半期のあいだ放置される。新規アカウントにも自動では適用されず、要件の網羅性を満たさない。

B（正解）　正解。バックアップポリシーは階層継承され新規アカウントにも自動適用される。タグによるリソース選択、保持期間、クロスリージョンコピーもプラン内で定義できる。

C架空　このようなサービスは存在しない。組織全体へのバックアップ設定の配布は、Organizationsのバックアップポリシーが担う。

D　実現は可能だがテンプレート管理とドリフト対応の負担が大きい。専用のバックアップポリシーがある以上、最適とは言えない。

正解：C

A　対応が速くなるだけで、非準拠リソースの作成自体は発生する。デプロイ時点でブロックするという要件を満たさない。

B　暗号化の有無にかかわらずRDSの作成が止まり、正当なデプロイまで阻害する。要件に対して粒度が粗すぎる。

C（正解）　正解。プロアクティブコントロールはCloudFormation Hooksを用い、リソースがプロビジョニングされる前に評価してブロックする。作成後の検出や修復が不要になる。

D　誤検知時にデータ損失を招く危険な運用であり、作成そのものを止める要件も満たさない。

正解：A

A（正解）　正解。組織証跡は新規アカウントにも自動適用され、メンバーアカウント側からは停止も削除もできない。保管先を別アカウントに分離し、オブジェクトロックとSCPで保護すれば改ざん耐性を確保できる。

B　新規アカウントへの追随が手作業になるうえ、各アカウントの管理者が自分の証跡を停止・削除できてしまう。

C　転送設定が各アカウント任せで停止可能であり、証跡そのものの改ざん耐性も担保されない。

D　Configは構成変更の記録であり、API操作の完全な監査ログにはならない。既定のイベント履歴は90日で失われる。

正解：B

A　収集基盤の実装と保守が必要で運用負荷が高い。ルール変更のたびに全アカウントへ配布する仕組みも別途必要になる。

B（正解）　正解。組織アグリゲータで全アカウント・全リージョンの評価結果を集約でき、組織適合パックでルール群を一括配布・更新できる。委任管理者により管理アカウントを日常運用から外せる。

C　Security Hubの多くのコントロールはConfigの記録に依存する。社内独自基準の表現にもConfigルールや適合パックが必要である。なお、この機能を提供する従来のSecurity Hubは2025年10月にAWS Security Hub CSPMへ改称され、同名の新しい統合サービスAWS Security Hub（2025年12月GA）と併存している。

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（正解）　正解。サービスクォータの多くはリージョンごとに独立して適用されるため、プライマリ側で引き上げていてもスタンバイ側には反映されない。引き上げは申請から承認まで時間がかかるので、切り替えの当日ではなく平常時に済ませておく必要がある。Service Quotasはクォータに対する使用率を表示し、対応しているクォータではしきい値に近づいたときに通知するCloudWatchアラームを作成できるため、訓練や実際の切り替えで台数を伸ばしたときにも上限への接近を早期に把握できる。

B　Auto Scalingグループの最大容量は、そのグループが起動してよい台数の設定にすぎず、アカウントのクォータとは別物である。クォータが不足していれば、最大容量を大きくしてもインスタンスの起動そのものが失敗する。Elastic IPアドレスのように、Auto Scalingの設定では手当てできない上限も残る。

C　クォータの引き上げは申請してから審査・承認までに時間がかかり、即時に反映される保証はない。リージョン規模の障害が起きている最中に承認を待つことになり、RTOを満たせなくなる。障害対応の手順ではなく、平常時に済ませておくべき作業である。

D　サービス制限のチェックは使用率が上限の80%に達したときに警告する仕組みであり、平常時は縮小された規模でしか稼働していないスタンバイ側では上限に近づかない。切り替え時に必要となる規模との差は現れないままである。仮に検出できたとしても、そこから引き上げを申請する後手の対応になる。

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

正解：A

A（正解）　正解。セルベースアーキテクチャでは1セルの容量が全体の数%に収まるため、変更起因の障害の影響範囲がセル数分の1に限定される。段階的な展開とベイクタイムにより異常を早期に検知して以降の展開を止められる。

B　切り戻しは速くなるが、切り替えの瞬間に全ユーザーが新環境へ移るため、影響範囲は依然としてリージョン全体である。数%に抑えるという要件を満たさない。

C　事前検証は有効だが、本番固有の条件で発生する問題は残る。検証をすり抜けた変更は一括適用されるため全ユーザーへ波及する。

D　設定変更の安全な配信には有効だが、コードやインフラの変更へ適用できる範囲は限られる。分離境界そのものを作る施策ではない。

正解：D

A　毎回接続を張ると接続数の急増をむしろ悪化させ、レイテンシも増える。DNSキャッシュの問題に対処できても、接続数上限の問題は残る。

B　インスタンスエンドポイントは特定のインスタンスを指すため、フェイルオーバー後は自前で切り替える仕組みが必要になり、改修量も運用リスクも増える。

C　容量のスケーリングは接続数上限をある程度緩和するが、フェイルオーバー時に古い接続が保持される問題は解決しない。コードの改修も必要になる。

D（正解）　正解。RDS Proxyは接続をプールして再利用するため同時実行の急増を吸収でき、フェイルオーバー時にはプロキシ側で新しいライターへ接続を張り替える。アプリ側の改修は接続先の変更のみで済む。

正解：B

A　自動化はできるが、AZ単位のグレー障害を自前のメトリクスで正しく判定するのは難しく、検知ロジックと誤検知対策の保守が必要になる。定期的な検証も別に作り込むことになる。

B（正解）　正解。ゾーンオートシフトはAWSがAZの障害を検知した際に自動でトラフィックを退避し、回復後に戻す。プラクティスランは週次で短時間の退避を実施し、1AZを失った状態で耐えられるかを継続的に検証する。

C　耐性の検証には役立つが、実際の障害発生時に自動で退避する仕組みにはならない。夜間帯の着手遅れという課題が解決しない。

D　インスタンス単位の置換であり、AZ全体に及ぶ障害では置換先も同じAZになりうる。ゾーン単位の退避にはならない。

正解：A

A（正解）　正解。ウォームスタンバイでは常に縮小構成が稼働しているため、切り替えはセカンダリの昇格とスケールアウトのみで完了し、RTO 15分に収まる。Aurora Global DatabaseのRPOは通常1秒程度で要件を満たし、費用も本番のフルコピーより大幅に低い。

B　バックアップ&リストアに相当する。コストは最小だがRPOはスナップショット間隔（最大24時間）、RTOは数時間規模となり、いずれの要件も満たさない。

C　マルチサイトアクティブ-アクティブであり要件自体は満たすが、費用が本番と同等になり3割以内という制約に反する。平常時にトラフィックを流さない前提とも矛盾する。

D　パイロットライトに相当する。データのRPOは満たすが、切り替え時にフリート全体を新規に起動するため起動と暖機に時間がかかり、RTO 15分の達成は不確実である。

正解：C

A　RTOとRPOは要件より大幅に良いが、レプリカインスタンスを常時稼働させるためコストが継続的に発生する。コスト最小化の要件に照らすと過剰である。

B　Elastic Disaster Recoveryはサーバーのブロックレベルのレプリケーションであり、RDSやS3のようなマネージドサービスは対象外である。用途が合致しない。

C（正解）　正解。バックアップ&リストア戦略であり、恒常的に稼働するリソースがないためコストが最小になる。RPOは日次のバックアップ間隔、RTOは復元とIaCによる再構築の時間となり、翌営業日という要件に収まる。

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　ログアウトの頻度は下がるが原因は残り、インスタンス障害やAZ障害では依然としてセッションが失われる。スケールイン保護は伸縮性とコスト効率も損なう。

B　共有自体は可能だが、ファイルロックとネットワーク遅延によりセッションの読み書きが遅く、頻繁に更新されるセッションストアの用途には適さない。

C（正解）　正解。セッションを外部の共有ストアへ移すことでEC2がステートレスになり、どのインスタンスでも任意のリクエストを処理できる。マルチAZ配置と組み合わせればAZ障害でもサービスを継続できる。

D　マルチアタッチはio1/io2かつ同一AZ内に限られ、クラスタ対応ファイルシステムも必要になる。AZ障害への対策にはならない。

正解：C

A　同時に追加する台数は増えても、1台あたり8分かかる起動時間は変わらないため立ち上がりの遅れは解消しない。

B　クールダウンは連続したスケーリングの間隔にすぎず、起動時間は短縮されない。猶予期間を縮めるとウォームアップ中のインスタンスが異常と判定される危険がある。

C（正解）　正解。ウォームプールは初期化を終えたインスタンスを停止状態で保持するため、スケールアウト時の待ち時間を大幅に短縮できる。周期的な需要に対しては予測スケーリングが事前に容量を確保する。

D　要件で避けたいとされているコスト増を招く。広告配信直後のような予測しにくい急増にも対応できない。

正解：B

A　コールドスタートの短縮には有効だが、アカウント全体の同時実行数の奪い合いは解決しない。バッチが枠を使い切る状況は変わらない。

B（正解）　正解。予約済み同時実行は関数ごとの上限であると同時に専用枠でもあるため、バッチの消費量を抑えつつ重要な関数の枠を確保できる。バッチは制限された枠内で時間をかけて処理される。

C　上限を上げてもバッチが先に使い切るという構造は同じであり、規模が大きくなれば同じ障害が再発する。分離の仕組みが必要である。

D　実行時間の短縮は多少効くが、バッチが枠を占有している状況では効果が限定的で、根本的な分離にはならない。

正解：D

A　一時しのぎにはなるが、接続数はクライアント側の増加に比例するため再び上限に到達する。メモリを接続の維持に消費する点も非効率である。

B　接続の総数が減るわけではないため、急増時には同じく上限に達する。全アプリケーションの改修も必要で最小の変更にならない。

C　参照負荷の分散には有効だが、書き込み側の接続枯渇は解消しない。振り分けのためのアプリケーション改修も発生する。

D（正解）　正解。RDS Proxyは多数の短命な接続を集約して少数のDB接続に多重化するため、Lambdaが急激にスケールしても上限に達しにくい。フェイルオーバー時の切り替え時間も短縮される。

正解：A

A（正解）　正解。キューが流量を平準化し、消費速度を外部APIの許容量に合わせられる。ジッター付きの指数バックオフは再試行の同期を防ぎ、デッドレターキューが手作業の再投入を不要にする。

B　再試行の総量が増えて外部APIへの負荷をさらに高める。呼び出し側のスレッドや実行時間も浪費し、状況を悪化させる典型的な対処である。

C　総量は減るが全クライアントが同じ間隔で再試行するため波が揃い、回復した直後に再び殺到する。間隔をずらすジッターがない点が問題である。

D　429を返している相手に対して並列度を上げれば、スロットリングが悪化するだけで解決にならない。相手側の障害を誘発する恐れもある。

正解：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が唯一現実的で、複数台を並行して使えば数週間で完了する。なお、Snowball Edgeは2025年11月に新規注文の受付を終了し、2026年12月末で全商用リージョンでのサポート終了が告知されている（後継はオンライン転送がDataSync、物理搬送がAWS Data Transfer Terminalやパートナーソリューション）。試験ガイドには引き続き掲載されているため出題を維持している。

正解：B

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

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

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

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

正解：A

A（正解）　正解。DataSyncはタスク単位で帯域上限（スロットル）とスケジュールを設定でき、2回目以降は差分のみを転送する。転送データのチェックサム検証も標準機能として備えており、要件をすべて満たす。

B　rsyncでも差分同期は可能だが、帯域制御・並列化・再試行・検証レポートをすべて自作・運用する必要がある。マネージドサービスで満たせる要件をわざわざ内製する妥当性がない。

C　File Gatewayはハイブリッドなファイルアクセスを提供する仕組みで、既存ファイラー上にある40TBの一括移送手段ではない。クライアントの向き先変更も移行期間中はオンプレミスが正という前提と衝突する。

D　毎晩の差分程度であれば夜間200Mbpsで十分転送でき、物理搬送は遅延とオペレーション負荷を増やすだけになる。Snowballは初回一括のような大容量向けの手段である。

正解：D

A　保管型ボリュームはプライマリデータをオンプレミスに保持し続けるため、テープ運用の置き換えにはならず、バックアップソフトのテープジョブ定義もそのままでは使えない。

B　ディスクバックアップ構成へ切り替えることになり、既存のテープジョブ定義とリテンション管理を作り直す必要がある。運用手順を変更したくないという要件に反する。

C　AWS Backupは既存のバックアップソフトウェアを置き換える方向の選択で、ジョブ定義や監査済みの運用手順を維持できない。テープライブラリの互換性も提供しない。

D（正解）　正解。Tape Gatewayは既存のバックアップソフトウェアからiSCSI接続の仮想テープライブラリ（VTL）として見えるため、監査済みのジョブ定義もリテンションポリシーも変更せずにそのまま利用できる。アーカイブ済みの仮想テープはS3 Glacier Deep Archive相当の階層に保管され、物理テープの外部倉庫保管費用とテープ交換作業の両方を削減できる。

正解：C

A　共有テナンシーでは物理サーバーが専有されず、物理コア単位のライセンス条項を満たせない。vCPU数からの集計も監査で求められる物理コアの根拠にならない。

B　Dedicated Instanceはハードウェアが他アカウントと共有されない点は満たすが、物理ソケット数やコア数の可視性・特定ホストへの固定ができないため、物理コア単位のBYOL要件には不足する。

C（正解）　正解。Dedicated Hostは物理ソケット/コアが可視化され、インスタンスを特定ホストへ固定できるため、物理コア単位・専有要件のBYOLに対応できる。License Managerのライセンス設定でコア上限を定義すれば、超過起動の防止と消費状況の追跡が可能になる。

D　運用としては簡素になるが、保有済みライセンスを活用したいという前提を無視しており、コスト面でも二重負担や資産の切り捨てが発生する。設問は既存ライセンスの持ち込み方を問うている。

正解：B

A　デバイスの発送・コピー・返送・取り込みには往復で数週間かかるうえ、期間中の差分追随は別の仕組みが必要になる。専用に確保した1Gbps回線が期限内に十分間に合うため、物理搬送を選ぶ理由がない。

B（正解）　正解。300TB = 300 × 1024^4 × 8 ≒ 2.64×10^15ビット、実効帯域は1Gbps × 0.8 = 8×10^8 bps。2.64×10^15 ÷ 8×10^8 ≒ 3.30×10^6秒 ≒ 38日となり、8週間（56日）の期限に収まる。DataSyncなら初回転送後に差分同期をスケジュール実行でき、追加データにも追随できる。

C　すでに移行専用のDirect Connect接続が確保されているのに、あえて品質の保証されないインターネット経路を使う理由がない。データ転送料も増え、帯域の予測も立てにくくなる。

D　保管型ボリュームはオンプレミスにプライマリデータを保持し続ける構成で、データセンターからの完全移行手段ではない。S3のオブジェクトとして解析データを配置したいという目的にも合わない。

正解：D

A　File GatewayはS3をバックエンドとするため、NTFSのフルセットのACL・クォータ・DFS名前空間といったWindowsファイルサーバー固有の機能を再現できない。オブジェクトストレージ前提の制約も残る。

B　EFSはNFS（POSIX）ベースのファイルシステムでSMBおよびNTFS ACLをネイティブにサポートしない。Windowsファイルサーバーの移行先としては要件を満たさない。

C　機能要件は満たせるが、OSパッチ・可用性構成・バックアップ・容量拡張をすべて自社運用することになる。マネージドサービスで同等機能が提供される以上、運用負荷の観点で最適解ではない。

D（正解）　正解。FSx for Windows File ServerはSMB、NTFS ACL、ユーザークォータ、DFS名前空間をネイティブにサポートする。既存のオンプレミスADへセルフマネージドAD参加として直接joinさせることも、AWS Managed Microsoft ADとの信頼関係を介すこともできるため、同じユーザーアカウントでのアクセスが継続できる。DataSyncはSMB転送時にACLと所有者情報を保持したまま移送できる。