AWS 認定 ソリューションアーキテクトアソシエイトサンプル問題を解説します

こんにちは。一気に秋も深まり、赤や黄色で樹々が彩られるようになりましたね。

前回に引き続いて、AWS認定のサンプル問題をもとに、深堀をして解説しようと思います。

今回は、AWS 認定のまずとっておけ！的な資格である「ソリューションアーキテクト アソシエイト」のサンプル問題を取り上げます。

AWS認定とは

AWS 認定は、クラウドの専門知識を検証し、専門家が需要の高いスキルを強調し、組織が AWS を使用してクラウドイニシアチブにおける効果的で革新的なチームを構築するのに役立ちます。個人やチームが独自の目標を達成できるように、役割と専門分野ごとに設計したさまざまな認定試験から選択します。

AWS 認定は領域やレベルごとに分けられ、本校執筆時点(2020/09)では12の認定資格が存在しています。

• レベル
• 基礎
• アソシエイト(中級ととらえてください)
• プロフェッショナル(上級ととらえてください)
• 専門知識(対象分野に特化した高度な認定)
• 領域
• 全般
• ソリューション
• 開発
• 運用
• DBや機械学習といった専門分野

表にまとめると以下の通りです。

#	レベル	認定名
1	基礎	クラウドプラクティショナー
2	アソシエイト	ソリューションアーキテクトアソシエイト
3	アソシエイト	デベロッパー アソシエイト
4	アソシエイト	SysOps アドミニストレーター アソシエイト
5	プロフェッショナル	ソシューションアーキテクト プロフェッショナル
6	プロフェッショナル	DevOps エンジニア プロフェッショナル
7	専門知識	高度なネットワーク
8	専門知識	Alexaスキルビルダー
9	専門知識	セキュリティ
10	専門知識	機械学習
11	専門知識	データ分析
12	専門知識	データベース

AWS認定ソリューションアーキテクトアソシエイト

試験の概要や出題割合などは、以下の試験ガイドをご確認ください。
https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf

サンプル問題を解いてみよう

それでは、サンプル問題を確認していきましょう。

サンプル問題：https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Sample-Questions.pdf

※以降、Markdown記載に合わせて、サンプル問題のABCDを1234と置き換えています。

第1問

問題文

カスタマーリレーションシップマネジメント (CRM) アプリケーションは、アプリケーションロードバランサーの背後にある複数のアベイラビリティーゾーンの Amazon EC2 インスタンスで実行されます。

これらのインスタンスの 1 に障害が発生した場合、どうなりますか?

1. ロードバランサーが、障害が発生したインスタンスへのリクエストの送信を停止する。
2. ロードバランサーが、障害が発生したインスタンスを終了する。
3. ロードバランサーが、障害が発生したインスタンスを自動的に置換する。
4. ロードバランサーが、インスタンスが置換されるまで、504 ゲートウェイ タイムアウト エラーを返す。

回答

１

解説

問題文で、「これらのインスタンスの 1 に障害が～」という記載は、「これらのインスタンスの 1つに障害が～」ととらえていただくとよいでしょう。

1. ロードバランサーは障害が発生した(ヘルスチェックに失敗した)インスタンスに対してリクエスト送信を停止しますので、適当といえます。
2. ロードバランサーは、インスタンスに対してヘルスチェックを行いますが、インスタンスそのものを終了(削除)したりはしないので、不適当です。
3. ロードバランサーは、インスタンスに対してヘルスチェックを行いますが、自動的に置き換える(終了(削除)や起動)といったことはしないので、不適当です。
4. これらのインスタンスの1(つ)に障害が発生した場合とあるので、この環境はロードバランサーに複数のインスタンスが存在しており1つ以上は正常に稼働している考えられます。
   504 エラーが発生する条件はいくつかありますが、1つ以上のインスタンスが稼働している状況では、インスタンスの置き換え完了するまでというのを理由に 504 エラーを返すというのは誤りですので、不適当です。

第2問

問題文

企業は非同期処理を実行する必要があり、分離されたアーキテクチャの一部として Amazon SQS を持っています。同社は、ポーリングリクエストからの空の応答件数を最小限に抑えることを望んでいます。

空の応答を減らすために、ソリューションアーキテクトは何をすべきでしょうか?

1. キューの最大メッセージ保存期間を増やす。
2. キューのリドライブポリシーの最大受信数を増やす。
3. キューの既定の可視性タイムアウトを増やす。
4. キューの受信メッセージ待機時間を延長する。

回答

４

解説

空の応答を減らすためには、SQS へメッセージを取得するポーリングリクエスト実施時に、空の場合には指定秒数の間、待機するロングポーリング機能(待たない場合は、ショートポーリング)を使用します。

1. 「最大メッセージ保存期間」は SQS の設定にある「メッセージ保持期間」のことであると考えます。これは、メッセージがキューに格納されてから削除されるまでの期間の設定です。空の応答を最小限に抑えることにつながりません。そのため、不適当です。
2. 「最大受信数」から、デッドレターキュー(DLQ) の最大受信数の設定であると考えます。 DLQ は何かしらの理由で配信されなかった(処理されなかった)メッセージが格納されているキューのことです。空の応答を最小限に抑えることにつながりません。そのため、不適当です。
3. 可視性タイムアウトは既に処理などを行っているメッセージを、別のインスタンス(メッセージを取得し処理を行うインスタンス)などから見えなくする期間を設定するものです。そのため空の応答を最小限に抑えることにつながらないので不適当です。
4. 受信メッセージ待機時間を設定、延長することでロングポーリングを使用するようになります。メッセージが空の場合の待ち時間が長くなりますので、ポーリングリクエストの実行回数が減ります。結果として空の応答を減らすことにつながるので適当といえます。

第3問

問題文

企業は現在、オンプレミスアプリケーションのデータをローカルドライブに格納しています。最高技術責任者は、データを Amazon S3 に保存してハードウェアコストを削減したいのですが、アプリケーションに変更を加えたくないと考えています。レイテンシーを最小限に抑えるには、頻繁にアクセスするデータをローカルで使用できるようにする必要があります。

ローカルストレージのコストを削減するためにソリューションアーキテクトが実装できる、信頼性の高い耐久性のあるソリューションとは何ですか?

1. ローカルサーバーに SFTP クライアントをデプロイし、SFTP 用 AWS 転送を使用してデータを Amazon S3 に転送する。
2. キャッシュ型ボリュームモードで設定された AWS Storage Gateway のボリューム型ゲートウェイをデプロイする。
3. ローカルサーバーに AWS DataSync エージェントをデプロイし、S3 バケットを転送先として設定する。
4. 保管型ボリュームモードで設定された AWS Storage Gateway ボリューム型ゲートウェイをデプロイする。

回答

２

解説

「Amazon S3 に保存してハードウェアコストを削減したい」、「アプリケーションに変更を加えたくない」、「レイテンシーを最小限に抑える」、「頻繁にアクセスするデータをローカルで使用できるようにする」といった要件から、ローカルドライブと同等の方式で読み書きを行いつつ Amazon S3 へのデータ格納をしてもレイテンシーを抑えるソリューションを選択すればよいです。

1. アプリから見てデータ(ファイル)へのアクセス方式が変わってしまうため要件を満たせません。そのため不適当です。
2. キャッシュ型ボリュームモードの AWS Storage Gateway の場合は、データ自体は S3 に書き込まれます。頻繁にアクセスするデータはキャッシュとしてローカルに保持されます。ストレージ容量については、必要なキャッシュ容量分だけ確保します。アプリ側からはアクセス方式も変わりません。このことから要件を満たせるため、適当といえます。
3. 「AWS DataSync エージェント」は Amazon S3 や Amazon EFS に対してデータ転送を行いますが、データ同期を目的とした機能であるので、使用容量分だけローカル側にストレージ容量が必要になってしまい「ハードウェアコストを削減したい」という要件を満たせません。そのため、不適当です。
4. 保管型ボリュームモードの AWS Storage Gateway の場合は、ローカル側に必要な分だけストレージ容量を確保し、書き込まれたデータは非同期で Amazon S3 にバックアップされます。アプリからみると iSCSI で接続されたストレージに対して読み書きを行うので、アクセス方式は変わりません。しかし、ローカル側に必要な分だけストレージ容量が必要になってしまい「ハードウェアコストを削減したい」という要件を満たせません。そのため、不適当です。

第4問

問題文

企業は、複数のアベイラビリティーゾーン全体にわたる VPC で、公開されている 3 層 Web アプリケーションを実行します。プライベートサブネットで実行されているアプリケーション層の Amazon EC2 インスタンスでは、インターネットからソフトウェアパッチをダウンロードする必要があります。ただし、インターネットから直接インスタンスにアクセスすることはできません。

インスタンスが必要なパッチをダウンロードできるようにするために実行すべきアクションはどれですか? (2 つ選択してください。)

1. パブリックサブネットで NAT ゲートウェイを構成する。
2. インターネットトラフィック用の NAT ゲートウェイへのルートがあるカスタムルートテーブルを定義し、それをアプリケーション層のプライベートサブネットに関連付ける。
3. Elastic IP アドレスをアプリケーションインスタンスに割り当てる。
4. インターネットトラフィック用のインターネットゲートウェイへのルートがあるカスタムルートテーブルを定義し、それをアプリケーション層のプライベートサブネットに関連付ける。
5. プライベートサブネットで NAT インスタンスを設定する。

回答

１，２

解説

パッチを当てたい Amazon EC2 インスタンスはプライベートサブネットにいるという情報と、プライベートサブネットにいる Amazon EC2 インスタンスがどのようにすればインターネットに出ていけるか、どんな設定をすればよいのかがわかれば、解ける問題です。

1. プライベートサブネットのインスタンスがインターネットと通信するには、 NAT ゲートウェイもしくは NAT インスタンスを経由する必要があるので、この選択肢は適当といえます。
2. NAT ゲートウェイや NAT インスタンスを作成・起動させただけでは、プライベートサブネットの Amazon EC2 インスタンスはインターネットと通信できません。ルートテーブルに通信経路の設定を行うことでインターネットと通信できるようになるので、この選択肢は適当といえます。
3. プライベートサブネットのインスタンスに Elastic IP アドレスを割り当てることは可能ですが、プライベートサブネットはインターネットゲートウェイへの通信経路設定がルートテーブルにされていません。また、選択肢4と組み合わせてしまうと、プライベートサブネットではなくなってしまうため、不適当です。
4. この設定をしていますと、プライベートサブネットがパブリックサブネットになってしまいます。セキュリティなどを考慮してのインスタンス配置、ネットワーク設定といった設計が崩れてしまうため、不適当です。
5. NAT インスタンスをプライベートサブネットに設定してもインターネットへの通信設定がルートテーブルにされていないためインターネットと通信できません。そのため、不適当です。

第5問

問題文

ソリューションアーキテクトは、2 週間の会社のシャットダウン中に実行不要の Amazon EC2 インスタンスのコストを節約するためのソリューションを設計したいと考えています。インスタンスで実行されているアプリケーションは、インスタンスが動作を再開するときに必要なデータをインスタンスメモリ (RAM) に格納します。

インスタンスをシャットダウンして再開するために、ソリューションアーキテクトが推奨すべきアプローチはどれですか?

1. インスタンスストアボリュームにデータを格納するようにアプリケーションを変更する。ボリュームを再起動中に再接続する。
2. インスタンスを停止する前に、インスタンスのスナップショットを作成する。インスタンスの再起動後にスナップショットを復元する。
3. 休止状態が有効になっているインスタンスでアプリケーションを実行する。シャットダウンの前にインスタンスを休止状態にする。
4. 停止する前に、各インスタンスのアベイラビリティーゾーンをメモしておく。シャットダウン後に、同じアベイラビリティーゾーン内のインスタンスを再起動する。

回答

３

解説

Amazon EC2 インスタンスを再開し、必要なデータをインスタンスメモリ (RAM) に格納するには、「休止状態」をサポートしているインスタンスを使用し、インスタンスの停止時に「休止状態」にする必要があります。

1. インスタンスストアボリューム(エフェメラルディスク)に格納したデータは、インスタンスの停止時に消えてしまいます。そのため、不適当です。
2. インスタンスのスナップショットを Amazon Machine Image(AMI) と考えますが、AMI にはメモリの状態まで保存しません。そのため、インスタンスが動作を再開するときに必要なデータをインスタンスメモリ (RAM) に格納できません。よって、不適当です。
3. 選択肢の記載の通り、休止状態が有効なインスタンスでアプリケーションを実行し、シャットダウンの前にインスタンスを休止状態にすることで、再開時に必要なデータがインスタンスメモリ (RAM) に格納されます。よって、適当といえます。
4. アベイラビリティゾーンをメモしておき、再起動時にそのアベイラビリティゾーンで再起動しても、インスタンスメモリ (RAM) にデータを格納できません。そのため、不適当です。

第6問

問題文

企業は、VPC で Amazon EC2 インスタンスでモニタリングアプリケーションを実行する予定です。インスタンスへの接続は、そのプライベート IPv4 アドレスを使用して行われます。ソリューションアーキテクトは、アプリケーションに障害が発生して到達不能になった場合に、トラフィックをスタンバイインスタンスに迅速に送信できるソリューションを設計する必要があります。

これらの要件を満たすアプローチはどれですか?

1. プライベート IP アドレスのリスナーで構成されたアプリケーションロード バランサーをデプロイし、ロードバランサーにプライマリインスタンスを登録する。障害発生時に、インスタンスを登録解除してセカンダリインスタンスを登録する。
2. カスタム DHCP オプションセットを構成する。プライマリインスタンスで障害が発生したときに、同じプライベート IP アドレスをセカンダリインスタンスに割り当てるように DHCP を設定する。
3. プライベート IP アドレスで設定されたインスタンスにセカンダリエラスティックネットワークインターフェイス (ENI) を接続する。プライマリインスタンスが到達不能になった場合は、ENI をスタンバイインスタンスに移動する。
4. Elastic IP アドレスをプライマリインスタンスのネットワークインターフェイスに関連付ける。障害発生時にElastic IP とプライマリインスタンスの関連付けを解除し、セカンダリインスタンスに関連付ける。

回答

３

解説

ポイントは Amazon EC2 インスタンスのプライベート IPv4 アドレスを使って通信していること、障害発生時にはトラフィックをスタンバイインスタンスへ迅速に送信できる必要があることです。この点を踏まえると接続元はプライマリインスタンスやセカンダリインスタンスを意識せず接続したい、つまり、プライマリインスタンスからセカンダリインスタンスに切り替わっても、アクセスに使用するプライベート IPv4 は変わらないと思われるので、答えが見えてきます。

1. ロードバランサーを使うというのはある意味正しいですが、プライマリインスタンスの登録を解除し、セカンダリインスタンスを登録するというのは試してみるとわかりますが、通信可能な Healthy 状態になるまで思いのほか時間がかかります。
   また、要件ではAmazon EC2 インスタンスのプライベート IPv4 アドレスを使うということですが、アプリケーションロードバランサーを使うとアプリケーションロードバランサーの IPv4 アドレスを使うことになり(厳密には、アプリケーションロードバランサーの DNS 名を名前解決して得られる IPv4 アドレス)、選択肢としては不適当と考えます。
   また、アプリケーションロードバランサーは負荷に応じて機能を提供するノードが増えたり減ったり切り替わったりするため、その都度、IP アドレスも更新されてしまいます。
2. DHCP オプションセットで選択肢にあるような プライマリインスタンスで障害発生時にセカンダリインスタンスに同じ IP アドレスを割り当てるような設定はできません。そのため、不適当です。
3. セカンダリエラスティックネットワークインターフェイス (ENI) であれば、割り当てるインスタンスを変更するのも迅速に行えるため、使用するローカル IPv4 アドレスを変更することなく、接続することが可能です。よって、適当といえます。
4. Elastic IP アドレスはパブリック IP アドレスを固定化して利用するためのサービスです。要件はプライベート IPv4 アドレスとあるため不適当です。

第7問

問題文

分析会社は、ユーザーにサイト分析サービスを提供する予定です。このサービスでは、ユーザーの Web ページに、同社の Amazon S3 バケットに対して認証済み GET リクエストを行う JavaScript スクリプトが含まれている必要があります。

スクリプトを正常に実行するため、ソリューションアーキテクトが行うべきことは何ですか?

1. S3 バケットでクロスオリジンリソース共有 (CORS) を有効にする。
2. S3 バケットで S3 バージョニングを有効にする。
3. ユーザーにスクリプトの署名付き URL を提供する。
4. パブリック実行権限を許可するようバケットポリシーを設定する。

回答

１

解説

ユーザーの Web ページ に含まれている JavaScript から Amazon S3 バケットに対して認証済み GET リクエストを行うことが要件になっています。Web ページが格納されているユーザーの Web サーバから分析会社の Amazon S3 バケットへ JavaScript でアクセスできる必要があります。Web ブラウザには HTML ファイルや JavaScript ファイルを読み込んだ Web サーバー(オリジンサーバー)と異なるサーバーからデータを取得すること(クロスドメイン通信)を拒否する仕組みがあります。つまり、CORS(Cross-Origin Resource Sharing)の設定が必要ということです。

1. 上記の通り、JavaScript からアクセスするには、 CORS の設定が必要で、 S3 バケットにはその機能があります。よって適当といえます。
2. S3 バージョニングの設定は S3 バケット上に格納したオブジェクトのバージョン管理を行い、必要に応じて復元するための機能です。そのため、要件とは関係がないため、不適当です。
3. 署名付き URL を利用することで S3 上のオブジェクトにアクセスできるようにはなりますが、その URL は有効期限が定められており、JavaScript に含めるには不適切であると考えます(有効期限が切れるたびに更新しないとならない)。もちろん、異なるサーバーからのアクセスは、やはりCORSの有効化が必要です。そのため、不適当です。
4. パブリック実行権限と同じ名前の機能は S3 の設定にはありませんので、パブリック読み取り許可、パブリック書き込み許可のことだと考えてみますが、やはり、JavaScript からのアクセスであれば、 CORS の有効化が必要になるため、不適当です。

第8問

問題文

企業のセキュリティチームは、クラウドに保存されているすべてのデータを、オンプレミスに保存された暗号化キーを使用して保管時に必ず暗号化する必要があります。

これらの要件を満たす暗号化オプションはどれですか。(2 つ選択してください。)

1. Amazon S3 管理キー (SSE-S3) でサーバー側の暗号化を使用する。
2. AWS KMS 管理キー (SSE-KMS) でサーバー側暗号化を使用する。
3. 顧客が提供するキー (SSE-C) でサーバー側暗号化を使用する。
4. クライアント側の暗号化を使用して、保存時の暗号化を提供する。
5. Amazon S3 イベントによってトリガーされる AWS Lambda 関数を使用し、顧客のキーを使ってデータを暗号化する。

回答

３，４

解説

オンプレミスに保存された暗号化キーを使用するのが要件として記載されています。つまり、クライアント(オンプレミス)側で暗号化キーを管理して暗号化するものが要件を満たす暗号化オプションになります。

1. この選択肢では、鍵の生成や管理が、Amazon S3となってしまい、オンプレミス側に保存された暗号化キーを使いません。よって、不適当です。
2. この選択肢では、鍵の管理が、Amazon KMS となってしまい、オンプレミス側に保存された暗号化キーを使いません。よって、不適当です。
3. 顧客が提供するキー、つまり、今回でいえばオンプレミス側に保存されたキーを使用して、サーバー側暗号化するので，適当です。
4. クライアント側(オンプレミス側)の暗号化ということなので、適当といえます
5. オンプレミスに保存されたキーで暗号化できないので不適当です。

第9問

問題文

規制要件により、企業はアクセスログを最低 5 年間維持する必要があります。一度保存された後のデータにアクセスすることはほとんどありませんが、必要に応じて 1 日前に通知することでアクセスできなければなりません。

これらの要件を満たす最もコスト効率の高いデータストレージソリューションは何ですか?

1. Amazon S3 Glacier ディープアーカイブストレージにデータを保存し、ライフサイクルルールを使用して 5 年後にオブジェクトを削除する。
2. データを Amazon S3 標準ストレージに保存し、ライフサイクルルールを使用して 30 日後に Amazon S3 Glacier に移行する。
3. Amazon CloudWatch ログを使用してデータをログに保存し、保存期間を 5 年に設定する。
4. Amazon S3 標準頻度の低いアクセス (S3 Standard-Ia) ストレージにデータを保存し、ライフサイクルルールを使用して 5 年後にオブジェクトを削除する。

回答

１

解説

5年間保持する必要があり、一度保存されるとほとんどアクセスがない。しかし、依頼などを受けたら1日でデータにアクセスできないとならない。逆に言えば、取り出すまで1日の猶予はあるということです。

これらの要件を満たすものが正解です。

いったん、 Amazon S3 の各ストレージクラスや仕様について、確認しましょう。
Amazon S3 は S3 1ゾーン以外は格納されたオブジェクトを複数のアベイラビリティゾーンに複製し、アベイラビリティゾーンに障害があってもオブジェクト破損にならないように設計されています。

• S3 標準
  • 高頻度アクセスの汎用ストレージ用
• S3 Intelligent - Tiering
  • 未知のアクセスパターンのデータ、またはアクセスパターンが変化するデータ用
  • アクセスパターンに応じて自動的に高頻度アクセス用の階層や低頻度アクセス用の階層にオブジェクトを移動させ、コスト低減が可能
• S3 標準 - 低頻度アクセス
  • 長期間使用するが低頻度アクセスのデータ用
  • S3 標準と比較してストレージ利用料が安価
• S3 1ゾーン - 低頻度アクセス
  • 長期間使用するが低頻度アクセスのデータ用、1つのアベイラビリティゾーンのみ使うため、S3 標準 - 低頻度アクセスと比較すると安価
  • オブジェクトが格納されているアベイラビリティゾーンで障害が発生するとデータ破損の可能性がある
• S3 Glacier
  • アーカイブ用とのストレージクラスのため、利用料が S3 標準 や 各種低頻度アクセスと比較して安価
  • データの取得に時間がかかり、数分から数時間の3種類で設定が可能
  • 長さによって取り出しにかかる料金に差がある
• S3 Glacier ディープアーカイブ
  • 7～10 年以上といった長期アーカイブおよびデジタル保存用
  • 1年に 1～2 回程度しか取り出さないデータ保存用途のため、 S3 Glacier よりもさらに安価
  • 取り出し時間は 12 時間以内

その他、各機能の詳細は以下の Web サイトにまとめられています。
https://aws.amazon.com/jp/s3/storage-classes/

料金についてはこちら。
https://aws.amazon.com/jp/s3/pricing/

1. 選択肢の中で最もコスト効率が高く、要件をすべて満たしているため適当といえます。
2. Amazon S3 Glacier へ移すのを30日待つ必要がないこと、5年後に削除するようになっていないなどから、不適当です。
3. Amazon Cloudwatch ログにデータを格納すると、検索しやすいといったメリットはありますが、保存量に対する課金額が Amazon S3 や Amazon S3 Glacier と比較して高価なため、コスト効率が低いと言わざるを得ません。そのため、不適当です。
4. 一見よさそうですが、Amazon S3 Standard-Ia は Amazon Glacier と比較すると、コスト効率が低いと言わざるを得ません。そのため、不適当です。

第10問

問題文

企業は、データ処理ワークロードを実行するためにリザーブドインスタンスを使用しています。
夜間のジョブは通常、実行に 7 時間かかり、10 時間以内に完了する必要があります。同社は、毎月末に需要が一時的に増加するため、現在のリソースの容量ではジョブが制限時間以内に終わらないと予想しています。
いったん開始された処理ジョブは、完了する前に中断できません。
同社は、できる限りコスト効率の高い容量を提供できるソリューションを実装したいと考えています。

ソリューションアーキテクトは、これを達成するために何をすべきでしょうか?

1. 需要の高い期間中にオンデマンドインスタンスをデプロイする。
2. 追加インスタンス用に 2 つ目の Amazon EC2 予約を作成する。
3. 需要が高まる期間中にスポットインスタンスを展開する。
4. ワークロードの増加をサポートするために、Amazon EC2 予約のインスタンスのインスタンスサイズを増やす。

回答

１

解説

問題から推察するに、毎晩夜間ジョブが走り、完了まで7時間、長くても10時間以内に完了しないとならないという制限がある。その処理に対しては、リザーブドインスタンス(RI)で処理能力を確保している。しかし、毎月末には需要がひっ迫し、現状の処理能力では、制限時間内に完了しない恐れがあるので、コスト効率が高い方法で対処できるものを選択します。

1. 必要な時に必要なだけ利用できるクラウドらしい対処の仕方です。適当といえます。
2. 月末のみに必要な処理能力に対して、 リザーブドインスタンスを追加するのはやりすぎです(仮に月末2日だけ処理が重いとしても、年間で24日分であり費用対効果が期待できません)。よって、不適当です。
3. オンデマンドインスタンスより安価なため、一見、適当であるように思えますが、問題文の中に「いったん開始された処理ジョブは、完了する前に中断できません」とあるので、落ちてしまう可能性があるスポットインスタンスは適しません。よって、不適当です。
4. 現状の処理能力で月末以外は問題がないため、リザーブドインスタンスのインスタンスサイズを大きくする(増やす)のは月末以外に余剰が生まれてしまうため不適当です。

サンプル問題以外の学習リソース

様々な学習リソースが用意されています。

以下はその一例です。

• AWS 公式の模擬問題
• AWS 認定サイトから受験可能です。
• 認定準備ワークショップに参加
• AWS が定期的に開催しているワークショップに参加して学ぶことが可能です
• 試験対策テキスト
• 徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書
• AWS認定資格試験テキスト　AWS認定 ソリューションアーキテクト-アソシエイト
• この１冊で合格！　AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集
• AWS認定アソシエイト3資格対策~ソリューションアーキテクト、デベロッパー、SysOpsアドミニストレーター~
• 最短突破 AWS認定ソリューションアーキテクト アソシエイト 合格教本

まとめ

このソリューションアーキテクトアソシエイトは前回お伝えしたクラウドプラクティショナーがリリースされる前は、AWS エンジニアの入門的資格と捉えている方が多かった印象があります。
AWSを利用するシステムを設計構築している SE の皆様におかれましては、ある程度の経験を積んだら挑戦してみてはいかがでしょうか。

記載されている会社名、製品名、サービス名、ロゴ等は各社の商標または登録商標です。