SAA-C03 の無料練習問題
AWS Certified Solutions Architect - Associate

正解はCです。アカウントBの複製先バケットのバケットポリシーでアカウントAのバッチ用ロールに書き込みを許可すると、ロールは元のアカウントの権限を保ったまま、アカウントAのバケットからの読み取りとアカウントBのバケットへの書き込みを同じ実行の中で行えます。ロール側の書き込み権限は問題文のとおり既に付与されているため、不足しているのはアカウントB側の許可だけです。Aは、ロールを引き受けると引き受けたロールの権限で動作するため、アカウントAのバケットを読み取る元の権限を同じセッションで使えず、要件に反します。Bは、複製の実行主体がアカウントBになり、バッチがアカウントAのロールで両方を扱うという前提に合いません。また、アカウントBの全プリンシパルへの読み取り付与は必要以上に広い権限です。Dは、実行主体がアカウントBのユーザーになるため、アカウントAのロールで両方のバケットを扱うという要件を満たしません。

A：信頼ポリシーでアカウントAのロールに引き受けを許可する設計自体は成立しますが、バッチがこのロールを引き受けると、そのセッションでは引き受けたロールの権限で動作します。アカウントA内のバケットを読み取るために元のロールの権限を使い続けることはできず、要件の『バッチの実行中にロールを切り替えない』に反します。

B：複製を実行する主体がアカウントBの配信基盤になるため、バッチがアカウントAのロールで両方のバケットを扱うという前提に合いません。また、このポリシーはアカウントAのバケットの読み取りを許可するもので、アカウントBのバケットへの書き込みを許可する設定ではありません。さらに、アカウントBのすべてのプリンシパルに読み取りを与えるのは必要以上に広い権限付与であり、対象を絞るべき場面で不適切です。

C：リソースベースポリシーは、そのリソースにアクセスできるプリンシパルを直接指定します。アカウントBのバケットポリシーでアカウントAのロールを指定すると、ロールを引き受けずに書き込みが可能になり、ロールは元のアカウントの権限を保ったまま動作します。アカウント間のアクセスでは両方のアカウントで操作を許可するポリシーが必要ですが、アカウントA側はロール自身の IAM ポリシーで読み取りと書き込みが既に許可されています。そのため、追加の変更はアカウントBのバケットポリシーだけで足ります。

D：要件はバッチがアカウントAの IAM ロールで両方のバケットを扱うことです。このユーザーの認証情報で処理させる設計は、実行主体をアカウントAのロールからアカウントBのユーザーへ変えてしまうため、要件を満たしません。さらに、ユーザーの認証情報をバッチに渡す必要があり、ロールを使う設計より運用上の利点がありません。

学習のポイント：複製先のバケットポリシーでアカウントAのバッチ用ロールを直接許可すると、ロールを切り替えずに両方のバケットを扱えます。ロールの引き受けでは元の権限が使えなくなる点が、誤答を見分ける鍵です。

公式ドキュメント

• access_policies-cross-account-resource-access.html
• access_policies_identity-vs-resource.html

ヒントを付けて結果をキャッシュするSQL文は、同じクエリが繰り返し実行され、実行コストが大きく、保存した結果を保持期間のあいだ返しても鮮度の要件に反しないものを選ぶ。本問では保存結果は保存時点から12時間保持され、保持期間の経過でしか入れ替わらない。Cの研修コース一覧は、全社員が同じ結果を取得する重いクエリである。月曜日の始業時に返りうる保存結果は日曜日の夜以降に保存されたもので、金曜日17時の更新より後の内容なので、要件を満たす。よって対象になる。Dの部署別の受講完了率集計は、結合と集計を伴う重い処理で、誰が開いても結果が同じため繰り返し実行される。午前9時台に返りうる保存結果は前日の21時台以降に保存されたものだが、前日の20時から午前2時までは開かれないため、バッチ完了後に保存された結果に限られる。前夜の結果で足りるという要件を満たすので、対象になる。Aの個人の受講履歴は反復性も実行コストもあるが、同じ社員が1日に何度も開くため、登録前に保存された結果が保持期間内に残り、登録直後に開くと登録前の履歴が返るので不適切である。Bのキーワード検索は索引のない列の検索で重い処理ではあるものの、検索語の大半が一度しか使われず再利用されにくいため、削減効果が限られる。Eのコース詳細は反復性があるが、このSQL文のままヒントを付けると本人の受講状況を含む結果全体が保存される。登録の前後に同じ詳細を開くため、登録直後に登録前の受講状況が返り不適切である。

A：誤り。個人の受講履歴は同じ社員が繰り返し開き、結合を伴う重い処理なので、反復性と実行コストの点ではキャッシュに向いて見える。しかし受講完了の登録直後に本人の画面へ反映されていなければならない。同じ社員が1日に何度も開くため、登録前に開いた時点で保存された結果が保持期間内に残っている。保存された結果は保持期間の経過でしか入れ替わらないので、登録直後に開くと登録前の履歴が返る。この鮮度の要件を満たせないため対象にできない。

B：誤り。索引のない列の検索は、実行時間が長くなりやすい重い処理である点ではキャッシュの対象になりうる。しかし問題文では、検索語の大半がその日に一度しか使われず、同じ語での再検索はほとんど発生しない。保存した結果が再利用される機会が乏しく、負荷削減の効果は限られる。少数の語が繰り返し使われる可能性まで否定するものではないが、本問の条件では、同じクエリが繰り返し実行されるという前提を満たさない。

C：正解。研修コース一覧は全社員が同じ結果を取得する読み取り中心の処理で、複数テーブルの結合を伴う重いクエリである。コース情報の更新は毎週金曜日の17時のみで、更新後の内容は次の月曜日の始業時までに見られれば足りる。保持期間は保存時点から12時間なので、月曜日の始業時に返りうる保存結果は、その12時間前以降、つまり日曜日の夜以降に保存されたものに限られる。これは金曜日17時の更新より後の内容であり、金曜日の更新前にいつ開かれていても、月曜日の始業時には更新後の内容が表示される。反復性、実行コスト、鮮度の3条件に加え、更新タイミングと保持期間の関係も満たすので、対象に適している。

D：正解。部署別の受講完了率集計は複数テーブルを結合して集計する重い処理で、誰が開いても結果が同じなので、同じクエリが繰り返し実行される。保持期間は保存時点から12時間なので、午前9時台に返りうる保存結果は前日の21時台以降に保存されたものに限られる。前日の20時から当日の午前2時までは開かれないため、該当するのは午前2時以降、つまりバッチ完了後に保存された結果だけである。前日に保存された結果は翌朝の最初のアクセス時には保持期間を過ぎており、データベースから取得し直される。日中のアクセスにはその朝以降に保存された前夜のバッチ結果が返るので、前夜のバッチ結果が見られれば十分という要件を満たす。反復性、実行コスト、鮮度に加え、バッチ完了時刻・アクセスのない時間帯・保持期間の関係も満たすため、対象に適している。

E：誤り。コース詳細は多くの社員が繰り返し開くため反復性はあるが、1つのSQL文でコース情報と閲覧者本人の受講状況を結合している。このSQL文のままヒントを付けると、受講状況を含む結果全体が保存される。社員は登録の前にも後にも同じコースの詳細を開くため、登録前に開いた時点の保存結果が保持期間内に残り、保持期間の経過でしか入れ替わらないので、登録直後に開くと登録前の受講状況が返る。登録直後に本人の画面へ反映するという要件を満たせないため、対象にできない。

学習のポイント：反復性・実行コスト・鮮度の3条件に加え、保存時点から起算する保持期間と、更新・バッチ完了・アクセスのない時間帯との関係で決まる。Aは登録前の保存結果が登録直後に返る鮮度の問題で、Bは反復性の不足で外れる。Eは、このSQL文のままヒントを付けると本人の受講状況を含む結果全体が保存され、登録直後に登録前の状況が返るため外れる。

公式ドキュメント

• caching-database-query-results.html

KMSキーへのアクセスは、キーポリシー、グラント、IAMポリシーのいずれによっても許可できます。そのため、IAMポリシー経由の権限だけを洗い出せる確認方法を選ぶ必要があります。Aは、PolicySourceArnが1回のリクエストで1つしか指定できないため、ユーザーとロールの一覧を1回で評価する方法として成立しません。Bは、プリンシパルごとにSimulatePrincipalPolicyを呼び出し、ActionNamesにkms:*を指定して暗号化・復号を含むすべてのアクションを評価し、ResourceArnsで対象キーに限定しているため、要件をすべて満たす正解です。Cは、プリンシパルごとの呼び出しとResourceArnsの指定は正しいものの、ActionNamesがkms:ListKeysだけなので、暗号化・復号に関わるアクションが評価から漏れます。Dは、IAMポリシーシミュレーターを使う点は要件に合いますが、対象キーのARNを指定しないと既定で全KMSキーがシミュレートされるため、監査範囲を当該キーだけに絞れません。

A：誤り。PolicySourceArnは1回のSimulatePrincipalPolicyリクエストで1つだけ指定できるため、複数のユーザーとロールを1回のリクエストでまとめて評価することはできません。プリンシパルごとに呼び出す必要があり、この方法は成立しません。

B：正解。プリンシパルごとに個別に呼び出すため、PolicySourceArnの1つだけという制約に合います。ActionNamesにkms:*を指定すると暗号化・復号を含むすべてのKMS APIアクションが評価対象になり、ResourceArnsに対象キーのARNを指定することで評価範囲を当該キーだけに限定できます。IAMポリシー経由の権限を確認するという要件をすべて満たす唯一の方法です。

C：誤り。プリンシパルごとの呼び出しとResourceArnsによるキーの限定は正しい設計です。しかし、評価したいKMS APIアクションはすべてActionNamesに指定する必要があるのに、kms:ListKeysだけでは暗号化・復号に関わる権限が評価対象から漏れます。監査でアクションを網羅する要件を満たしません。

D：誤り。IAMポリシーシミュレーターは既定ですべてのKMSキーに対してアクセスをシミュレートします。対象キーのARNを指定しないと、結果に他のキーの権限が含まれ、監査範囲を当該キーだけに限定できません。結果から読み取る作業を加えても、評価対象が範囲外のキーを含む点は解消されません。

学習のポイント：IAMポリシー経由の権限を洗い出すには、PolicySourceArnが1リクエストに1つだけなのでプリンシパルごとに呼び出し、ActionNamesで評価対象のKMS APIアクションをすべて指定し、ResourceArnsで対象キーに限定する、という3点を同時に満たす必要があります。

公式ドキュメント

• determining-access-iam-policies.html

この問題では、要件1(発行側と後続の疎結合)、要件2(変更の種類に応じた、後続サービスの外側での振り分け)、要件3(急増時の取りこぼし防止と後続の自分のペースでの処理)の3つを、2つの選択肢の組み合わせで満たす構成を選びます。正解はAとEです。Aでは、契約変更サービスはEventBridgeへ発行するだけで後続を知らずに済みます。EventBridgeは受け取った変更を各ルールのイベントパターンと照合し、一致した変更だけをそのルールのターゲットへ送るため、変更の種類ごとの振り分けを受信側のコードに持たせずに済みます。後続を追加するときもEventBridge側のルールとターゲットを追加するだけで、契約変更サービスのコードは変わりません。これで要件1と2を満たします。Eでは、そのルールのターゲットに後続サービスごとのSQSキューを緩衝材として置き、LambdaとEKS上のコンテナがそれぞれ自分のキューから取り出して処理します。帳票発行のコンテナにも、このキューを経由して変更が届きます。これで要件3を満たします。Aだけでは変更を蓄える受け皿がなく、Eだけでは発行先と種類ごとの振り分けのルールが定まらないため、2つを組み合わせる必要があります。Bは、契約変更サービスが後続を呼び分けて同期的に応答を待つため要件1を満たさず、後続の遅延が応答に伝わり緩衝材もないため要件3も満たしません。Cは、5分ごとのまとめ処理で個々の変更をすぐに処理できず、変更の内容をもとに配信先を選ぶ仕組みもないため要件2を満たしません。また、一括で渡すため、後続が自分のペースで処理する要件3の意図にも合いません。Dは、全変更を全後続に届けて各サービスのコードで判定し読み捨てる方式で、受信側のコードで判定しないことを求める要件2を満たしません。

A：契約変更サービスは後続サービスの名前や台数を知らず、変更をEventBridgeへ発行するだけになります。EventBridgeは受け取ったイベントを各ルールのイベントパターンと照合し、パターンに一致したイベントだけをそのルールのターゲットへ送ります。つまり、変更の種類ごとの振り分けを担うのは、後続サービスの外側にあるEventBridgeのルールです。変更の種類ごとにイベントパターンを定義すれば、種類に応じた担当サービスにだけ届けられ、受信側のコードで判定する必要はありません。後続サービスを追加するときは、EventBridge側にルールとターゲットを追加しますが、契約変更サービスのコードは変更せずに済みます。このため、要件1の疎結合と要件2の種類に応じた配信を満たします。ルールのターゲットは担当サービスごとに設定し、この組み合わせではそのターゲットとしてEの後続サービスごとのSQSキューを置きます。帳票発行のコンテナにも、EventBridgeから直接ではなく、そのキューを経由して届きます。Aの構成には、変更を蓄えて後続サービスが自分のペースで取り出す受け皿が含まれないため、要件3はEとの組み合わせで満たします。

B：契約変更サービスが後続サービスの呼び分けを担うため、後続の追加や改修のたびに契約変更サービス側の改修が必要になり、要件1を満たしません。また同期呼び出しで結果を待つため、帳票発行の遅延や障害が契約変更画面の応答に直接伝わり、変更が集中したときに受け止める緩衝材もないので要件3も満たしません。呼び出し先をAPI Gatewayのパスで分けても、契約変更サービスが後続を呼び分けて応答を待つ構成であることは変わりません。

C：5分ごとに未処理分をまとめて処理する方式では、個々の変更が発生した時点で後続の処理を始められません。この方式は変更を大きなまとまりで扱うため、個々のイベントを単位として処理するという、イベント駆動で一般に推奨される設計と合いません。また、この構成ではLambda関数が受付テーブルからまとめて読み出した変更を後続へ渡すだけで、発行された変更の内容をもとに後続サービスの外側で担当サービスを選ぶ仕組みがありません。そのため、要件2を満たしません。さらに、起動間隔ごとに未処理分が一括で後続へ渡されるため、後続サービスは自身の処理能力に合わせて処理するという要件3の意図にも合いません。

D：この選択肢は、全変更を全後続に届けたうえで、各サービスのコードが種類を判定して担当外を読み捨てる設計です。担当外の変更も各サービスに届き、振り分けを受信側のコードで行っているため、後続サービスの外側で振り分け、受信側のコードでは判定しないとした要件2を満たしません。また、新しい種類の変更を追加するたびに受け側の判定処理も変える必要があり、後続の改修の影響を避けたい要件1の趣旨にも合いません。

E：EventBridgeのルールには、SQSキューを含む複数のターゲットを指定できます。後続サービスごとのSQSキューをルールのターゲットに置くと、Aのルールで種類ごとに振り分けた変更は、担当サービスのキューに入ります。変更が集中してもメッセージはキューに蓄積され、契約変更サービスは後続の処理能力を待たずに済みます。SQSはサービスの間の緩衝材として、トラフィックが増えたときのスケーリングを助けます。料金再計算のLambdaは、イベントソースマッピングによって自分のキューからイベントを取り出して処理するため、自分のペースで処理できます。帳票発行のコンテナも自分のキューから処理能力に合わせて取り出すため、要件3を満たします。一方、Eだけでは契約変更サービスがどこへ変更を発行し、どのイベントパターンで種類ごとに振り分けるかが定まりません。発行先と振り分けのルールはAで定義するため、AとEの組み合わせで3つの要件をすべて満たします。

学習のポイント：役割分担を見分けることが鍵です。発行側が後続を知らずに済み、変更の種類ごとの振り分けはEventBridgeのルールのイベントパターン照合で行い(A)、急増の吸収はルールのターゲットに置いたSQSキューが担います(E)。この2つの組み合わせで3要件を満たし、同期呼び出し・定期バッチ・受信側判定の誤答とは区別できます。

公式ドキュメント

• concepts-event-driven-architectures.html
• eb-event-patterns.html
• sample-eventbridge-custom-event.html

正解はAで、実行ロール側の許可は既にあるため、不足しているバケット側の許可をバケットポリシーで追加すればよい。リソースベースのポリシー経由のアクセスでは、実行ロールは自アカウントの権限を保持したまま利用できるため要件に合う。Bはロールを引き受ける方式で、引き受けた側の権限で動くためアカウントAの DynamoDB 権限を保持したまま同時利用する要件を満たさない。Cは実行ロール側に既にある種類の許可を重ねるだけで、バケット側で許可を定める要件に応えておらず誤り。Dは信頼ポリシーをロールの引き受け可否を定める設定として扱っており、バケットへの読み取り許可を与える仕組みではないため誤り。

A：正解。バケットポリシーはリソース側に付けるリソースベースのポリシーで、どのプリンシパルにアクセスを許可するかをバケット側で指定できる。本問では実行ロール側の許可は既に与えられているため、不足しているのはバケット側の許可であり、これをバケットポリシーで追加すれば要件を満たせる。リソースベースのポリシー経由でアクセスする場合、プリンシパルは元のアカウントで動き続けるため、DynamoDB への書き込み権限も失わない。

B：誤り。この方式では、アプリケーションはアカウントBのロールを引き受けてそのロールの権限で動く必要があり、アカウントAの実行ロールの権限を保持したまま同時に使うことができない。そのため、アカウントAの DynamoDB への書き込みと同時に満たすという要件に合わない。

C：誤り。実行ロールには読み取りを許可するIDベースポリシーが既にあるため、これを追加しても新しい許可は生まれない。IDベースポリシーは実行ロール側から権限を定めるものにすぎず、アクセスされるバケット側がどのプリンシパルを許可するかを定めていない。バケット側で実行ロールを許可する設定がなければ、本問のバケット側の設定だけで許可するという要件を満たさない。

D：誤り。信頼ポリシーは、どのプリンシパルがそのロールを引き受けられるかを定めるものであり、バケットへのアクセス許可を与える設定ではない。また、信頼ポリシーの向きも誤っており、アカウントBのバケットへの読み取りを許可する仕組みとして成立しない。

学習のポイント：アカウントBのバケットへのアクセス許可をバケット側(リソースベースのポリシー)で与えると、アカウントAの実行ロールは自アカウントの権限を保ったままアクセスできる点が鍵になる。

公式ドキュメント

• access_policies-cross-account-resource-access.html