📝 AWS SAA の練習問題

練習問題の例（体験版の 5 問）

1. 問 1・セキュアなアーキテクチャの設計

   ある会社は、EC2 インスタンスで動くアプリケーションから Amazon S3 のバケットにファイルを書き込みたいと考えています。現在はアクセスキーをアプリケーションの設定ファイルに書いていますが、セキュリティ監査で長期の認証情報をサーバーに置かないよう指摘されました。最も安全な方法はどれですか。

   1. ア アクセスキーを環境変数に移し、設定ファイルからは消す
   2. イ S3 への書き込みを許す IAM ロールを作り、インスタンスプロファイルで EC2 インスタンスに関連付ける
   3. ウ アクセスキーを暗号化した EBS ボリュームに保存する
   4. エ バケットポリシーで Principal を "*" にして、誰でも書き込めるようにする
   正解と解説を見る

   正解：イ S3 への書き込みを許す IAM ロールを作り、インスタンスプロファイルで EC2 インスタンスに関連付ける

   IAM ロールをインスタンスプロファイルで EC2 に付けると、アプリケーションは自動でローテーションされる一時的な認証情報を使えるため、長期のアクセスキーをサーバーに置く必要がありません。環境変数や暗号化したボリュームに移しても、長期のキーがサーバーにあることは変わりません。Principal を "*" にするのは、誰にでも書き込みを許すことになり危険です。

2. 問 2・弾力性に優れたアーキテクチャの設計

   ある EC サイトでは、Web 層が注文を受けると、すぐに後ろの処理サーバーへ直接送っています。セール中にアクセスが急に増えると処理サーバーが追いつかず、注文が失われることがあります。注文を失わずに、2 つの層を疎結合にする方法として最も適切なものはどれですか。

   1. ア 処理サーバーのインスタンスタイプを最大のサイズに変更する
   2. イ Web 層と処理サーバーを同じ EC2 インスタンスにまとめる
   3. ウ Amazon SQS のキューに注文を入れ、処理サーバーはキューから取り出して処理する
   4. エ Amazon CloudFront を Web 層の前に置いて、注文のリクエストをキャッシュする
   正解と解説を見る

   正解：ウ Amazon SQS のキューに注文を入れ、処理サーバーはキューから取り出して処理する

   SQS のキューを間に置くと、注文はキューに保存されるため、処理側が遅れても失われず、処理サーバーは自分のペースで取り出せます。これが疎結合の基本の形です。インスタンスを大きくしても急な増加の上限は残り、同じインスタンスにまとめると結合はむしろ強くなります。注文のような書き込みのリクエストは CloudFront でキャッシュするものではありません。

3. 問 3・高性能なアーキテクチャの設計

   ある会社は、Amazon S3 に置いた画像や動画を世界中のユーザーに配信しています。アジアやヨーロッパのユーザーから、読み込みが遅いという声が出ています。アプリケーションをほとんど変えずに、配信の遅延を減らす方法として最も適切なものはどれですか。

   1. ア Amazon CloudFront のディストリビューションを作り、S3 バケットをオリジンにする
   2. イ 各リージョンに EC2 インスタンスを立て、手作業でファイルをコピーする
   3. ウ S3 のストレージクラスを S3 標準 - 低頻度アクセスに変える
   4. エ S3 バケットのバージョニングを有効にする
   正解と解説を見る

   正解：ア Amazon CloudFront のディストリビューションを作り、S3 バケットをオリジンにする

   CloudFront は世界中のエッジロケーションにコンテンツをキャッシュするため、ユーザーに近い場所から配信でき、遅延が減ります。各リージョンに EC2 を立てて手作業でコピーするのは、運用の手間が大きくなります。ストレージクラスの変更やバージョニングは、コストや保護のための機能で、配信の速さは改善しません。

4. 問 4・コストを最適化したアーキテクチャの設計

   ある研究チームは、毎晩大量の画像を変換するバッチ処理を EC2 で動かしています。処理は小さな単位に分かれていて、途中でインスタンスが止まっても、その単位をやり直せば問題ありません。終わる時刻にも余裕があります。コンピューティングのコストを最も下げられる購入方法はどれですか。

   1. ア オンデマンドインスタンス
   2. イ Dedicated Hosts（専有ホスト）
   3. ウ 3 年の Reserved Instances（全額前払い）
   4. エ スポットインスタンス
   正解と解説を見る

   正解：エ スポットインスタンス

   スポットインスタンスは余っている EC2 の容量を大きな割引で使える購入方法で、中断されることがありますが、やり直しができて時間に余裕がある処理に向いています。オンデマンドは割引がありません。毎晩だけ動く処理に 3 年の Reserved Instances を買うと、使わない時間の分も払うことになります。Dedicated Hosts はライセンスや規制のための選択肢で、高くなります。

5. 問 5・弾力性に優れたアーキテクチャの設計

   ある会社は Amazon RDS for MySQL で本番のデータベースを動かしています。アベイラビリティーゾーン（AZ）の障害が起きても、手作業なしで短時間にデータベースが使える状態に戻るようにしたいと考えています。最も適切な構成はどれですか。

   1. ア 同じ AZ にリードレプリカを作り、障害時はアプリケーションの接続先を手で書き換える
   2. イ 毎日自動バックアップを取り、障害時はスナップショットから復元する
   3. ウ マルチ AZ 配置を有効にし、別の AZ のスタンバイへの自動フェイルオーバーを使う
   4. エ DB インスタンスのストレージを Provisioned IOPS に変更する
   正解と解説を見る

   正解：ウ マルチ AZ 配置を有効にし、別の AZ のスタンバイへの自動フェイルオーバーを使う

   RDS のマルチ AZ 配置では、別の AZ に同期レプリケーションされたスタンバイがあり、障害時は自動でフェイルオーバーされます。エンドポイントの DNS 名は変わらないので、アプリケーションを書き換える必要もありません。同じ AZ のリードレプリカは AZ 障害に耐えられず、切り替えも手作業です。スナップショットからの復元は時間がかかり、最後のバックアップ以降のデータも失われる可能性があります。

この 5 問を、答え合わせつきで解く（無料）

実技で練習する（分野ごとのコースと章）

本物と同じコマンドを打って覚えると、選択問題でも迷わなくなります。

• セキュアなアーキテクチャの設計

  • AWS CLI 第1章 雲への入口（設定と認証）（Lv1〜8）
  • AWS CLI 第5章 雲の海図（VPC）（Lv30〜35）
  • AWS CLI 第6章 雲の都の運用（IAM・ログ）（Lv36〜42）
  • AWS CLI 第7章 雲の守り人（ロールと秘密）（Lv43〜51）

• 弾力性に優れたアーキテクチャの設計

  • AWS CLI 第2章 雲の倉庫（S3）（Lv9〜16）
  • AWS CLI 第8章 雲の見張り塔（運用と監視）（Lv52〜62）

• 高性能なアーキテクチャの設計

  • AWS CLI 第4章 雲の船（EC2）（Lv23〜29）