ブックマークページはこちら
正解番号の相違等のご報告はコメントでいただけますと幸いです。技術質問は会員制コミュニティで対応しております。
8/2:AWSサービス種別の演習カテゴリを提供開始しました。
8/8:全問ランダムを模擬試験に名称変更。合格時に認定証を表示するようにしました。
10問中 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/問題数10
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
【SAP-281】ある大規模メディア企業は、次世代ニュース配信プラットフォームのバックエンドを完全サーバーレスで構築する計画を立てている。要件は以下のとおりである。
1) 全世界の読者向けに HTTPS 公開 API を提供する。
2) バックエンドのデータストアは Amazon DynamoDB 上の複数テーブルで、1 秒あたり数万要求までスケールする。
3) サーバー運用を排除し、インフラはフルマネージドサービスのみで構成する。
4) 短時間でアクセスが急増しても自動スケールし、運用者によるキャパシティ調整を不要とする。
5) API レイヤでは、テナント毎のスロットリングや認証を簡易に設定できることが望ましい。
この要件を満たすアーキテクチャとして最も適切な選択肢を2つ選べ。
HTTPS 公開 API、テナント単位のスロットリングと認証、秒間数万リクエストを処理する DynamoDB、完全マネージドかつ自動スケール──この四点が鍵です。API Gateway ならスロットリング・API キー・Cognito 連携を簡単に設定でき、REST タイプでは AWS サービスへの直接統合も可能です。Lambda を挟めばビジネスロジックを柔軟に実装できますが、レイテンシとコストを抑えたい場面では介在を減らす選択肢も有効です。一方、HTTP API は現状 DynamoDB 直結ができず、ALB や CloudFront は API 制御やオリジン要件で制約が残ります。各サービスの機能差と要件適合度を見比べ、最終的にインフラ運用ゼロで機能面を全て満たす組み合わせを二つ導き出しましょう。
【SAP-282】国内ゲーム会社のデータ分析基盤チームは、1 日あたり数十本のプレイヤー行動分析ジョブを Amazon EMR で実行している。ジョブ投入はゲームイベントの開催可否によって突発的に変動し、平均 CPU 利用率は 20 % 程度だがピーク時には 5 倍近く跳ね上がることもある。ジョブはレイテンシ目標が厳しく、完了までの時間を伸ばすことは許されない。一方で CFO からは「今の On-Demand 専用クラスターは月次コストが高すぎる。最低でも 40 % 削減しろ」と指示を受けた。クラスターは常時起動しており、システムを停止せずに構成を変更できることが前提である。
データプラットフォームアーキテクトは、コスト削減と性能維持の両立を図るため、EMR のインスタンス購入オプションをどのように組み合わせるべきか。
ピークに合わせスループット確保しつつアイドル時コストを下げるには、負荷変動を担うタスク層だけ割引率の高い購入オプションで弾力的に増減させ、制御プレーンや HDFS を保持する層は中断不可なので安定したオプションを維持する構成が考えられます。EMR ではノードタイプごとにオンデマンド・スポットを混在させられる方式があり、さらに容量最適化を選ぶと奪い合いの少ないインスタンスに自動で寄せてくれるため中断率を抑止可能です。既存のクラスターでも数分のローリング操作で切替えられるため停止は不要。平均 20% 利用率ならタスク分を変動課金に移すだけで 40% 近い削減が視野に入ります。性能確保とコスト圧縮の両立を軸に総合的に判断しましょう。
【SAP-283】FinTechPro 社は 1 つの AWS アカウント内で複数のマイクロサービスを運用している。
セキュリティ部門は「開発エンジニアは承認済みリソースだけを CloudFormation 経由でデプロイでき、他の API には一切アクセスできない」ことを必須要件とした。
この要件を満たすための IAM 設計として最も適切なものはどれか。
鍵は「エンジニアが直接呼べる API を CloudFormation に絞り、実際のリソース作成は CloudFormation が別ロールで行う」構成です。開発者が使うロールには CreateStack/UpdateStack などスタック操作だけを許可し、S3 や Lambda など承認済みサービス権限を載せたサービスロールを CloudFormation に委任します。スタック起動時に role-arn を固定すれば、利用者が勝手に権限を差し替える余地もありません。許可境界や SCP は経路を強制しにくく、手動デプロイ前提では自動化が阻害されます。最小権限を保ちながらセルフサービスを実現する案かどうかを総合的に判断してください。
【SAP-284】複数のワークロード用 AWS アカウント (ProdA, ProdB) で生成される CloudTrail 監査ログを、監査専用アカウントの既存 S3 バケット log-central‐bucket に一元保存したい。
セキュリティ部門は以下の要件を提示している。
• 書き込み(アップロード)のみを許可し、読み取り・削除・ACL変更は許可しない
• ログオブジェクトは保存時に必ずサーバーサイド暗号化されていること
• クロスアカウントアクセスは最小権限で実装する
• バケットはログ集約専用で他用途には使わない
これらの要件を満たすために必要な構成として最も適切なものを2つ選択せよ。
CloudTrailが別アカウントのバケットへ書き込む際は、バケットポリシーでサービスプリンシパル cloudtrail.amazonaws.com に s3:PutObject だけを許可し、aws:SourceAccount と aws:SourceArn で対象トレイルを限定すると人手の読取・削除を防ぎつつ最小権限になります。暗号化は PUT 要求に SSE ヘッダーを必須とする方法に加え、バケット側でデフォルト暗号化を有効にしてヘッダー漏れでも自動暗号化させれば二重で安全です。Get/Delete 付与や ACL 制御は要件と合わず注意。書き込み専用・暗号化必須・最小権限・専用バケットという四条件を同時に満たす組み合わせを総合的に選択しましょう。
【SAP-285】あなたは、APAC の 2 つの AWS リージョンを利用して可用性を確保する Web アプリケーションの DR 戦略を設計している。
ワークロードの概要は次のとおりである。
・トラフィックは Application Load Balancer 経由で Amazon ECS(Fargate 起動タイプ)に送られる。
・ビジネスデータは Amazon RDS for PostgreSQL に保存されている。
・コンテナイメージは Amazon ECR に格納している。
経営層からは「災害発生時、最大 18 時間以内にサービスを再開し、最後のバックアップから 6 時間以内のデータ損失で抑えること」「平常時のコストを極力削減すること」が求められた。
最も費用対効果が高く、かつ RTO/RPO を満たす DR アーキテクチャとして最適なものを 1 つ選べ。
求められるのは平常時コスト最小とRTO18時間・RPO6時間の両立です。4つの代表的なDR方式を思い出しましょう。アクティブ-アクティブは高速復旧だが常時二重運用で高コスト。ウォームスタンバイも縮小構成とはいえCPUやDBが動き続け費用が発生します。パイロットライトはDBのみ稼働で比較的安価ですが、イメージ転送や追加デプロイの所要時間がRTOに影響します。最後に残る方式はバックアップ頻度と自動コピーでRPOを満たし、復元とIaC展開を並行すればRTO18時間内に収まるうえ常時のコンピューティング費用が不要です。要件を数値で照合し、費用対効果を総合判断してください。
【SAP-286】社内データセンターで稼働している 3 層構成の BtoC 向けオンライン予約サイトを AWS へ全面移行する計画がある。
必須要件は次のとおり。
1. Web 層および DB 層の高可用性をマルチアベイラビリティーゾーンで確保すること
2. セキュリティを向上させ、DDoS や OWASP Top-10 から保護すること
3. 静的アセット(画像・JS・CSS)は低レイテンシで世界中に配信すること
4. 運用保守作業を最小化し、自己管理ミドルウェアを極力排除すること
上記すべての要件を満たす設計として最も適切なものを 3 つ選べ。
Web層はHTTP向けのロードバランサをインターネット側に置き、裏側のサーバーをAuto Scalingで複数AZへ分散すると、障害時の自動切替と運用省力化が同時に得られます。DBは自動バックアップと秒〜十数秒レベルのフェイルオーバーが組み込まれたフルマネージドMySQL互換サービスを選ぶと、高可用性と保守削減を満たせます。静的コンテンツはS3をオリジンとして世界のエッジにキャッシュする配信網を経由させれば遅延が低く、同じ場所にWAFを仕込むことでDDoSやOWASP Top-10対策も完結します。自己管理ミドルウェアや単一AZ構成は要件達成が難しい点に注意しましょう。四つの必須条件を総合的に眺め、可用性・セキュリティ・配信性能・運用負荷の全てをバランス良く満たす構成を選び出してください。
【SAP-287】ある動画処理サービスは Amazon EC2 Auto Scaling グループで構成されており、需要に応じて数分単位でインスタンス数が増減している。
開発チームは既存の CI/CD パイプラインから本番環境へ 1 日 3 回程度リリースしているが、次の追加要件が発生した。
1. 新しいインスタンスが起動した直後に自動で最新コードを取得して稼働すること
2. 運用担当者の手作業やサービス停止は最小限に抑えること
3. リリース準備から本番反映まで 24 時間以内に完了させること
これらを踏まえ、最小の運用負荷で継続的デプロイを実現する設計として最も適切なものはどれか。
起動直後に最新版を稼働させたいので、スケールアウト時に各インスタンスが即座にデプロイフローへ参加できる仕組みが鍵です。エージェントを含んだAMIをあらかじめ用意し、起動テンプレートを更新しておけば、自動生成されたインスタンスはすぐにCodeDeploy経由でアプリを取得できます。パイプラインからローリング更新を呼び出せばスケールを止めず可用性を維持できます。手動でAMIを差し替えたり起動後に都度インストールする方式は運用負荷や遅延が増えるため、パイプラインとAuto Scaling、CodeDeployを一元化した構成を選びましょう。
【SAP-288】あなたは全社データレイクとしてアカウントAの S3 バケット「dl-central-raw」にペタバイト級データを集約している。数十のアプリケーションが別アカウント・別VPCから当該バケットへ読み書きする必要があるが、会社方針によりインターネット経由および NAT/IGW の利用は全面的に禁止されている。将来的に数百 VPC へ拡張される見込みであり、アプリケーション単位で最小権限を担保しつつサービス固有機能のみで実装する設計として最も適切な手順を2つ選べ。
ペタバイト級共有バケットを他アカウント・多数 VPC から完全プライベートに扱う絵を描いてください。S3 への正式なプライベート経路は Gateway VPC Endpoint で、エンドポイントポリシーを使えば各 VPC が自分の許可されたアクセスポイントだけを呼び出す形に絞れます。最小権限を保つにはバケット所有者がアプリケーション単位で S3 アクセスポイントを発行し、VpcConfiguration で接続元 VPC ID を固定、バケットポリシーではアクセスポイント経由のみ許可するのが効果的です。S3 には Interface Endpoint が無いこと、他アカウントではアクセスポイントを作れないことも合わせて確認しましょう。複数の要件を同時に満たす構成かを俯瞰して選択してください。
【SAP-289】多国籍製造企業Z社は、部門ごとに 40 以上の AWS アカウントを保有している。
日本の個人情報保護法対応のため、開発者が実行するすべての API を ap-northeast-3 (Osaka) 以外のリージョンで受け付けてはならない。
今後も新規アカウントが頻繁に追加される見込みであり、運用部門は最小限のオーバーヘッドでこの制限を一元的に維持したい。
この要件を最も効率的かつ拡張性高く満たす設計はどれか。
多数アカウントを継続的に追加する環境では、アカウント個別の IAM ポリシーや権限セットよりも、組織全体に一括で効く仕組みが管理負荷を抑えます。リージョン制御には条件キー aws:RequestedRegion を用い、Osaka 以外を明示的に Deny するとルートユーザーを含め確実に遮断できます。OU 単位で一度設定すれば、その配下の既存・新規アカウントへ自動継承されるため、アカウント作成後に StackSet を流す必要もありません。Deny を上位 OU でかけた場合に下位で上書きできない継承の特性にも注意しつつ、最小ステップで漏れなく適用できる案を総合的に選びましょう。
【SAP-290】オンプレミスとプライベート接続済みの VPC が 1 つあります。現在は単一の 1 Gbps Direct Connect 回線に 1 つの Private Virtual Interface(VIF)を作成し、VPC の Virtual Private Gateway(VGW)へ直接関連付けています。
今後の要件は次のとおりです。
• 同じロケーションで物理的に冗長な 2 本目の回線を追加し、BGP セッションを冗長化する
• 将来的に別リージョンの複数 VPC へも同じ回線ペア経由で拡張できる設計にする
• AWS が推奨する Direct Connect 高可用性アーキテクチャに準拠する
これらの要件を最も確実に満たすアーキテクチャはどれか。
AWS の高可用性ガイドでは、同一ロケーションに回線を 2 本敷設する際、各回線ごとに個別の Private VIF と BGP セッションを持ち、それらを 1 つの論理ゲートウェイに束ねることを基本としています。将来、別リージョンの VPC へも同じ回線ペアを共有したいなら、その論理ゲートウェイはリージョン非依存である必要があります。リージョンローカルのハブや単一 VIF の LAG 構成では経路制御が複雑化し、推奨パターンから外れる可能性が高い点に注意しましょう。複数回線の冗長化、BGP の二重化、マルチリージョン展開の三要件を一括で満たせるかどうかを総合的に判断してください。