AWS SAA サンプル問題

正解：B

A　アクセスキーは長期認証情報そのもので、要件に真っ向から反する。ユーザーデータはメタデータサービス経由で参照できるため、キーの露出リスクも高い

B（正解）　正解。インスタンスメタデータ経由で自動ローテーションされる一時認証情報が配布され、インスタンス上に静的キーを置かずに済む

C　Parameter Storeを読むための認証情報が別途必要になるうえ、取得後もアクセスキー自体は長期認証情報のまま。問題を先送りしているだけ

D　ルートユーザーのアクセスキーはそもそも作成すべきでない最悪の選択。権限も無制限で最小権限の原則に反する

正解：C

A　AWSが完全に管理するため運用は最も楽だが、キーポリシーによるアクセス制御や個別の使用監査ができない。「使用を追跡したい」要件を満たせない

B　リクエストごとにキーを送信する方式で、キーマテリアルの保管・配布は完全に自社責任になる。「自社で管理したくない」に反する

C（正解）　正解。キーマテリアルはKMSが保護しつつ、自動キーローテーションの有効化、キーポリシーによる制御、CloudTrailでの使用記録がすべて可能

D　クライアントサイド暗号化はキー管理・ローテーション・監査をすべて自前で実装する必要があり、運用負荷が最も高い

正解：D

A　インターネット経由の通信になるうえ、NATゲートウェイは時間課金に加えて処理データ量にも課金される。大量転送では最も高くつく

B　プライベート通信は実現できるが、ENIの時間課金と処理データ量課金が発生する。S3はゲートウェイ型が使えるため、コスト面で最適ではない

C　インスタンスをインターネットに露出させることになり、要件に反する

D（正解）　正解。ゲートウェイエンドポイントはS3とDynamoDBのみ利用でき、エンドポイント自体の追加料金がかからない。VPC内から直接AWSネットワーク経由で到達する

正解：A

A（正解）　正解。SCPはメンバーアカウント内のIAMプリンシパルが持てる権限の上限を定義するガードレールで、アカウント側の管理者でも上書きできない

B　アカウント内の管理者が新しいロールを作れば制限を回避できるうえ、200アカウント分の運用負荷が膨大。強制力がない

C　Configは作成後の検出と修復であり、作成そのものを防げない。予防的統制ではなく発見的統制

D　Access Analyzerはリソースポリシーによる外部共有の検出が目的で、リージョン制限の強制機能はない

正解：C

A　AWSマネージドキーはサービス側が自動作成・管理するもので、専有ハードウェアでも単一テナントでもない。制御権も最も弱い

B　Secrets Managerは認証情報などのシークレット保管が目的で、暗号化キーを保護するHSMではない。そもそもSecrets Manager自体がKMSに依存する

C（正解）　正解。CloudHSMは単一テナントの専有HSMを提供し、FIPS 140-2 レベル3検証済み。AWSはHSM内のキーにアクセスできず、ユーザーがキーの完全な管理権を持つ

D架空　AWS Key Rotation Managerというサービスは存在しない。KMSのキーローテーション機能を独立サービスと誤認させる選択肢

正解：B

A　Shieldはネットワーク層・トランスポート層のDDoS攻撃を対象とする。HTTPペイロードの内容を検査してSQLインジェクションを判定する機能はない

B（正解）　正解。レイヤー7のWebアプリケーションファイアウォールで、SQLインジェクションやXSSのマネージドルールグループを持ち、CloudFrontやALBに直接関連付けられる

C　NACLはIPアドレスとポートによるステートレスなフィルタリングのみ。リクエストボディの内容は判定できず、送信元IPが変わると追随できない

D　VPCの入出力トラフィックを検査するファイアウォールで、CloudFrontディストリビューションには関連付けられない。Webアプリ向けのL7保護にはWAFが適切

正解：C

A　5,000人×アカウント数のIAMユーザー管理が必要で運用負荷が最大。パスワードの二重管理は退職時の失効漏れなど重大なリスクを生む

B　Cognitoはアプリケーションのエンドユーザー向け認証サービス。AWSマネジメントコンソールへの従業員アクセス管理は本来の用途ではない

C（正解）　正解。ADを信頼できるIDソースとして接続し、許可セットを使って複数アカウントへのシングルサインオンを一元管理できる。AWS側でのユーザー作成は不要

D架空　AWS Identity Federation Gatewayというサービスは存在しない。IDフェデレーションという概念を独立サービスに見せかけた選択肢

正解：A・C・E

A（正解）　正解。REST APIではLambdaオーソライザーで任意のJWTの署名・有効期限・クレームを検証し、認可結果をキャッシュしてバックエンドに到達する前に拒否できる

B　プライベートAPI向けの制御であり、インターネット公開のAPIでは前提が異なる。加えてJWTの検証も呼び出し回数の制限も実現できない

C（正解）　正解。使用量プランは呼び出し元ごとに1日/週/月あたりのクォータとレート上限を設定でき、取引先単位の流量管理をAPI Gateway側で完結できる

D　レイテンシとバックエンド負荷を下げる性能・コスト施策であり、認証・流量制限・攻撃遮断のいずれの要件も満たさない

E（正解）　正解。マネージドルールグループを適用すればSQLインジェクションやクロスサイトスクリプティングなどのリクエストをアプリケーションに届く前に遮断できる

F　流量の上限を外す方向の設定であり、要件の「取引先ごとの上限」と正反対。攻撃を受けた際の影響も拡大する

正解：A・D

A（正解）　正解。ルートユーザーは削除も権限の縮小もできないため、認証を多要素にすることが最も効果的な保護になる。管理アカウントのルートは組織全体に影響するため、ハードウェアMFAなど強度の高いデバイスの利用が推奨される

B　ルートユーザーにはIAMのアイデンティティベースポリシーをアタッチできない。ルートは元からアカウント内のすべての操作が可能であり、ポリシーで権限を定義するという考え方自体が当てはまらない

C　SCPは組織の管理アカウントには一切適用されない。メンバーアカウントのルートには効果があるが、管理アカウントのルートを守る手段にはならない

D（正解）　正解。ルートのアクセスキーは漏えい時の被害が最大級で、しかも代替手段（IAMロールやIdentity Center）が常にあるため保持する理由がない。存在する場合は速やかに削除する

E　Secrets Managerが自動ローテーションできるのはデータベース認証情報などのシークレットであり、AWSアカウントのコンソールパスワードは対象外。保管したところでルート自体の保護強度は上がらない

正解：C

A　リードレプリカは非同期レプリケーションのためデータ損失の可能性があり、昇格も手動操作が必要。自動フェイルオーバーの要件を満たさない

B　バックアップは復旧の最後の砦だが、リストアには長い時間がかかる。数分以内の自動復旧という要件には遠く及ばない

C（正解）　正解。別AZのスタンバイへ同期レプリケーションが行われ、AZ障害時にRDSがDNSエンドポイントを自動的に切り替える。データ損失なく数分以内に復旧できる

D　処理能力は上がるが可用性はまったく向上しない。単一AZのままではAZ障害で停止する

正解：B

A　ピークに合わせた固定サイズは平常時の無駄が大きく、想定を超えるスパイクでは結局取りこぼす。根本的な緩衝機構がない

B（正解）　正解。キューがバッファとして働き、生産者と消費者のスループット差を吸収する。スパイクを平準化する疎結合の基本パターン

C　SNSはプッシュ型で、購読側が処理しきれなくてもメッセージが押し込まれる。バッファリングにはならず、SNS+SQSの組み合わせが必要

D　ALBにレート制限機能はなく、仮に制限できたとしても超過した注文を捨てることになる。「注文を失わない」要件に反する

正解：C

A　最も安価だが、インフラを一から構築するためRTOが数時間から数日かかる。RTO 2時間の要件を満たせないと問題文が明示している

B　RPO/RTOはほぼゼロにできるが、本番同等のリソースを二重に持つため維持コストが最大。「コストを抑えたい」要件に対して過剰

C（正解）　正解。データ層のみ常時稼働させることでRPOを小さく保ちつつ、コンピュート層は災害時に起動するため平常時コストを大きく抑えられる

D　RTOはさらに短くなるがアプリ層も常時課金されるため、パイロットライトよりコストが高い。RTO 2時間で足りるなら過剰投資になる

正解：A

A（正解）　正解。レイヤー4で動作し超低レイテンシと極めて高いスループットを実現する。AZごとに静的IPを持ち、Elastic IPの割り当てにも対応する

B　レイヤー7のHTTP/HTTPS向けで、TCPそのものは扱えない。IPアドレスは可変のDNS名で提供され、静的IPを持てない

C　サードパーティの仮想アプライアンス（ファイアウォールやIDS）を透過的に挿入するためのもので、アプリケーションのフロントエンド用途ではない

D　旧世代のロードバランサーで新規利用は推奨されない。NLB相当の性能や静的IPも提供しない

正解：D

A　同一AZ内の冗長化ではAZ障害時に両方が停止する。またRoute 53のフェイルオーバーはDNS TTLの分だけ切り替えが遅れる

B　Auto Recoveryは同一AZ内で同じインスタンスを復旧する機能。AZ障害には対応できず、負荷に応じた台数の増減も行わない

C　復旧が手動になるため可用性が人的対応に依存する。自動スケーリングの要件も満たさない

D（正解）　正解。ALBが健全なAZのインスタンスにのみ振り分け、ASGが不足分を他AZで自動補充する。負荷に応じたスケールアウト・インも同時に実現できる

正解：B

A　標準キューはベストエフォート順序で、少なくとも1回配信のため重複が起こりうる。可視性タイムアウトは処理中の再配信を防ぐだけで順序も重複も解決しない

B（正解）　正解。FIFOキューはメッセージグループ単位で厳密な順序を保証し、重複排除IDにより5分間の重複送信を排除する。まさにこの要件のための機能

C　標準トピックは順序保証も重複排除も行わない。順序と重複排除が必要ならSNS FIFOトピックとSQS FIFOキューの組み合わせが必要になる

D　Firehoseは配信先へのバッファリング付きロードが目的で、順序保証も重複排除も提供しない。取引処理のワークフローには適さない

正解：C

A　DLMはEBSスナップショットとEBS-backed AMIが対象。RDSやDynamoDB、EFSは管理できず、一元化の要件を満たさない

B　実現は可能だが、リトライやエラー処理、保持期間の削除処理まで自前で作り込むことになり運用負荷が高い。マネージドサービスがある場面での車輪の再発明

C（正解）　正解。EBS、RDS、DynamoDB、EFSなど多数のサービスを横断して、単一のプランでスケジュール・保持期間・監査レポートを一元管理できる

D　Configが記録するのは構成情報の履歴であってデータのバックアップではない。データの復元はできない

正解：A

A（正解）　正解。既定のEC2ヘルスチェックはインスタンスのステータスチェックしか見ない。ELBヘルスチェックを有効にすると、ターゲットグループの判定で異常なインスタンスが終了・置換される

B　登録解除時に既存接続の完了を待つ時間の設定で、異常インスタンスの検知や置換には関係しない

C　猶予期間は起動直後にヘルスチェックを無視する時間。0にすると起動途中のインスタンスが誤って終了されかねず、今回の原因とは無関係

D　台数は増えるがハングしたインスタンスはグループ内に残り続け、ALBがそこへ振り分ける限り障害は解消しない

正解：C

A　gp3を含む通常のEBSボリュームは1インスタンスにしかアタッチできない。マルチアタッチ対応のio2でもクラスター対応ファイルシステムが別途必要で、POSIX共有の要件には合わない

B　S3はオブジェクトストレージでPOSIXのファイルロックやパーミッションのセマンティクスを持たない。既存のファイルI/Oを前提としたレガシーアプリはそのまま動かせない

C（正解）　正解。EFSは複数インスタンスから同時にマウントできるフルマネージドNFSで、POSIXセマンティクスを備え、容量は自動的に伸縮する

D　インスタンスストアは停止でデータが消える揮発性ストレージ。rsyncによる事後同期では同時書き込みの一貫性も保証できない

正解：A

A（正解）　正解。キーによるアクセスパターンに対して規模を問わず1桁ミリ秒の性能を出し、オンデマンドモードならトラフィック変動に自動で追随してキャパシティ計画も不要

B　リレーショナルDBは複雑なクエリに強いが、数百万同時接続への水平スケールは苦手。接続数の急増にはインスタンスサイズの変更が必要になる

C　列指向の分析用データウェアハウスで、大量の集計クエリ向け。単一行の低レイテンシな読み書きには極めて不向き

D　グラフデータベースで、関係のたどり方が中心のクエリに最適化されている。キーによる単純なルックアップに使うのは過剰かつ不適切

正解：B

A　静的ファイルの配置は近くなるが、ユーザーを最寄りバケットへ導く仕組みを別途作る必要があり、動的コンテンツやAPI応答は速くならない

B（正解）　正解。エッジロケーションで静的コンテンツをキャッシュしつつ、動的リクエストもAWSバックボーン経由でオリジンへ転送するため全体のレイテンシが改善する

C　複数リージョンに実体がある場合に最寄りへ誘導する機能。単一リージョンにしか環境がない現状では改善効果がない

D　ALBはリージョン内のAZにしか配置できず、他国にエンドポイントを置くことはできない

正解：C

A　SQSはメッセージを1つのコンシューマーが取得すると他からは見えなくなる。複数用途での並行読み取りや、読み終えたデータの再処理ができない

B　S3などへのロードに特化した配信サービスで、複数のリアルタイムコンシューマーがストリームを独立に読む用途には対応しない

C（正解）　正解。ストリーム内のデータは保持期間中は消費されても残り、複数のコンシューマーが自分の位置を持って読める。保持期間の設定により再処理も可能

D　ファンアウトはできるがメッセージを保持しないため、過去24時間分の再処理ができない。順序保証もなく高スループットのテレメトリには不向き

正解：D

A　IOPSがボリュームサイズに比例し、4TBでは12,000 IOPS程度が上限。60,000 IOPSには届かない

B　大きなブロックのシーケンシャル読み書きに最適化されたHDDで、IOPS性能は極めて低い。データベースのランダムI/Oには不適

C　アクセス頻度の低いデータ向けの最も安価なHDD。性能要件を到底満たさない

D（正解）　正解。IOPSをサイズと独立してプロビジョニングでき、単一ボリュームで数十万IOPSとサブミリ秒レイテンシに対応する。I/O集約型データベース向けの選択肢

正解：B

A　読み取りは分散できるがRDS for MySQLのリードレプリカは最大5台で、レプリケーション遅延も相対的に大きい。ストレージも上限を見て手動で拡張する必要がある

B（正解）　正解。最大15台のAuroraレプリカを共有ストレージ層から低遅延で読み取らせ、リーダーエンドポイントで負荷分散できる。ストレージは10GB単位で自動拡張し、フェイルオーバーも高速

C　パッチ適用、バックアップ、フェイルオーバーをすべて自前で運用することになり、運用負荷が最も高い

D　MySQL互換という前提が崩れ、SQLベースのアプリケーションを全面的に書き換える必要がある。移行コストが要件に見合わない

正解：A

A（正解）　正解。Redisはリスト、ハッシュ、ソート済みセットなどの豊富なデータ構造を持ち、レプリケーションと自動フェイルオーバー、永続化に対応する

B　Memcachedは単純なキーバリューのみでレプリケーションを持たない。ノード障害でそのノードのキャッシュは失われ、要件を満たさない

C　DAXはDynamoDB専用のキャッシュ層で、リレーショナルデータベースの前段には配置できない

D　CloudFrontはHTTPレスポンスのエッジキャッシュであり、アプリケーションとDBの間のクエリ結果キャッシュとしては機能しない

正解：B

A　参照頻度が下がった後も最も高い保存単価を払い続けることになる。削除の手動運用もミスの元になる

B（正解）　正解。Standard-IAはミリ秒単位の即時取得を保ちながら保存単価が安い。失効アクションで削除も自動化でき、要件と料金体系が一致する

C　保存単価はさらに安いが、取り出しに数分から数時間かかる。「参照時は即時取得が必要」という要件を満たさない

D　バージョニングは誤削除対策であり、現行オブジェクトのアクセス頻度に応じたコスト最適化にはならない。むしろ保存容量が増える

正解：D

A　柔軟だが単価が最も高い。中断耐性のあるワークロードでこれを選ぶのは機会損失

B　常時稼働するベースライン向け。夜間のみ動く変動ワークロードでは稼働していない時間も課金され、かえって割高になる

C　特定AZのキャパシティを確保する仕組みで、料金はオンデマンド単価のまま。使用していなくても課金され、削減にはならない

D（正解）　正解。中断耐性があり期限に余裕のあるバッチ処理はスポットの理想的なユースケースで、オンデマンド比で最大90%の削減が見込める

正解：C

A　50Mbpsで150TBを送ると理論上でも約280日かかる。帯域が制約である以上、ネットワーク転送では期限に間に合わない

B　帯域は解決するが、専有接続の物理開通には通常数週間から数か月かかり、一度限りの移行のために契約するのはコスト面でも不合理

C（正解）　正解。回線帯域に依存せず大容量を物理輸送でき、数週間という期間に収まる。ペタバイト未満のオフライン移行における標準的な選択肢

D架空　AWS Bulk Transfer Applianceというサービスは存在しない。Snowballファミリーの名称を知らないと選んでしまう架空の選択肢

正解：A

A（正解）　正解。アクセスパターンを監視して自動的に階層を移動し、頻繁/低頻度階層間の移動に取り出し料金がかからない。予測不能なアクセスに対する標準的な答え

B　保存単価は安いが取り出しごとにデータ取得料金がかかる。突然頻繁に読まれるようになった場合、Standardより高くつく可能性がある

C　さらに安価だが単一AZにしか保存されず耐久性が下がる。取り出し料金の問題も解決しない

D　ライフサイクルは日数ベースの一方向の移行しか定義できず、実際のアクセス状況に追随しない。移行リクエスト料金も無駄に発生する

正解：B

A　割引率は高いがリージョンとインスタンスファミリーに固定され、変更できない。ファミリーやリージョンが変わる可能性があるという条件と噛み合わない

B（正解）　正解。1時間あたりの支出額をコミットする方式で、インスタンスファミリー、サイズ、リージョン、さらにFargateやLambdaにも自動的に適用される。柔軟性を保ったまま最大級の割引が得られる

C　割引率はCompute Savings Plansよりわずかに高いが、特定リージョンの特定インスタンスファミリーに固定される。変更の可能性があるという条件に合わない

D　スポットは中断される前提のため、下回ってはならないベースラインキャパシティの確保には使えない

正解：C

A　フルロード中の更新差分が反映されないため、切り替え時にソースを停止する必要があり長いダウンタイムが発生する。異種エンジン間のスキーマ変換も行われない

B　SQL ServerのバックアップをPostgreSQLへリストアすることはできない。異なるエンジン間ではバックアップ形式の互換性がない

C（正解）　正解。SCTが異種エンジン間のスキーマとストアドプロシージャを変換し、DMSのCDCが切り替え直前まで変更を追随させるためダウンタイムを最小化できる

D　DataSyncはファイル/オブジェクトの転送サービスで、データベースファイルをコピーしても異種エンジンのAuroraでは読み込めない