SAA資格演習問題（無料30問）

ヒントボタン

CSV がアップロードされた「瞬間」に変換処理を開始するには、ポーリング方式とイベント駆動方式のどちらが適しているでしょうか。
四半期に 1 回しかアクセスしない長期保存データに最もコスト効率の良いストレージクラスはどれか、取り出し時間の許容度と合わせて考えてみてください。
30 日後に不要になるデータの扱いとして、保存し続ける方法と自動削除する方法のどちらがコスト最適化に寄与するかも重要な判断ポイントです。

ヒントボタン

この問題では「事前にテスト環境で検証してから本番に反映」「データ整合性の維持」「最小限の管理負担」という 3 つの要件がポイントです。
テスト期間中も本番データとの同期が途切れない仕組みはどれでしょうか。
RDS にはバージョンアップグレードのテストと切り替えを自動化するマネージド機能があります。
レプリケーションが切断されるタイミングに注目して、各選択肢を比較してみてください。

ヒントボタン

この問題では「業務に必要な操作のみ許可」と「意図しないアクセスの防止」が求められています。
不正操作を事後的に検出するだけで「防止」の要件を満たせるか考えてみましょう。
認証情報の共有や過剰な権限付与は、AWS のセキュリティベストプラクティスでどう扱われているでしょうか。
社内エンジニアの AWS リソース管理に最も適した AWS のアイデンティティ管理の仕組みは何かを整理してみてください。

ヒントボタン

この問題では「購入済みの作品のみ視聴可能にする」というユーザー単位・コンテンツ単位のアクセス制御が求められています。
CloudFront にはエンドユーザーのアクセスを制御する仕組みと、オリジンへのアクセス経路を制御する仕組みがありますが、それぞれの役割の違いを考えてみましょう。
また、各作品が「単一のメディアファイル」であることは、個別ファイル向けの制御と複数ファイル一括の制御のどちらが適切かを判断するヒントになります。さらに、署名付き URL は「発行時にアプリケーションが購入状況を判定し」「利用時は CloudFront が署名と有効期限のみを検証する」という役割分担で動いている点も押さえておきましょう。

ヒントボタン

この問題には大きく3つの要件があります。即時アクセスが必要な期間とアーカイブ期間の使い分け、ルートユーザーでも削除できない仕組み、そして複数AZによる高い耐久性です。
S3 オブジェクトロックには2つのモードがありますが、ルートユーザーの操作を制限できるのはどちらでしょうか。
また、ストレージクラスごとの AZ 冗長性の違いにも注目してみてください。単一 AZ のクラスで「最大限の復元力」は実現できるでしょうか。

ヒントボタン

Session Manager（EC2 インスタンスへのセキュアなリモートアクセスサービス）自体が持つログ出力の組み込み機能について考えてみましょう。

ヒントボタン

問題文では「バックアップソフトウェアと運用手順をそのまま継続利用する」ことが求められています。
既存のテープバックアップソフトウェアは、どのようなプロトコル・インターフェイスでテープライブラリと通信しているでしょうか。
そのインターフェイスをクラウド側で再現できるサービスはどれか、という観点で選択肢を比較してみてください。
NFS やオブジェクトストレージへの直接保存では、テープとしての認識が維持できるかどうかがカギです。なお、iSCSI はブロック単位（ディスクやテープの生データ単位）でデバイスをやり取りするプロトコルで、NFS や SMB のようなファイル単位で共有するプロトコルとは異なります。テープ機器をそのままエミュレートする VTL は、このブロックレベルで動作する iSCSI だからこそ実現できる、という点を押さえておくと整理しやすいです。

ヒントボタン

この問題では「保存時の暗号化（サーバーサイド暗号化）」が求められています。
「転送時の暗号化（HTTPS）」や「アクセス制御（ACL）」とは別の概念であることに注意してください。
バケットポリシーの条件キーの中で、アップロード時の暗号化ヘッダーの有無を直接評価できるものはどれでしょうか。
事前に防止する方法と事後に検出する方法では、どちらがシンプルで確実かも考えてみましょう。

ヒントボタン

スナップショットから作成された EBS ボリュームは、初回アクセス時にどこからデータを取得しているでしょうか。
その仕組みが原因で発生する遅延を「事前に」解消できる EBS の機能を思い出してみてください。
ボリュームタイプの変更やインスタンスの事前準備では、この遅延読み込みの仕組み自体は変わらない点に注目しましょう。

ヒントボタン

この問題では、データのアクセス頻度が時間とともに3段階に変化する点に注目してください。
高頻度・低頻度・ほぼ未アクセスという異なるパターンが混在する場合、手動で遷移タイミングを決めるのと、自動で最適化するのとでは、どちらがコスト効率に優れるでしょうか。
また、取得料金の有無が数兆件規模でどれほどのコスト差を生むかも考えてみましょう。さらに、S3ライフサイクルポリシーによる階層遷移自体にもオブジェクト単位の遷移リクエスト料金が発生する点が、数兆件規模ではコスト差に直結する点も押さえておきましょう。
「即座にデータを取得できる」という要件を、各ストレージクラスの取得レイテンシーと照らし合わせて検討してください。

ヒントボタン

処理時間とメモリ使用量が、サーバーレスコンピューティングサービスの制限内に収まるかどうかを確認してみましょう。（ヒント：AWS Lambda の最大タイムアウトは15分＝900秒です。90秒の処理は余裕で収まります。）
コスト効率を最優先する場合、「処理がないときにコストが発生しない」課金モデルのサービスはどれでしょうか。
常時稼働するインフラが必要な構成と、イベント駆動で必要なときだけ起動する構成のコスト差を考えてみてください。

ヒントボタン

この問題では「複数アカウント・リージョンのリソース検出」「依存関係のマッピング」「アーキテクチャ図の自動生成」「最小限の手作業」という4つの要件がポイントです。
リソースの存在を把握するだけでなく、リソース同士の関係性まで自動的に図にできるサービスやソリューションはどれでしょうか。
監査ログやセキュリティスキャンなど、本来の用途が異なるサービスを見分けることが重要です。
AWS Solutions Library で提供されている専用ソリューションに注目してみてください。

ヒントボタン

問題文の要件を整理してみましょう。「リレーショナルデータベース」「時間帯による大きなトラフィック変動」「使った分だけの課金」の3つがキーワードです。
NoSQL サービスはリレーショナルの要件を満たせるでしょうか？
固定サイズのインスタンスを常時稼働させる構成は、変動するワークロードに対してコスト効率が良いでしょうか？
負荷に応じてコンピューティングリソースが自動調整される「サーバーレス」のアプローチを持つリレーショナルデータベースがないか考えてみてください。

ヒントボタン

この問題では「SMB プロトコル」と「運用負荷の最小化」という 2 つのキーワードに注目してください。
各選択肢が対応しているプロトコル（SMB、NFS、iSCSI）は何かを確認しましょう。
さらに、フルマネージドサービスと自前構築では、運用負荷にどれほどの差が生まれるかを考えてみてください。
Windows ファイル共有に特化した AWS のマネージドサービスが存在することを思い出せるかがカギです。

ヒントボタン

この問題で使われる業務用語について、まず整理しましょう。「オンライン小売企業」はネット通販会社、「在庫集計バッチ処理」は週に一度まとめて在庫データを計算する処理のことです。EC2の「Auto Scaling グループ」は複数のサーバーを束ねて自動的に台数を調整する仕組みです。

この問題では「事前にキャパシティを確保する」「必要なキャパシティを自動で見積もる」「運用負荷を最小化する」という3つの要件がポイントです。処理量（データの量）が週ごとに変わるため、必要なサーバー台数も毎回異なります。負荷が発生してから対応するリアクティブな方式では、30分前の準備という要件を満たせません。
また、キャパシティの値を人が決める方式では、専任チームがいないという制約に引っかかります。
Auto Scaling には、過去のパターンを自動で学習して将来の需要を予測する機能があることを思い出してみてください。

ヒントボタン

この問題では「OS レベルのアクセスが必要」という点と「運用負荷を最小限に抑えたい」という点の両立が求められています。

「OS レベルのアクセス」とは、サーバーのオペレーティングシステム（Linux/Windows）に直接ログインして操作することを指します。具体的には SSH でサーバーにログインしてソフトウェアをインストールしたり、設定ファイルを直接編集したり、OS のプロセスを制御することです。

**【RDS系サービスの比較】**
| サービス | OSアクセス | マネージド機能 | 運用負荷 |
|———-|———–|—————-|———-|
| **RDS for Oracle** | × | ○ | 低 |
| **RDS Custom** | ○ | ○（制限あり） | 中 |
| **EC2自前構築** | ○ | × | 高 |

RDS Customは、内部的にはEC2インスタンス上で動作しており、そのホスト（裏側のサーバー）にSSHでアクセスできます。これにより任意のソフトウェアをインストールしながら、AWS が提供するバックアップや監視などのマネージド機能も利用可能です。

フルマネージドサービスは便利ですが、OS にアクセスできるでしょうか？
EC2 なら自由度は高いですが、少人数チームで DB 運用をすべて担えるでしょうか？
この 2 つの要件を同時に満たせる「中間的なサービス」がないか考えてみてください。

ヒントボタン

この問題のカギは「予測不能なタイミングで急増する」という条件です。
トラフィックに規則的なパターンがない場合、事前にスケジュールを組んだり過去データから予測したりするアプローチは有効でしょうか。
「今まさに起きている負荷の変化」にリアルタイムで反応できるスケーリング方式はどれかを考えてみてください。
あわせて、負荷が下がったときにコストを抑える仕組みがあるかどうかも判断のポイントです。

ヒントボタン

この問題には「静的コンテンツの高速配信」と「サーバーサイドコードの共有」という2つの要件があります。
それぞれに適したサービスを1つずつ選ぶ必要があります。
静的ファイルをグローバルに高速配信するには、どのようなキャッシュの仕組みが有効でしょうか。
また、Windows Server 環境で複数インスタンスからファイルを共有するとき、Windows がネイティブに使うファイル共有プロトコルは何かを考えてみてください。

ヒントボタン

この問題には「低レイテンシー」と「アプリケーション変更の最小化」という 2 つの要件があります。
DynamoDB の読み取りレイテンシーをミリ秒からさらに短縮するには、どのような仕組みが必要でしょうか。
また、キャッシュを導入する場合、DynamoDB と API 互換性があるかどうかがアプリケーション変更量にどう影響するか考えてみてください。

ヒントボタン

500 Mbps の回線で 600 TB を転送するのに何日かかるか、まず計算してみましょう。通信速度の単位 Mbps（Mega bits per second）はビット毎秒、データ容量の TB/MB はバイト単位なので、まず 1 Byte = 8 bits の関係を使って単位を揃えます。500 Mbps ÷ 8 = 62.5 MB/s、600 TB = 600,000 GB = 600,000,000 MB なので、600,000,000 MB ÷ 62.5 MB/s = 9,600,000 秒。これを日数に直すために 1 日 = 24 時間 × 3,600 秒 = 86,400 秒 で割ると、9,600,000 ÷ 86,400 ≈ 111 日となります。
ネットワーク帯域幅がボトルネックになる場合、AWS にはネットワークに依存しない別の転送手段があります。
**【サービス選択の判断フロー】** ①まず転送時間を計算（データ量GB ÷ 回線速度MB/s ÷ 86400 = 日数）→ ②期限を超えるなら**物理転送（Snowball）**、間に合うなら**ネットワーク転送（DataSync / Storage Gateway）**→ ③保管コスト最小化が要件なら**Glacier Deep Archive**、即時アクセスが必要なら**S3 Standard / Standard-IA**を選ぶ。Direct Connect は新規開通に数週間〜数ヶ月かかるため、短期移行案件には向きません。
長期保管のコストを最小化するには、アクセス頻度に応じた最も安価なストレージクラスを選ぶことがポイントです。
Direct Connect のプロビジョニングにかかるリードタイムも考慮してみてください。

ヒントボタン

フェイルオーバー時にダウンタイムが数分に及ぶ原因は、DB 側の切り替え時間だけでしょうか？
Aurora 自体のフェイルオーバーは通常 30 秒以内に完了します。問題文の「数分間」というギャップに注目し、アプリケーション側の DNS キャッシュ（OS や JVM が古いエンドポイントの IP を TTL 期間中保持する）や、コネクションプールが切断済み接続を抱えたまま再確立に時間を要する点に目を向けてみてください。
アプリケーションとデータベースの間に「接続を仲介するレイヤー」を置くことで、裏側の切り替えを透過的に処理できるサービスがあります。
「アプリケーションコードの大幅な変更を避ける」という要件を満たすには、エンドポイントの変更だけで導入できる方法が理想的です。

ヒントボタン

この問題では、リージョン全体の障害に備えて RTO（復旧時間目標：障害発生からサービス復旧までの許容時間）と RPO（復旧時点目標：障害時のデータ損失許容範囲）を「ともに最小限」にすることが求められています。
データベースのリージョン間レプリケーション方式として、ストレージレベルで動作するものとアプリケーションレベルで動作するものでは、ラグや昇格時間にどのような違いがあるでしょうか。
また、バックアップからの復元やバイナリログベースのレプリケーションでは、RPO や RTO がどの程度になるかを比較して考えてみてください。
Aurora が提供するリージョン間の可用性向上機能の中で、最も新しく最適化されたものはどれかがポイントです。参考として、Aurora Global Database は目安として RPO 約1秒・RTO 1分未満を実現できるとされており、他の方式（バックアップ復元、DMS、クロスリージョンリードレプリカ）と比較する際の基準になります。

ヒントボタン

DynamoDB はパスワード認証ではなく IAM ベースの認証を使うサービスです。この点を踏まえると、どの認証方式が適切か絞り込めます。
クロスアカウントアクセスで「長期認証情報」と「一時認証情報」のどちらがセキュリティのベストプラクティスに合致するか考えてみましょう。
AWS STS が発行する認証情報の特徴と、IAM ロールの信頼関係の仕組みに注目してください。

ヒントボタン

この問題では「SSH キーの廃止」「IAM による一元管理」「SSH ポート非公開」「運用負荷の最小化」という4つの要件がポイントです。
SSH プロトコル自体を使わずにシェルアクセスを実現できる AWS マネージドサービスはないか考えてみましょう。
HTTPS 経由で EC2 インスタンスと通信し、IAM で認証・認可を行える仕組みに注目してください。
踏み台ホストやカスタム基盤を構築する方式は、運用負荷の観点でどうでしょうか。

ヒントボタン

AWS KMS は暗号化キーを管理するマネージドサービスで、カスタマーマネージドキーはユーザーが完全に制御できるタイプの暗号化キーです。Lambda の環境変数暗号化では、実行時に機密情報を安全に利用できるため、データベースパスワードや API キーなどの保護に有効です。

Lambda 関数が他の AWS サービスを呼び出すとき、その権限はどのポリシーで制御されるでしょうか。
また、KMS カスタマーマネージドキーへのアクセスは、呼び出し元のポリシーだけで許可されるでしょうか。それとも、キー側のポリシーも必要でしょうか。
KMS の「二重認可モデル」を思い出し、認可が評価される2つのポイントを考えてみてください。

ヒントボタン

この問題では「ストリーミングデータの取り込み」「S3 への蓄積」「管理の手間の最小化」という3つの要件がポイントです。
まず、AWSの主なストリーミングサービスには以下があります：Amazon Data Firehose（配信に特化、超シンプル）、Kinesis Data Streams（細かい制御可能、少し複雑）、Amazon MSK（Kafkaベース、大規模向けだが管理が必要）。使い分けは「どれだけ管理したいか」で決まります。
各選択肢について、サーバーやクラスターの管理が必要かどうか、データ変換機能が本当に必要かどうかを考えてみましょう。
AWS にはストリーミングデータを宛先に自動配信することに特化した、サーバーレスのサービスがあります。
そのサービスが S3 をネイティブの配信先としてサポートしているかどうかに注目してください。

ヒントボタン

この問題では、2 つの異なる AWS アカウント間でリソースを共有する仕組みが問われています。
AWS が推奨するクロスアカウントアクセスの方法では、どのようなサービスを使って一時的な認証情報を取得するでしょうか。
「信頼ポリシー」と「権限ポリシー」の 2 つが必要になる仕組みを思い出してみてください。
最小権限の原則を守るには、長期的な認証情報と一時的な認証情報のどちらが適切かも考えてみましょう。

ヒントボタン

この問題では「アプリケーションサーバーへの負荷を最小限に抑える」ことが重要な要件です。
アップロードデータがサーバーを経由する構成と、サーバーを経由しない構成では、スケーラビリティにどのような差が生まれるでしょうか。
S3 はマネージドサービスとして自動スケールする特性を持っています。クライアントから S3 へ直接データを送る方法がないか考えてみてください。
サーバーの役割を「データの中継」ではなく「アクセス許可の発行」に限定できないかがカギです。

ヒントボタン

この問題では「アプリケーション層の高可用性・スケーラビリティ」と「データベースの読み取りパフォーマンス向上」という 2 つの要件があります。
アプリケーション層について、単一インスタンスの課題を解消するには、複数の AZ にインスタンスを分散させ、負荷に応じて自動的に台数を増減できる仕組みが必要です。
データベース層について、読み取り負荷をプライマリからオフロードするには、読み取り専用のレプリカが必要ですが、フェイルオーバー専用のスタンバイと読み取り可能なレプリカの違いに注意してください。
また、要件がマルチリージョンを求めているか、単一リージョン内で十分かを見極めることも大切です。問題文に「グローバル展開」や「災害復旧（DR）」への言及がない場合、マルチリージョン構成（Aurora グローバルデータベースなど）は要件を超えたオーバーエンジニアリングと判断し、より単純で十分な構成を優先します。

ヒントボタン

この問題では「作成を防止する」と「手順変更を最小限にする」という 2 つの要件に注目してください。
事後検出ではなく、事前に防止できる仕組みはどれでしょうか。
また、開発者が暗号化を意識しなくても自動的に暗号化される仕組みはどれでしょうか。
Organizations 環境でルートユーザーにも適用できる制御メカニズムが何かを思い出すと、正解に近づけます。