30問中 0問が回答されています
質問:
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
You must sign in or sign up to start the テスト.
まず、次の操作を完了する必要があります:
正解数 0/問題数30
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
【SAA-1】あるスタートアップは、VPC 内の Application Load Balancer(ALB)を経由して稼働するオンラインストアを提供しています。新たに制定されたコンプライアンス方針により、サイトへのトラフィックを「韓国とオーストラリア」からのアクセスだけに制限し、その他地域からのリクエストは拒否する必要があります。日々の運用作業を極小化しつつ、この要求を満たす最適な方法はどれでしょうか。
国別で通信を制御したい場合、DNS レベルの振り分けはバイパスされ得る点、NACL やセキュリティグループでは CIDR を手動更新する運用が発生ししかも後者は明示的拒否を書けない点を踏まえ、常に最新の国情報を自動反映し ALB に直接アタッチできるアプリケーション層のサービスを選ぶと運用負荷と遵守の両立がしやすく、さらにリクエスト単位のログを自動的に CloudWatch などへ保管できれば監査対応の証跡も確保できるという総合的な視点で比較検討してみてください。
【SAA-2】新興企業のモバイル開発チームは、ステージングと本番で共通利用する e コマース向け REST API を Amazon API Gateway で公開している。サインアップ/サインインは既に Amazon Cognito ユーザープールで実装済みであり、API はログイン済みユーザーだけが呼び出せるようにしたい。API キー配布や独自コードの保守・追加インフラの運用は極力避ける場合、最適なアプローチはどれか。
モバイル側で Cognito 認証が完了しているなら、その ID トークンを Authorization ヘッダーに添えて API を呼ぶだけで、API ゲートウェイ側が署名や有効期限を自動検証してくれる仕組みを活用すると実装も運用も最小化できます。SigV4 署名をアプリに組み込む案は毎リクエストで署名ロジックが動き実装負荷が大きく、Lambda オーソライザーや自前の認証サービスを置く案はコード保守や追加インフラが発生します。API キーはユーザー認証ではなく利用量計測や無署名 API 制御向けで今回の目的に合いません。ステージングと本番で同じ設定を使い回せ、トークン失効管理も Cognito が担えるネイティブ統合の有無を軸に、要件である「ログイン済みユーザー限定」「追加運用を極力避ける」を総合的に満たす選択肢を見極めましょう。
【SAA-3】海外の広告代理店は AWS アカウントを持っていない。社内の S3 バケット(Block Public Access が有効)に格納されている 300 MB の動画ファイルを、ダウンロード用 URL を介して 12 時間だけ安全に共有する必要がある。バケットや他のオブジェクトを公開せず、AWS が提供する標準機能のみで実装できる最適な方法はどれか。
社外利用者に一時的に大容量ファイルを渡す場合、公開設定を変えずにオブジェクト単位で有効期限付きアクセス権を埋め込める仕組みがあると、Block Public Access を保持したまま URL だけで共有できます。署名情報を組み込むので AWS アカウントやアクセスキーは不要で、URL の期限が切れれば自動的に無効となります。バケットポリシーや CDN、SFTP などは構築や設定戻しの運用が増え、12 時間の単発共有には過剰です。標準機能で簡潔かつ期限到来後に自動失効し、追加コストや権限管理を最小にできる手段を選ぶ視点で総合的に判断しましょう。
【SAA-4】フィンテック企業は顧客のクレジットスコアに関する極秘 CSV ファイルを Amazon S3 に保管している。計算処理を担う Amazon EC2 インスタンス群は、外部ネットワークへ出られない VPC のプライベートサブネットに配置されている。インターネットを一切通さずにこれら EC2 から S3 へ接続し、しかも特定のマイクロサービスだけが対象バケットにアクセスできるようにする必要がある。最も適切な対応を2つ選びなさい。
計算系EC2はインターネット非接続のプライベートサブネットにあり、S3への経路も外部を通せないため、NATやインターネットゲートウェイを経由する案は前提と矛盾します。AWS内部だけでS3に届く経路を用意し、その経路から来た通信だけをバケット側で許可すると要件を二重で満たせます。バケットポリシーには特定エンドポイントやプリンシパルを条件にできるキーが用意されている点も思い出してください。IAMアクセスキーの埋め込みや静的ウェブホスティングの利用はセキュリティや通信経路の点で適さず、プライベート環境へ閉じる目的にもそぐいません。通信経路と権限制御の両面をAWSの専用機能で分離して考えると正解に近づけます。
【SAA-5】TechSoft社は AWS Organizations を利用して 30 以上の AWS アカウントを一元管理している。
セキュリティ部門は、すべてのアカウントから GuardDuty 検出結果を集約するため、オハイオリージョン (us-east-2) に S3 バケット「techsoft-security-logs」を 1 つだけ用意した。満たすべき条件は次のとおり。
1) バケットに対するあらゆる操作は TechSoft 組織に属する IAM ユーザーまたはロールだけに許可する。
2) 新しいアカウントを Organizations に追加しても、追加スクリプトや手動設定は極力不要とする。
3) 組織外アカウントやインターネットからのアクセスは全面的に拒否する。
4) us-east-2 以外のリージョンからの意図しないアクセスやレプリケーションもブロックする。
セキュリティ部門は今後さらに多数の子アカウントを増やす計画であり、運用負荷を最小限に抑えながらこれらの要件を恒久的に担保したい。
最適な設計はどれか。
組織に新しく追加されたアカウントが自動でログバケットに書き込めるようにしたい場合、ポリシーへ個々のアカウント ID を列挙したり、Lambda などで動的に追記する仕組みは運用負荷やポリシーサイズ上限が課題となります。Organizations 全体を 1 つの条件で束ねられるキーがあるかを思い出し、そのうえでリージョン外からの操作やパブリック公開を包括的に拒否できる設定を組み合わせれば、意図しない経路を確実に遮断できます。最終的には「誰がアクセスできるか」と「どのリージョンから許可するか」をシンプルかつ恒久的に制御できる設計を選ぶ視点で総合判断してください。
【SAA-6】新興企業B社は、プライベートサブネットに配置した分析用 EC2 インスタンスから Amazon S3 バケットへファイルのアップロードとダウンロードを行う必要がある。社内のコンプライアンスでは「通信がインターネットを横断しないこと」が絶対条件であり、追加コストや構成変更はできる限り小さく抑えたい。これらの要件を最も効率的に満たすネットワーク設計はどれか。
通信がインターネットを経由しない、追加料金がほぼ発生しない、設定変更がルートテーブルの更新程度で済む――この 3 点を同時に満たす仕組みを探すと、NAT のように IGW を通過するものや従量課金が発生するエンドポイントタイプ、オンプレミス移行のように環境を大きく変える案は自然と除外され、S3 へのアクセスを AWS 内に閉じ込めつつ定額無料で提供されるネイティブ機能に着目しサブネットからの経路制御だけで要件が達成できるかを総合的に見極めることが、分析用インスタンスを変更せずシームレスに安全なファイル転送を実現する近道となります。
【SAA-7】本社 LAN (CIDR: 192.168.50.0/22) だけを接続元として、パブリックサブネット上の踏み台サーバー経由で、プライベートサブネット内のバックエンド EC2 インスタンスへ SSH で保守ログインできるようにしたい。
最小権限と多層防御を実現するため、既存のセキュリティグループを更新して実施すべき手順を 2 つ選べ。
本社 LAN → 踏み台 → バックエンドという 2 段の経路を個別のセキュリティグループで管理すると考えてみましょう。外部に面する踏み台側は社内 CIDR だけを IP レンジ指定で許可し、内部に面するバックエンド側は IP ではなく踏み台のセキュリティグループ参照で SSH を許可すると、踏み台のプライベート IP 変化への耐性、VPC 内他ホストからの遮断、最小権限の徹底が同時に成立します。NACL は追加の防御層ですが、セキュリティグループを緩める代替にはなりません。SSH(TCP 22)のみを対象にし、ステートフル性で戻り通信は自動許可される点も踏まえ、最も単純で安全な手順を総合的に判断してください。
【SAA-8】国内医療機器メーカーが新たに AWS 上でマルチアカウント基盤を立ち上げています。社内基準は以下のとおりです。
1) すべてのワークロードは大阪リージョン (ap-northeast-3) のみに配置すること
2) どの VPC からもパブリックインターネットへ直接出られないこと
3) 違反が発生し得ないよう事前にブロックする強制制御を中央で適用すること
単なる検出や通知だけでは要件を満たしません。これらの条件を継続的に確実に満たせる組み合わせを 2 つ選んでください。(正解は 2 つ)
大阪リージョン限定かつインターネットへ直接出られない状態を予防的に強制するには、各アカウントの設定変更を許さず API レベルで操作自体を拒否できる Organizations 直下の SCP や Control Tower の強制ガードレールといった中央集権型の構成管理が有効であり、違反が起こってから検知・通知・手動対応する仕組みや VPC 個別の通信制御だけでは要件を満たさないため、リージョンや IGW ルートの作成そのものを禁止するポリシーを組み合わせて一元適用できるかを俯瞰し複数案を比較して総合的に判断しましょう
【SAA-9】自社は AWS Organizations で 15 アカウントを運用している。以前、root ユーザー宛てに届いた緊急セキュリティ通知を担当者が長期休暇で不在だったため見逃し、被害が拡大した。今後は
① 選任された 2〜3 名の管理者だけが確実に通知を受け取り、
② 退職・不在時にも配信経路が途切れないよう冗長化し、
③ 追加コストや複雑な運用を避けたい。
最も適切な対応はどれか。
root 宛ての緊急連絡は AWS で送信先を 1 つしか持てないため、担当者が休暇・退職しても 2〜3 名の管理者に確実に届く仕組みとしては、個人アドレスやクライアント転送に頼るより、メンバー変更が楽なメール配布リストを宛先に設定し、同一リストを Organizations の請求・運用・セキュリティの代替連絡先にも登録して経路を二重化する方法なら追加サービスや保守が不要です。SES や SNS、Lambda などを各アカウント分構築する案と比較し、可用性・冗長性・運用の簡素さという要件を総合的に満たせるかを俯瞰して判断してみてください。
【SAA-10】国際企業「グロボデータ社」では、開発・テスト・本番など 18 個の AWS アカウントを AWS Organizations で管理しています。
内部監査から「全アカウントで S3 バケットをパブリック公開する API を使えなくし、今後追加されるアカウントにも強制したい」という依頼がありました。
運用部門は、各アカウントに個別で IAM ポリシーを配布せず、中央で一括ガバナンスを実現したいと考えています。
この要件を最も効率的かつ拡張性高く満たす方法はどれですか。
全アカウントが共通で従う「上限」を中央に置けば、各アカウントの IAM 管理者がいかに強い権限を持っていても回避できません。しかも組織の最上位に一度だけ設定すれば、のちに OU やアカウントが増えても自動的に適用されます。通知や修復を待つ検出的手段ではなく、API 自体を事前に実行不能にする予防的ガードレールを選ぶ視点が重要です。複数案の運用負荷、強制力、将来拡張性を比較して総合的に判断しましょう。
【SAA-11】自社アカウント (987654321000) の Frankfurt リージョン (eu-central-1) にある VPC (CIDR: 172.30.0.0/16) から、別アカウント (444444444444) の Sydney リージョン (ap-southeast-2) に配置された在庫管理 API (TCP 8443 のみ) へ安全にアクセスしたい。
ビジネス要件
1. 先方 VPC 内の当該 API だけを利用対象とする。
2. 必要帯域は約 500 Mbps、コストはできるだけ低く抑える。
セキュリティ要件
1. 通信は AWS バックボーン内で完結させ、インターネットは経由しない。
2. パブリック IP アドレスを割り当てない。
3. 広い CIDR 同士の相互疎通は禁止し、単一ポートに限定した最小権限を徹底する。
ネットワーク制約
• 自社側はルートテーブルとセキュリティグループを変更できるが、サービス提供側はサービスエンドポイントのみ公開可能。
• クロスリージョン接続および DNS 名解決が必要。
上記の要件をすべて満たす接続方法として最も適切なものを選んでください。
インターネットを迂回しリージョンを越えても AWS バックボーン上で閉じ、相手側は広い CIDR を共有せず 1 ポートだけのサービスエンドポイント公開にとどめたいという前提では、CIDR ベースで双方向にルーティングを広げる仕組みよりも、利用側サブネットに専用 ENI が動的に挿入され NLB の所定ポートだけを転送する一方向型マネージド接続を選択することで、500 Mbps 程度の帯域確保とパブリック IP 不要の要件を同時に満たせますので、コストや運用の簡素化も踏まえサービス単位で絞れる方式を軸に総合判断してみてください。
【SAA-12】動画配信サービスを運営する企業では、単一の Amazon RDS for PostgreSQL に対し複数の Amazon ECS Fargate タスクと AWS Lambda 関数からアクセスしている。
社内ポリシーは「DB 資格情報を 14 日以内に自動ローテーションし、人手作業を最小化すること」と規定している。
さらに、各タスクおよび関数には「シークレットの取得のみ許可し、更新は不可」とする IAM 制約が求められる。
これらの条件を同時に満たす最適な設計はどれか。
RDS 用の資格情報を 14 日サイクルで完全自動ローテーションできる仕組みが標準で組み込まれているサービスを思い出してみましょう。ウィザードで 1〜29 日を指定すると、裏側で Lambda が新しいユーザーを生成・検証・適用まで行い、人手を介しません。さらにそのサービスは取得用 API と更新用 API が分離されているため、IAM ポリシーで Get のみを許可し Put を拒否する運用が容易です。対照的に Parameter Store は通知や外部スクリプトが必要、S3 や環境変数はファイル差し替えや再デプロイが発生し運用負荷が高くなります。自動化レベル、最小権限、手作業削減という複数要件を横並びで比較すると、自動ローテーション機能と API 分離が決め手になるはずです。
【SAA-13】物流企業 K 社は AWS Organizations 配下に 5 つのメンバーアカウントを所有している。オンプレミスの自己運用 Microsoft Active Directory 内のユーザー/グループを複製せずに、全アカウントへ統一的なサインオンを提供したい。追加の IdP サーバーを新たに保守することは避け、高可用性と運用効率の両立を求めている。最適な構成はどれか。
オンプレ AD のユーザーを複製せずに統一サインオンを実現するには、AWS 側に追加で IdP サーバーを維持しないマネージド型サービスを選ぶことが鍵です。マルチ AZ で自動冗長化され、IAM Identity Center と直接統合できるディレクトリを用いれば、フォレスト信頼でオンプレ AD と接続して認証を完結でき、運用負荷も抑えられます。さらに、Organizations 全体を横断して権限セットを一元管理できれば、アカウントごとの個別設定が不要となり効率的です。可用性、運用コスト、管理容易性を総合的に比較して最適解を判断してください。
【SAA-14】社内システムでは、Amazon Linux 2 と Windows Server が混在する数十台の EC2 インスタンスを 3 つのプライベートサブネットに配置している。
現状は公開サブネット上の踏み台サーバを経由してポート 22/3389 で運用担当者がログインしているが、
・踏み台の維持や秘密鍵配布を廃止して管理コストを下げたい
・インターネットやオンプレ VPN に頼らず AWS 標準機能だけで運用アクセスを完結させたい
・アクセス権限と操作履歴を IAM ポリシーと AWS CloudTrail に一元的に残したい
という新しいガバナンス要件が出た。
最も適切な対応策はどれか。
Linux と Windows の両方に対応し、22 番や 3389 番を開けずにブラウザや CLI からシェルや RDP 相当の操作ができ、各インスタンスに IAM ロールを付与するだけで鍵配布を省けて CloudTrail に接続履歴が残り、VPC エンドポイントを併用すれば通信が AWS 内で完結して踏み台や VPN の維持も不要になる仕組みがどれか、鍵管理・ネットワーク経路・監査の三点を同時に満たせるかを総合的に判断してください。
【SAA-15】動画クリップとメタデータを配布している企業 GreenStream では、1 つの Amazon S3 バケットにサムネイル画像(静的)とリクエストごとに生成される JSON ファイル(動的)を保管し、Amazon CloudFront パブリックディストリビューションを通して世界中の匿名視聴者に提供したいと考えている。新たに示されたセキュリティおよび運用条件は次のとおり。
1. エンドユーザーがアクセスできるのは CloudFront のドメイン名のみで、S3 のリージョナルエンドポイントへは直接届かないこと
2. アプリケーションコードやリダイレクトの実装は変更せず、インフラ設定だけで完結すること
3. バケットは全面的にプライベートで、最小特権の原則を担保すること
4. 将来、署名付きリクエストやオリジン TLS 強制など、OAC の最新機能をすぐ利用できる構成にしておくこと
これらの前提をすべて満たすアーキテクチャとして最も適切なのはどれか。
バケットを完全非公開に保ちつつ CloudFront だけに読み取りを許可するには、CloudFront が S3 へ SigV4 署名付きリクエストを代理送信できる最新のオリジンアクセスコントロール機能を用いると、バケットポリシーで最小権限を厳格に適用できます。静的ウェブサイトエンドポイントや Referer ヘッダー、ACL の public-read など公開設定に依存する方式は、リージョナルエンドポイントへの直アクセスや将来要求される TLS 強制といった拡張時に足かせになりがちです。アプリ改修やリダイレクトを伴わずインフラ設定だけで要件を満たせるか、そして拡張性・運用負荷・セキュリティを総合的に見比べて最適な解を選んでください。
【SAA-16】社内規定の厳格な条件は次のとおり。
1) すべての HTTP/HTTPS リクエストは AWS WAF を経由させること。
2) Amazon S3 はバックエンド専用とし、インターネットから直接到達できないようにすること。
グローバルに静的 Web サイトを届け、のちに API などを容易に追加できる構成として最適なのはどれか。
全ユーザの通信が必ず WAF を最前段で通過しつつグローバル配信と将来のオリジン追加を両立させるには、まずエッジサービスを入口に据え、S3 は Block Public Access で完全非公開としたうえでそのエッジからの署名付きアクセスだけを許可する設計が基本となりますので、各案について①エンドユーザ→WAF→エッジ→バックエンドの経路が切れ目なく確保されているか、②バケットが公開 CIDR ではなく信頼できるアイデンティティで保護されているか、③後から API などを容易に追加できる柔軟性があるか、の三点を俯瞰して総合判断してみてください。
【SAA-17】自社の稼働情報を示す CloudWatch ダッシュボードを、AWS アカウント非保持の外部審査員が四半期ごとに閲覧する必要があります。
審査員にはダッシュボード 1 画面だけ見られれば十分で、追加インフラの手配や IAM 資格情報発行は極力避けたいと考えています。
最小権限で運用とコストを抑えて要件を満たす方法はどれですか。
審査員には四半期に一度、1 枚のダッシュボードを閲覧させるだけで十分であり、AWS アカウントや IAM 資格情報を渡したくないという前提が最重要です。サーバやユーザーを新設すると運用負荷とコストが増し、最小権限にも反します。実は CloudWatch ダッシュボードには、署名付きの限定公開 URL を数クリックで作成し、ブラウザだけで閲覧させる機能があります。これなら追加インフラも認証も不要で、他リソースへのアクセス権も生まれません。閲覧頻度・権限範囲・コスト・運用簡素化を総合的に比較し、最も軽量な方法を選びましょう。
【SAA-18】社内向け BI プラットフォームを新規構築しています。プライベートサブネット上で稼働する Amazon EC2 インスタンスから、同一リージョンの Amazon DynamoDB テーブルへインターネットを経由せずにアクセスすることが社内セキュリティ標準で求められています。可用性を維持しながら料金をできるだけ抑えられるネットワーク設計として最適なのは次のうちどれですか。
インターネットを通さずに DynamoDB と通信するには、VPC 内で完結する経路を確保する仕組みを思い出してください。複数 AZ で自動冗長化され、時間単価がかからずデータ転送料のみで利用できるサービスをルートテーブルに追加すれば、AWS バックボーン経由でプライベートサブネットの EC2 から直接アクセスできます。NAT インスタンスや NAT ゲートウェイはインターネットゲートウェイを必須とし、前者は運用負荷、後者は時間課金が発生します。ACL で宛先を制限しても経路がインターネットに依存していれば要件を満たしません。可用性、運用負荷、コスト、セキュリティを横並びに眺めて最もシンプルに要件を満たす選択肢を導き出してください。
【SAA-19】社内の配送追跡サービスが Amazon EC2 インスタンス (Amazon Linux) 上で稼働している。このサービスは Amazon S3 バケット「parcel-logs」に対しオブジェクトの取得と保存を行う必要がある。インスタンス内に長期的な認証情報を保持せず、かつ最小権限で S3 に安全にアクセスできるようにしたい。ソリューションアーキテクトはどの方法を採用すべきか。
配送追跡サービスが動く EC2 から S3 へ安全にアクセスするには、インスタンス内部に長期キーを配置せず一時的な認証情報を自動取得し、GetObject と PutObject など必要最小限の操作だけを許可できる仕組みを採ることが重要ですので、IP 条件や人間向けグループではなくインスタンス自身に動的に権限を付与できる AWS 標準のやり方を思い出し、キー埋め込みによる漏えいリスクやフルアクセスの過剰権限も考慮して最もセキュアかつ運用しやすい選択肢を総合的に判断してください。
【SAA-20】あなたの組織では AWS アカウントを 2 つ運用しています。
・アカウント X・・・データサイエンス部門が利用。自分たちの S3 バケットにはすでに IAM ポリシーで適切な権限を持っている。
・アカウント Y・・・情報システム部門が所有。ここには「DataExchangeRole」という IAM ロールがあり、特定バケットに対して GetObject と PutObject だけを許可する最小権限のポリシーが設定済み。
今後、アカウント X のエンジニアが、このロールを経由してアカウント Y のバケットにファイルの読み書きを行う必要がある。
追加の運用負荷を発生させず、かつ最小特権の原則を維持しながらクロスアカウントアクセスを実現する最適な手順はどれか。
クロスアカウントで S3 に最小権限アクセスさせるには、アクセス先に用意されたロールを信頼できる相手として委任し、利用元ユーザーが STS で一時的にそのロールを引き受ける方法が推奨です。これなら長期キーや個別権限付与が不要で、既存の GetObject/PutObject だけのポリシーをそのまま使えるため権限が広がりません。一方、バケットポリシーで全アカウントを許す設定、フルアクセスのマネージドポリシー付与、ユーザー複製とキー共有はいずれも運用負荷や漏えいリスクを上げがちです。最小特権と運用効率を両立できる選択肢はどれかを総合的に判断してください。
【SAA-21】新任クラウド担当者は、IAM ポリシー のみ で次のアクセス要件を満たす権限を付与するよう求められました。
バケット 「app-assets」 に対してオブジェクトの読み取り (GetObject) と書き込み (PutObject) を許可
バケット 「app-assets」 自体の一覧取得 (ListBucket) を許可
バケット 「confidential-backup」 にはバケット/オブジェクトを問わず一切アクセスさせない
そのほかの S3 バケットや AWS リソースの権限は変更しない
次の 4 つのポリシーのうち、この要件を最小権限で正しく満たすものを 1 つ選んでください。
まず許可側で必要なのは、app-assets バケット自体を一覧できる s3:ListBucket と、オブジェクトに対する s3:GetObject、s3:PutObject です。リソース ARN はバケットとオブジェクトで末尾が「/*」付きかどうかが異なる点に注意してください。次に confidential-backup にはバケット操作とオブジェクト操作の両方を完全に拒否する明示的 Deny が必要です。Deny は Allow より常に優先されるため、範囲を広げ過ぎると app-assets へのアクセスまで打ち消してしまいます。他のバケットを触らないようワイルドカードを安易に用いないこと、そして最小限の ARN のみを対象にすることを意識すると最適解が見えてきます。
【SAA-22】次の IAM ポリシーは、技術部門グループ “WebDev” にアタッチされている。
JSON には 2 つのステートメント (1 と 2) が含まれている。
“`
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “1-AllowTerminateFromOfficeNet”,
“Effect”: “Allow”,
“Action”: “ec2:TerminateInstances”,
“Resource”: “*”,
“Condition”: {
“IpAddress”: { “aws:SourceIp”: “198.51.100.0/25”] }
}
},
{
“Sid”: “2-DenyEC2OutsideOregon”,
“Effect”: “Deny”,
“Action”: “ec2:*”,
“Resource”: “*”,
“Condition”: {
“StringNotEquals”: { “ec2:Region”: “us-west-2” }
}
}
]
}
“`
グループのメンバーが EC2 インスタンスを終了できる条件として、最も正しい説明を選べ。
IAM では明示的 Deny が Allow より必ず優先されます。このポリシーは最初の文で TerminateInstances を送信元 IP 198.51.100.0/25 に限定して Allow し、次の文で us-west-2 以外の全 EC2 操作を Deny しています。許可を得るには「IP 条件を満たす」かつ「Deny の対象にならないリージョン」を同時に満たす必要があります。Action も TerminateInstances のみに絞られているため、他の操作は暗黙的に拒否されます。IP だけ、あるいはリージョンだけに注目すると評価順序を見落とすので、全条件と Action 範囲を組み合わせた総合判断で考えてみてください。
【SAA-23】動画配信サービスを運営する企業では、Amazon ECS のハイブリッドクラスター(Fargate と EC2 起動タイプの混在)上で動いているコンテナが、生成した PNG サムネイルを Amazon S3 バケットにアップロードする必要があります。
VPC から S3 へのネットワーク経路はすでに構成済みであり、イメージ内にアクセスキーなどの資格情報を埋め込まず、タスク実行時だけ最小限の権限で書き込みを行わせたいと考えています。
この要件を満たす最適な方法はどれですか?
VPC 経路は整備済みなので通信面は問題ありません。焦点は「資格情報をどう安全に渡し、かつ最小権限にするか」です。タスク開始時に一時的な認証情報が自動注入され、Fargate と EC2 の両方で同じ仕組みが使える方法を思い出してください。インスタンス全体に広い権限を持たせたり、固定アクセスキーを環境変数で渡したりする案は、範囲が広すぎたり漏えいリスクが高かったりして要件に適合しません。また、セキュリティグループは通信可否のみで認可を解決しない点も確認しましょう。S3 への操作は PutObject だけ許可すれば十分ですから、最小権限ポリシーをその仕組みに添付し、タスク定義で引き受けるイメージを持つと整理しやすいです。資格情報のライフサイクル、適用範囲、最小権限を総合的に満たす選択肢を見極めてください。
【SAA-24】国内スーパー「Sakura Stores」は、決済完了イベントを Amazon EventBridge のルールで検出し、AWS Lambda 関数 CheckOrderRisk を即時実行して不正取引を遮断したいと考えている。
情シス部門からは「EventBridge だけが Invoke できるよう最小権限で設定せよ」と指示がある。
次のうち、この要件を最も適切に満たす設定はどれか。
EventBridge が Lambda を呼び出す場合、呼び出される側の関数にリソースベースポリシーを付けて「誰が Invoke できるか」を制御するのがセキュアな手順です。実行ロールは関数が外部へ何を実行できるかを決めるもので用途が違います。ポリシーでは Principal に events.amazonaws.com を明示し、Action は lambda:InvokeFunction だけに限定し、Resource も対象関数の ARN に絞ることで最小権限が保てます。Principal をワイルドカードにしたり Action を lambda:* にすると権限過多になる点を意識し、これら条件を同時に満たす選択肢を総合的に判断しましょう。
【SAA-25】オンライン決済サービスを提供するスタートアップでは、2 つのアベイラビリティーゾーンに配置した Amazon EC2 インスタンスからオブジェクトストレージへ日次バックアップを取得しています。現状、インスタンスはパブリックサブネットに配置され、インターネットゲートウェイ(IGW)経由で Amazon S3 に接続しています。
新たなセキュリティ基準により次の要件が課されました。
・インターネットとの通信は全面的に遮断する
・外部へのアウトバウンド通信で必要なのは S3 へのみ
この条件を満たすネットワーク設計として最適なものを 1 つ選んでください。
インターネット経路を完全に閉じるには、EC2 がパブリック IP を持たず IGW に到達しない設計が第一歩です。S3 へは AWS ネットワーク内部の専用経路を用いることで、ルートテーブルやセキュリティグループを最小限に保ったまま通信できます。その専用経路は無料かつ冗長化が自動、各 AZ で高可用となるサービスが用意されています。NAT や VPN は最終的に外部網へ出る箇所が残り、アドレス範囲変動への追随や運用コストが課題です。また、パブリック DNS 解決が不要となるためアウトバウンドルールも一層シンプルになります。各案を比較し、プライベートサブネット化と疎通先を S3 のみに限定できる機構の有無という観点で総合的に判断してください。
【SAA-26】データ分析用の EC2 インスタンスが配置されているプライベートサブネットから、インターネットを経由せずに社内の Amazon S3 バケットへファイルを転送できる構成を計画している。
追加で Direct Connect や VPN を敷設する予定はなく、コストおよび運用作業をできる限り抑えたい。
セキュリティグループの修正や IAM ポリシーの調整は許容されている。
この要件をもっとも効率的に満たすアーキテクチャはどれか。
プライベートサブネットの EC2 から社内 S3 に閉域で安価に送りたいなら、時間課金がなくルートテーブルにプレフィックスリストを足すだけで済み、バケットポリシーに SourceVpce 条件を設けて外部経路を遮断できるゲートウェイ型 VPC エンドポイントの特性と、NAT や API Gateway、インターフェース型が生む追加料金や運用負荷を並べて比較すると、最少コスト・最小作業という要件を総合的に満たせる案が自然と浮かび上がるはずです。
【SAA-27】社内の分析チームは、VPC 内の EC2 インスタンス (IAM ロール: ReportUploader) から、S3 バケット audit-data-store にログファイルを転送する仕組みを計画しています。
制約
1. インターネットゲートウェイ・NAT ゲートウェイ・パブリック IP を一切使わない
2. 通信を許可するのは該当 EC2 インスタンスのみ
3. そのほかの AWS サービスや外部ネットワークからのアクセスは拒否する
この要件を最も満たす構成はどれか。
要件はプライベートネットワーク内だけで S3 と通信し、かつ特定 EC2 インスタンスだけを許可することです。インターネットや NAT に依存する経路は排除する必要があります。S3 には VPC エンドポイントを利用できますが、ゲートウェイ型は IP 制御が中心で同じ VPC 内の他リソースを完全に締め出しにくい点に注意しましょう。インターフェイス型ならエンドポイント ID とセキュリティグループをバケットポリシーの条件に含められ、IAM ロール条件と組み合わせれば粒度の細かい制御が可能です。さらにパブリックルートを削除し、各 AZ で適切に DNS 解決させれば外部経路を持たずに通信を閉域化できます。これらを踏まえ、構成要素が三つの要件を同時に満たしているか総合的に判断してみてください。
【SAA-28】あなたは TechFusion Ltd. のクラウドアーキテクトです。
Amazon EC2 インスタンス i-789xyz から Amazon RDS へ接続するためのデータベースパスワードを安全に扱う必要があります。要件は以下の通りです。
1. パスワードは AWS Systems Manager Parameter Store の SecureString として保存し、カスタマー管理 KMS キー arn:aws:kms:us-east-1:444455556666:key/techfusion-db-key で暗号化すること。
2. そのパラメータを取得できるのは i-789xyz に割り当てられたインスタンスプロファイルのみで、他の EC2、Lambda、ユーザーには認可しないこと。
3. 最小権限を徹底し、他のパラメータ名や KMS キーへのアクセスはブロックすること。
すべての要件を満たす設計として最も適切なものはどれか。
SecureString は IMDS から自動取得されないため ssm:GetParameter を明示的に許可し、カスタマー管理キーで暗号化した場合は kms:Decrypt を該当キーの ARN のみに絞って付与する必要があります。そのうえでワイルドカードを避けたリソース指定と余分な KMS アクションを排除し、信頼ポリシーを ec2.amazonaws.com のみに限定した専用ロールを i-789xyz 専用のインスタンスプロファイルとして関連付ければ、他の EC2・Lambda・ユーザーからのアクセスを遮断しつつ最小権限を維持できるという観点から、要件を満たす構成かどうかを総合的に判断してください。
【SAA-29】社内のセキュリティ基準では「EC2 にパブリック IP を割り当てない」「外部インターネットを経由させない」「運用コストを極力低減する」の 3 点が義務付けられている。プライベートサブネット内の EC2 インスタンスから、同じリージョンにある Amazon S3 バケットへファイルをアップロード/ダウンロードし、将来的に同リージョンの Amazon DynamoDB も参照する予定がある。月間データ転送量は約 11 TB と見積もられている。最も費用効率の高いネットワーク構成を選択せよ。
プライベートサブネットの EC2 から S3 や DynamoDB に向かう経路としては、NAT ゲートウェイ経由、インターフェイス型エンドポイント、Direct Connect、サービス固有のゲートウェイ型エンドポイントなどが候補になります。要求は①パブリック IP を付けない ②インターネットを経由しない ③11TB/月でもコストを極小化、の三点です。S3 と DynamoDB だけに用意された仕組みで、転送量もエンドポイント利用料も無料になる方法が存在するかを思い出してみましょう。最後に、帯域課金や ENI 使用料が積み重なる構成と比較し、すべての要件を最も低コストで同時に満たす案を総合判断してください。
【SAA-30】映像配信ベンチャーが AWS に 2 層アーキテクチャの新サービスを構築しています。
・フロントエンド EC2 インスタンス (SG-FE) はパブリックサブネットにあり、全世界のユーザーから HTTPS (TCP 443) でアクセスされる。
・バックエンドの MySQL インスタンス (SG-BE) はプライベートサブネットに配置し、フロントエンドからの TCP 3306 トラフィックだけを受け付けること。
・セキュリティグループは最小権限を遵守すること。
要件を満たすために不可欠なセキュリティグループルールを 2 つ選びなさい。
インターネット公開用のフロントエンドには世界中からの HTTPS(TCP 443)を受け入れる入口が必須ですが、セキュリティグループはステートフルなので応答の出口は暗黙に許可され追加設定は要りません。一方、プライベートサブネットの MySQL は TCP 3306 を用い、送信元をフロントエンドのセキュリティグループだけに絞ることで「誰がどこへ接続できるか」を最小化できます。UDP や広すぎる CIDR、目的外ポートの開放は原則避け、通信方向・プロトコル・範囲を突き合わせながら、最小権限を守りつつサービス要件をすべて満たす構成かを総合的に判断してください。