ブックマークページはこちら
正解番号の相違等のご報告はコメントでいただけますと幸いです。技術質問は会員制コミュニティで対応しております。
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-241】毎日 22:00 から平均 3 時間実行されるビジネスクリティカルなバッチ分析ワークロードのために Amazon EMR クラスターを設計しています。
要件は以下のとおりです。
• マスターノードとコアノードはジョブ実行中に中断してはならない。
• タスクノードは中断が許容される。ジョブ完了後はコスト削減のためにタスクノードのみ停止したい。
• クラスターは常時稼働し、マスターノードとコアノード 1 台ずつ (合計 2 台、r6g.xlarge) が最低限必要である。
• コスト最小化を最重要とし、ベースライン需要には割引プランを活用したい。
これらの要件を最も満たす設計はどれか。
マスターとコアは絶対に落とせないのでスポットは避け、常時稼働する r6g.xlarge 2 台分には 1 年コミットの割引プランで固定費を抑える考え方が出発点です。負荷が高まるのは夜間 3 時間だけのため、タスクノードはスポットで構わず、自動スケーリングでジョブ終了までに最小 0 台へ収束させればアイドル料金を排除できます。割引プランは AZ や世代を問わず差額を自動適用できる Compute Savings Plans が柔軟で、コスト重視の要件とも合致します。一方、タスクをオンデマンドに固定すれば日中も課金され、逆に全ノードをスポットにすると中断通知でマスターやコアが停止し業務が破綻します。可用性の担保、短時間の伸縮、長期割引の適用という三つの視点を重ね合わせ、全条件を最もバランス良く満たす組み合わせを導き出してください。
【SAP-242】国内動画配信サービスが期間限定の無料キャンペーンを実施したところ、ユーザ登録テーブル(PostgreSQL on Amazon Aurora)への書き込み要求が平常時 200 TPS からピーク時 15,000 TPS まで瞬間的に跳ね上がることが判明した。
– 既存のリレーショナル・スキーマおよびアプリケーション SQL は改修不可
– 書き込みを取りこぼさず、少なくとも 1 回は確実に DB へコミットすること
– 平常時はコストを抑え、ピーク時のみ自動でスケールさせたい
– 運用チームは少人数で、インフラの手動オペレーションを最小化したい
これらの要件を満たす最適なアーキテクチャはどれか。
既存SQLに手を入れずピーク1.5万TPSを吸収するには、まず高耐久なメッセージバッファに登録要求を溜め、サーバレスで瞬時に横方向へ拡張するワーカーが段階的にAuroraへ書き込む流れを思い描くと要件が整理できます。バッファはほぼ無制限のスループットと少なくとも1回の配信保証を持ち、ワーカーは同時実行を自動調整するため平常時は料金が抑えられます。RDS Proxyが接続を束ねればDB側の負荷も緩和できます。リレーショナル移行や手動スケールが不要で、運用工数を最小にできるかどうかを含め、全ての要件を俯瞰して最適なアーキテクチャを選定しましょう。
【SAP-243】あなたは複数事業部が個別に保有している10の既存 AWS アカウントを、共通のガバナンス下で一元管理したいと考えている。
要件は次のとおりである。
1. すべての既存アカウントを単一の組織に統合すること。
2. 成員アカウントでは Amazon EC2 だけをフルアクセス可能とし、それ以外の AWS サービスは原則使用させないこと。
3. 今後、外部で新規に開設されたアカウントを毎月追加する予定があり、手作業と設定工数を極力抑えたい。
これらの要件を最も効率的かつ拡張性高く満たすために、実施すべきアクションを 2 つ選択せよ。
まず管理側で Organizations を作成し既存アカウントを招待する方法と、各アカウントから参加申請させる方法があります。管理側主体の招待は API 自動化しやすく、毎月の追加でも手順が均一化します。サービス制御は IAM ではなく OU に付与する SCP を使い、EC2 だけを許可する許可リスト型にしておくと、新規アカウントを OU に移すだけで同じ制限を適用できます。ロールの個別展開や VPC 設定での抑止は運用負荷や漏れのリスクが残る点も比較しましょう。三つの要件を俯瞰し、統合手順の簡便さ・ガードレールの強度・拡張時の作業量のバランスで最適な組み合わせを選びましょう。
【SAP-244】電力系スタートアップの DevOps チームは、単一の CodeCommit リポジトリ (repo-energy) を用いて機能開発 (feature/*) と本番 (main) を管理している。
開発者が feature ブランチを push すると、そのブランチ専用のパイプラインを即座に用意し、次の要件を満たしたい。
1. ブランチ作成をトリガーに新しい CI/CD パイプラインを自動生成すること
2. パイプライン内でユニットテストとテストカバレッジ計測を自動実行すること
3. テスト済みアーティファクトは開発アカウント (111111111111) の S3 バケット dev-artifacts のみに保存し、本番アカウント (222222222222) の prod-artifacts には直接書き込まないこと
4. すべてのテストが成功した後にのみ main ブランチへ安全にマージし、そのイベントで本番アカウント側パイプラインを開始すること
5. ソリューションは AWS ネイティブサービスのみで構成し、クロスアカウントアクセスは IAM ロールで制御すること
上記要件を最も効率的かつ保守容易に満たすアプローチはどれか。
ポイントは次のとおりです。
・ブランチが増えるたびに人手なくパイプラインを複製できる仕組みが必要。テンプレートを即時展開できるサービスを思い出しましょう。
・長時間のユニットテストとカバレッジ計測はビルド専用サービスが得意領域。実行上限が短い関数型サービスでは足かせになります。
・アーティファクトは開発用バケットだけに出力し、本番側にはマージ完了後にロールを引き受けてアクセスすることで分離と監査性を確保。
・オンプレミスや外部ツールに頼らず AWS ネイティブで完結させること、クロスアカウント権限は AssumeRole を用いて細かく制御することが必須。
これら要件を同時に満たす構成を複数案で比べ、動的生成の容易さと運用負荷の低さを総合的に判断してください。
【SAP-245】グローバル e コマース企業では、購入イベントを Amazon SNS トピックに発行し、購読している AWS Lambda が Aurora MySQL に注文データを挿入する。通常は問題ないが、販促セール時には数万件/秒のバーストが発生し、同時起動した Lambda が DB 接続上限と CPU を枯渇させ、書き込みの欠落と高遅延が顧客体験を損なっている。失敗した更新は自動再試行され、必要に応じて検証可能で順序保証は不要である。追加の EC2 や自前ミドルウェアを使わず、マネージドサービスのみでバックプレッシャと接続効率を確保し、高可用性を実現するアプローチはどれか?
(2つ選択)
セール時の急激な呼び出しをなだらかにするには、SNS から直接 Lambda を起動する方式を見直し、弾力的にメッセージを貯められるマネージドキューを挟んでバッチ投入や自動再試行を任せるとバックプレッシャーを吸収できます。同時に、爆発的に増える Lambda がデータベースへ個別接続を張り続けないよう、接続プールを提供するマネージド仲介層を経由させれば接続数と CPU を大幅に節約可能です。順序保証は要件外なので高スループットのキュー種別を選び、インスタンス増強や手動運用に頼らず、バッファ・プール・同時実行制御を組み合わせて総合的に高可用性とコスト効率を判断しましょう。
【SAP-246】組織は 10.20.0.0/16 の VPC を使用し、2 つの AZ にまたがって構成しています。
・パブリックサブネット (10.20.0.0/24, 10.20.1.0/24) に Application Load Balancer (ALB) を配置。
・プライベートサブネット (10.20.2.0/24, 10.20.3.0/24) に EC2 Web サーバーを配置し、ポート 80 と 443 のみで待ち受ける。
最小権限の原則に従い、ALB だけが Web サーバーに接続できるよう Network ACL (NACL) を設定したい。
プライベートサブネットの NACL に追加すべきルールを 2 つ選択しなさい。(複数選択)
ALB が置かれている 10.20.0.0/24 と 10.20.1.0/24 をひとまとめにすると 10.20.0.0/23 です。プライベートサブネット側の NACL では、この CIDR から到着する 80・443 を受け入れるインバウンドがまず必要になります。NACL はステートレスのため応答用アウトバウンドも別に許可が要り、戻りパケットは 1024–65535 のエフェメラルポートを用いる点が重要です。0.0.0.0/0 へ広げたり、80・443 を外向きに空けても返答は成立しないこと、さらにセキュリティグループ設定とは問われているレイヤが異なることを忘れないでください。ALB の CIDR、双方向通信、必要ポートの三要素を踏まえ、最小権限を保てる 2 ルールを総合的に選択しましょう。
【SAP-247】急成長中のモバイルゲーム会社は、世界同時開催のトーナメント機能をリリースしたいと考えている。
現在プレイヤー戦績は Amazon Aurora MySQL に格納されており、1 秒あたり 5,000 件のランキング読み取りクエリが発生する見込みである。
要件は次のとおり。
• Aurora を依然として唯一の永続的データソースとする
• ランキング読み取りは 10 ms 未満のレイテンシを維持
• 今後 20 万人超の同時接続にスケールできる設計
• リージョン内 2 つのアベイラビリティーゾーン障害に耐える可用性
• Aurora からの書き込みパターンは変更しなくてもよい
この要件を最も確実に満たすアーキテクチャはどれか。
永続ストレージはAuroraのまま、アプリの書き込み処理は変えないという条件が核心です。1秒あたり5,000件、応答10ms未満、20万同時接続という高読み取り負荷をさばくには、クエリ内容が順位取得である点にも注目しましょう。頻繁な更新があるランキングではレプリケーションラグやディスクI/Oがボトルネックになりがちです。インメモリでスコア順に並び替えられるデータ構造を備え、ノード追加で水平に伸ばせるサービスを利用すれば、超低レイテンシと大規模スケールを同時に満たせます。また複数AZにデータを複製できる仕組みを選べば二重障害にも備えられます。これら要件を総合的に満たせる構成を考えてみてください。
【SAP-248】ある旅行会社は、ユーザーが投稿する短い動画を保存し、自動でサムネイルを生成する新しいワークロードを設計しています。休日の午後には毎分数千本の動画がアップロードされる見込みです。システムは急激なトラフィック増加に合わせて拡張し、処理完了後は即座にユーザー端末へ通知する必要があります。要件を満たす構成の組み合わせを3つ選んでください。
急増するアップロードをアプリ層でさばかずに済ませるには、認証済みクライアントが一時署名付き URL でオブジェクトストレージへ直接 PUT する手法が定番です。取り込み後はイベント通知をキューに流し、バッファリングしつつバックエンド処理を需要に応じて水平に膨らませましょう。キューをポーリングする計算リソースは常駐ではなく秒単位で同時実行数が伸縮するサービスにするとアイドルコストを抑えられます。変換完了後の連絡はメールよりモバイルプッシュを使うことでリアルタイム性を確保できます。これらがすべてサーバーレスで連携し、四つの要件をバランス良く満たしているか総合的に見極めてください。
【SAP-249】あなたはグローバル展開する製造企業のクラウドセンターオブエクセレンス(CCoE)で、200 以上のアカウントと 6 リージョンから成る AWS Organizations を管理している。
各部門(OU 単位)には四半期ごとに変動する利用予算が設定されており、支出が 80%・100% を超えた時点で
1. 部門共通のメールグループ
2. ChatOps 用 Amazon Chime チャネル
へ自動通知することが必須である。
また、新規プロジェクトは CCoE が承認した IaC テンプレートのみでリソースを起動でき、個別アカウントの利用者は予算定義や通知先を変更できてはならない。
この要件を最も効果的かつ運用自動化を維持した形で満たすアクションを 2 つ選択せよ。
四半期ごとのOU予算を一括で配布し、閾値到達時にメールとChimeの両方へ自動通知するには、BudgetsリソースとSNS/EventBridgeを多アカウント多リージョンへ横展開できる仕組みが欲しいですね。さらに利用者を承認済みIaCテンプレート経由の起動に限定するには、セルフサービスを保ちつつテンプレートと権限制御をセットで提供し、他経路を根元で遮断する方法が有効です。異常検知や手動チェック、IAM条件だけでは要件の自動化や統制に不足が残ります。スケールとガバナンス、運用負荷を俯瞰し最も整合的な組合わせを選びましょう。
【SAP-250】あなたは多国展開するフィンテック企業のソリューションアーキテクトである。現行システムはリージョン1で Regional API Gateway、Lambda、単一の DynamoDB テーブルを用いて稼働している。今後リージョン2とリージョン3にも同一の Lambda コードと環境を配置済みで、以下の追加要件を満たすマルチリージョンサーバーレス基盤を構築したい。
1. それぞれのリージョンで低レイテンシ (<50 ms) で API を公開し、クライアントは Route 53 により最寄りかつ正常なリージョンへ誘導されること。
2. 非リレーショナルデータは全リージョンで同時書き込み可能なアクティブ-アクティブ構成とし、リージョン障害時も書き込みが滞らないこと。
3. 単一点障害を排除し、RTO は 5 分未満とする。
4. 追加作業は最小限とし、運用負荷およびコストを抑えること。
上記要件を満たすために取るべきアクションはどれか。2つ選べ。
API は地域ごとの遅延とフェイルオーバーが鍵です。エンドポイントの種類を比較し、Route 53 のレイテンシールーティングとヘルスチェックを組み合わせる手法を思い出しましょう。データは全リージョン同時書き込みが要件なので、キャッシュや一方向レプリケーションでは不十分です。マルチマスターをネイティブに実現でき、追加コードが不要なサービスが最適です。RTO 5 分未満という制約は手動やバッチでは対応困難である点も考慮してください。サービス名に含まれる “Global” や “Regional” の意図を照らし合わせ、API とデータ層の特性を総合的に判断しましょう。