ブックマークページはこちら
正解番号の相違等のご報告はコメントでいただけますと幸いです。技術質問は会員制コミュニティで対応しております。
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-231】あるグローバル企業は 8 つの AWS アカウントを AWS Organizations で統合管理しており、管理アカウントでは Consolidated Billing が有効になっています。
過去 6 か月分の Usage Report から、EC2、AWS Fargate、AWS Lambda を合計した平均オンデマンドコストが 5,000 USD/月、ピーク時はその 2 倍に達することが分かりました。
同社は今後 3 年間にわたって組織全体のコンピューティングコストを可能な限り削減したいと考えています。
変動する需要を考慮しつつ、最も高い割引率を得ながら EC2・Fargate・Lambda の横断的な使用量をカバーできるプランとして、どの選択肢が最も適切でしょうか。
EC2・Fargate・Lambda を横断して割引を効かせたい場合、サービスを限定しない Savings Plan が鍵です。期間を 3 年にすると 1 年契約より割引率が大きくなります。Consolidated Billing で 1 つだけ購入すればコミット額を 8 アカウント全体に自動配分でき、利用の波を相殺できます。コミット額は過去 6 か月の平均程度に合わせ、平常時を網羅しつつピーク超過分のみオンデマンドにすれば過大コミットも回避可能です。Instance 向けプランや特定 RI は対象範囲が狭く、アカウント個別購入では余剰や不足が起こりやすい点を比較し、横断適用・長期契約・集中購入という三要件を満たす案を総合的に選びましょう。
【SAP-232】高度なセキュリティ要件を持つ製造業A社は、オンプレミスで稼働している Oracle 11g データベース(3 TB)を、すでに CMK で暗号化済みの Amazon Aurora PostgreSQL(同一リージョン)へ最小ダウンタイムで移行したい。
前提条件
・データベースは 24 時間更新されている
・会社専用の 1 Gbps Direct Connect(Private VIF)が敷設済み
・インターネット経由を禁止
・転送中/保管時ともに暗号化が必須
移行方式として最も適切なアプローチはどれか。
ダウンタイム最小化には、最初のフルロード後も更新差分を継続的に取り込める仕組みが不可欠です。Oracle から Aurora へ異種エンジン間のレプリケーションを行えるマネージドサービスが何か、思い出してください。インターネットは禁止のため Direct Connect Private VIF とプライベートサブネットを用い、1 Gbps 専用線で 3 TB の初回転送を済ませます。転送中は TLS、保存時は CMK で暗号化するのが自然です。オフラインデバイスや単純バックアップでは差分同期や停止時間で不利、公開ネットワーク利用案は前提違反になる点も整理しましょう。複数要件を一度に満たすサービス構成を選ぶという俯瞰的視点で判断してください。
【SAP-233】ある SaaS チームは、Amazon EKS 上のコンテナと API Gateway で構成されたクラウドネイティブアプリケーションを 1 つのリージョンで運用している。
永続データは Amazon RDS for PostgreSQL と Amazon DynamoDB に保存されている。
IaC(AWS CloudFormation)と CI/CD パイプラインにより、同一構成を他リージョンへ数十分でデプロイできる。
経営陣は「RPO は 4 時間以内、RTO は 8 時間以内、かつ DR コストを最小化する」ことを求めている。
最適な災害復旧戦略を 1 つ選べ。
RPO 4 時間は「バックアップ取得からコピー完了まで」が 4 時間以内、RTO 8 時間は「環境再構築と切替え」を含めて 8 時間以内が目安です。IaC と CI/CD があるなら EKS や API Gateway の再デプロイは数十分で済むため、平常時に全コンポーネントを動かす必要はありません。コストを抑えるには、アプリは最小限だけ先行配置し、RDS と DynamoDB を定期的にクロスリージョンへバックアップコピーしておき、災害時に自動復元と Route 53 などでフェイルオーバーする設計が有効です。バックアップ&リストア、パイロットライト、ウォームスタンバイの違いを整理し、RPO/RTO と費用のバランスを総合的に比較してみてください。
【SAP-234】国内出版社が運営するモバイルクーポン配信サービスでは、
・日曜 20:00〜22:00 に秒間 8,000 リクエスト、他の時間帯は平均 200 rps のバーストトラフィックが発生
・ユーザ入力データ(JSON 可変スキーマ)は 1 TB/月 発生し、原本をそのまま保存しておく必要がある
・月次の経営レポート作成時にアドホックな SQL 解析と BI ダッシュボード可視化を行う
・99.9% 可用性、P95 レイテンシ 150 ms 以下、インフラ月額 40% コスト削減を目標
・最小運用(サーバ/クラスター管理を回避)、自動スケール、リージョン内冗長が必須
この要件を満たすアーキテクチャの組み合わせとして最も適切なものを 2 つ選べ。
ピーク8000rpsを自動吸収するには、水平スケールが自動で行われるフルマネージドAPIが不可欠です。サーバやコンテナの保守が残る構成は「最小運用」の条件に合いません。可変スキーマJSONはオブジェクトストレージへそのまま保存し、サーバレスSQLで直接分析すればETL不要で低コストです。静的サイトはCDNを前段に置き、OACなどでバケットを非公開にすればレイテンシとセキュリティの両立が可能です。BI は常時クラスターを持たない可視化サービスを選ぶことでコスト削減を後押しします。リージョン内冗長を標準で備え、99.9%可用性をサービス側に任せられる構成を選び、サーバレス度・スケール特性・課金形態を総合的に見渡して最適解を判断してください。
【SAP-235】大手メディア企業は、Auto Scaling グループで増減する Amazon EC2 上の Web アプリケーションを Application Load Balancer(ALB)で公開している。
セキュリティチームは次の要件を満たすログ取得基盤を 1 週間以内に構築したい。
• すべてのリクエストについてクライアント IP、接続プロトコル/ポート、ユーザーエージェントを保持する
• 分析インフラはサーバーレスで、オンデマンドに SQL で検索できる
• 過剰なパケット複製や独自解析基盤の運用は避けたい
アーキテクトは次のうちどの設計を採用すべきか。
要件を分解しましょう。取得したいのはクライアント IP や User-Agent など HTTP レイヤの項目です。ネットワークフローやメトリクスだけでは含まれません。ログは低コストで集中保管し、SQL でサーバーレス検索できる必要があるので、S3 + Glue/Athena の組み合わせが定番です。またパケット複製を避けたいのでミラーリング系は外れます。Auto Scaling で台数が変動してもロードバランサ側で一括出力できると運用が楽です。これらを総合し、最もシンプルかつ一週間で構築しやすい案を選んでください。
【SAP-236】あなたはリアルタイム分析を行う分散インメモリ型ワークロードの設計を担当している。ワークロードはプライマリノード 1 台とワーカーノード 12 台で構成され、ワーカーノード間では継続的に大量のデータを複製・同期する必要がある。可用性よりもネットワーク遅延とスループットが最優先であり、ミリ秒未満のレイテンシーを実現しつつ 100 Gbps クラスのインスタンス間帯域を確保したい。
この要件を満たす Amazon EC2 の配置戦略とインスタンスタイプの組み合わせとして、最も適切なものはどれか。
ミリ秒未満かつ 100 Gbps のノード間通信を実現するには、インスタンスを同一ラック近傍に密集させる配置が不可欠です。Cluster Placement Group はこの目的に設計されており、ENA Express 対応の最新メモリ最適化インスタンスなら 100 Gbps を引き出せます。Spread は 1 AZ 7 台の上限と物理距離の長さで低遅延には不向き、Partition は AZ 分散ゆえ遅延と帯域で不利です。汎用や旧世代は最大 50 Gbps 程度に留まるため要件に届きません。大量レプリケーションを伴うインメモリ分析では、メモリ容量と帯域を最大化しつつ台数制限がない構成が望ましいです。距離・帯域・台数・可用性を総合的に見渡し、最も目的に合う組み合わせを選びましょう。
【SAP-237】企業Aはパブリック向けの認証 API を Application Load Balancer(ALB)配下で運用している。最近、失敗したログイン呼び出しが短時間に数千件発生し、攻撃元 IP は都度入れ替わるためブラックリストの手動更新が追いつかない。
同社は
・過負荷による認証サービスのレイテンシを抑制したい
・追加オペレーションを極力なくし、継続的に防御したい
・レイヤ 7 での遮断を優先し、既存の ALB 構成を変更したくない
という要件を掲げている。
最も適切な対応策はどれか。
攻撃は HTTP レイヤで発生し、IP が頻繁に変わります。要件は①既存 ALB をそのまま使い L7 で遮断、②閾値超過時に自動対処し運用負荷を最小化、③過負荷による認証レイテンシを抑える、の三つです。セキュリティグループや Network ACL は L4 までの制御であり動的に大量ルールを追加するのは現実的ではありません。人手で IP を追う方法も攻撃速度に遅れます。ALB に簡単に関連付けられ、IP ごとのリクエスト数を時間窓で集計して自動で遮断や緩和を行うマネージド機能がないかを思い出し、複数要件を俯瞰する総合判断で選択しましょう。
可用性を高めるには、構成要素すべてを障害ドメインをまたいで冗長化することが前提です。まずアプリケーション層は複数 AZ に分散し、ロードバランサが正常ノードへ振り分ける仕組みが必要です。次にデータ層はストレージが 3AZ に自動レプリケートされ、プライマリ障害時に数十秒で自動フェイルオーバーできるフルマネージド型を選ぶと運用が大幅に簡素化されます。スタンバイ DB を自前で切り替える方式は可用性を確保できても運用負荷が残りがちです。リージョン間二重化や NoSQL への全面移行は魅力的ですが、今回の要件では変更工数や整合性制御が追加負担となる点に注意しましょう。アプリと DB の両方をシンプルにマネージドで多重化できる構成が、可用性と運用最小化の観点から総合的に優位となります。
【SAP-239】貴社では、複数部門がそれぞれ独立した AWS アカウントと VPC を保有しています。
中央インフラ部門は「監査ログ集約サービス」を us-east-1 リージョンの専用 VPC で運用しており、Network Load Balancer(NLB)背後の EC2 Auto Scaling グループでログ取込み API を提供しています。
今後 12 部門(最大 15 部門まで拡大予定)の VPC から、このサービスへ完全プライベートにアクセスさせる必要があります。追加要件は次のとおりです。
1. 部門 VPC のいくつかは 10.0.0.0/16 を含む重複 CIDR を使用している。
2. サービス提供 VPC 以外の VPC でルートテーブルを頻繁に変更したくない。
3. 接続を許可する VPC は、事前承認された部門 VPC のみに限定したい。
4. インターネット経由やパブリック IP の露出は一切不可。
5. 将来的に同じ仕組みを別アカウント/同リージョンの VPC にも展開する計画がある。
これら要件をすべて満たす最適な接続方式はどれか。
重複 CIDR をそのまま許容できるか、各部門 VPC のルートテーブルを触らずに済むか、接続元を明示的に承認できるか、インターネットを全く経由しないか、さらに他アカウントでも横展開しやすいか──まずは五つの要件を同時に思い浮かべてください。IP ルーティングを前提とする仕組みは CIDR 重複で通信が止まりやすく、VPN やハブ型ネットワークはパブリック IP の露出を伴うものがあります。一方、ロードバランサ背後のサービスへ、相手 VPC に自動で作成される ENI から直接アクセスし、接続時に承認フローを挟める仕組みなら上記の懸念を一括解消できます。各方式の特徴と制約を一覧化し、五要件を横串で比較する総合判断がカギです。
【SAP-240】あなたの組織ではサービス分離型マルチアカウント構成を採用しています。
・アカウント X:DNS 管理専用。プライベートホストゾーン「db.internal.example.com」が既に存在し、RDS プライベートエンドポイントを CNAME で公開済み。
・アカウント Y:新規に VPC「vpc-app-01」を作成し、EC2/ECS から前述のホスト名で DB へ接続したい。
新規デプロイ後、アプリケーションが DNS 解決に失敗し起動できませんでした。ネットワークは同リージョン、VPC ピアリングは済みでセキュリティグループも許可済みです。ホストゾーンのレコードは正しく、変更を最小限に抑えたい。クロスアカウントでの Route 53 private hosted zone 共有を有効化し、アプリケーションから正しく名前解決できるようにするために取るべき手順の組み合わせはどれですか。(2 つ選択)
プライベートホストゾーンを他アカウントの VPC で使う場合は、まずゾーンを管理する側で VPC 関連付けを許可する認可を発行し、次に利用側でその認可を指定して VPC を関連付ける、という二段階が公式手順です。認可は一度確定すれば削除しても関連付けは残るので、最小限の変更で済みます。VPC ピアリングの DNS 有効化や Resolver エンドポイントは外部やオンプレ連携で用いる仕組みで、このケースでは不要です。同名ゾーンを重複作成すると競合の原因にもなります。権威を一元化しつつ構成を簡潔に保つには、ゾーン所有側の認可発行と利用側の関連付けを組み合わせる総合判断が鍵となります。