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】あるデジタル広告解析会社では、夜間バッチでクリックログを集計し翌朝のレポートとして顧客に提供している。
基盤は EMRFS を利用する Amazon EMR クラスターで、マスター・コア・タスクの全ノードを常時 EC2 オンデマンドインスタンスで稼働させている。
処理は毎日 1:00 に開始し、およそ 6 時間で終了するが、利用者がログを閲覧するのは午後以降のため、完了までの速度は最重要ではない。
一方、経営層は 24 時間稼働による計算コストの増大を問題視しており、インフラ運用チームも可能な限り既存のジョブ定義を変えずに費用を削減したいと考えている。
クラスターはオートスケーリングや自動終了を含む管理機能を利用可能で、ジョブは中断しても再実行で整合性が保たれる設計となっている。
ソリューションアーキテクトは、インフラレベルでコストを最小化しつつ安定したジョブ実行を維持するために、どの構成を採用すべきか。
最適な選択肢はどれか。
EMR クラスターは「マスター(管理)・コア(データ保持+処理)・タスク(処理のみ)」の3種類のノードで構成される。夜間バッチでコストを抑えたいときは、『マスター/コア=オンデマンド、タスク=スポット、ジョブ完了後はクラスター終了』+必要に応じて Savings Plans を組み合わせるパターンを押さえる。EMRFS を使えば入出力データは S3 に保存されるため、クラスターを終了してもデータは残り、レポート閲覧に EMR の起動は不要。Compute Savings Plans は都度購入するものではなく、1年or3年で「1時間あたり○ドル分使う」と一度だけ契約し、以降は自動的に割引が適用される仕組み。オンデマンドの割引にはリザーブドインスタンス(RI)もあるが、RI にはゾーンスコープ(特定AZ固定・キャパシティ予約付き)とリージョンスコープ(AZ柔軟だがインスタンスファミリー固定)の2種類がある。いずれもインスタンスファミリーは固定されるため、インスタンスフリートのように柔軟に構成が変わる EMR には、ファミリー・AZ・OS を問わず割引が効く Compute Savings Plans のほうが適している。MapReduce はデータを分割して並列処理(Map)し結果を集約(Reduce)する分散処理の基本手法。
【SAP-242】ある家電メーカーは新製品発表イベントに向け、AWS上で特設サイトを運営している。
サイトは製品紹介と、来場予約・アンケートを受け付けるログイン機能を提供し、入力データは Amazon RDS for PostgreSQL に格納している。
テレビCMと連動した瞬間的なアクセス増により秒間で数万件の書き込みが発生すると予測されるが、既存テーブルを変更する時間も余裕もない。
ビジネス部門は「申し込み情報が一件でも失われれば販売機会を逸する」と危惧し、インフラ担当は少人数運用のまま突発負荷を平滑化したいと考えている。
アプリケーションでの再送制御は困難なため、データベースにコミットされるまで送信内容を確実かつ耐久的に保持できるバッファ層が必要になる。
これらの事情を踏まえ、ソリューションアーキテクトは高い耐久性を備えたキューイングサービスを挿入し、可変トラフィックを吸収しながら順次 RDS へ書き込む構成をインフラレベルで決定する必要がある。
ソリューションアーキテクトが採用すべき AWS サービスとアーキテクチャはどれか?
RDS への突発書き込みスパイクには「SQS でバッファして Lambda で順次書き込み」のパターンが定石です。Lambda はキューからメッセージを取り出して RDS に INSERT する橋渡し役です。DB スケールアップだけではスパイクを吸収しきれず、データ損失リスクも残ります。なお、実運用では Lambda の並列実行による接続数増加に備えて RDS Proxy を併用するとさらに堅牢になります。
【SAP-243】あるオンライン決済プラットフォームを運営する企業では、開発部門ごとに10の既存 AWS アカウントを保有し、Amazon EC2 上でマイクロサービスを提供している。
今後チームが増え続けることを踏まえ、運用部門は「全アカウントを単一の AWS Organizations 配下に統合し、各チームには EC2 だけをフルに使わせ、それ以外のサービス利用を抑止する」という新たなガバナンス方針を定めた。
これはコストの予測精度を高め、内部監査を迅速化する経営判断に基づく。
運用負荷を抑えるため、追加アカウントには極力手作業ゼロで同じ制限を適用できる仕組みが求められている。
ソリューションアーキテクトは、インフラ設計の観点からどの手順の組み合わせを採用すべきと判断すべきか。
最適な組み合わせを二つ選べ。
Organizations+SCP を使って『EC2 のみ許可』という制約を OU 単位で一括適用するパターンを思い出す。「2 つ選べ」では、同じ役割の選択肢を 2 つ選ばず、異なるステップ(①基盤構築 ②ポリシー適用)をそれぞれカバーする選択肢を組み合わせることがポイント。似た内容の選択肢が複数ある場合、どちらを選んでも技術的には成立するように見えるが、試験では「より簡潔で本質的な方が正解、冗長な方がダミー」というパターンが多い。惑わされずに、2 つの選択肢が異なるステップをカバーしているかを確認しよう。
【SAP-244】オンライン小売プラットフォームを運営するある会社では、ユーザーにリアルタイム価格更新を含む Web アプリケーションを提供し、ソース管理に AWS CodeCommit、CI/CD に AWS CodePipeline を使用している。
現在は単一パイプラインでユニットテストを実行した後、ビルド成果物を Amazon S3 に配置し本番へ展開しているが、開発組織の拡大に伴いワークフローの分離と高速化が課題になっている。
経営層は「新機能を迅速に試しつつ、本番の可用性と顧客体験を損なわないこと」を最優先と考えており、その背景で CI/CD の統制と監査も強化したいと要望している。
ソリューションアーキテクトには次の技術要件が提示された。
①新機能開発を支援する新しいパイプラインを用意し、開発中は本番アプリケーションに影響を与えないこと。
②ユニットテストを自動的に実行し、継続的テストを組み込むこと。
③開発環境と本番環境の成果物を物理的または論理的に分離し、誤配布を防止すること。
④承認済みのテスト完了コードのみを本番ブランチにマージできる仕組みを提供し、運用負荷とスケール要件に耐えること。
インフラ設計レベルで判断する同アーキテクトは、これらの制約とビジネス目標を同時に満たすため、どの AWS サービス構成/アプローチを採用すべきか?
【CI/CD の基本】CI(継続的インテグレーション)はコード変更のたびに自動でビルド・テストを行う仕組み、CD(継続的デリバリー/デプロイ)はテスト済みコードを自動で環境にデプロイする仕組みである。AWS では CodePipeline がワークフロー全体の管理、CodeBuild がビルド・テスト実行、CodeDeploy がデプロイを担当する。
【用語の整理】
・フィーチャーブランチ:新機能ごとに本番ブランチから枝分かれさせる作業用ブランチ。作業完了後に本番ブランチへマージ(統合)する。
・ビルド成果物(アーティファクト):ソースコードをビルドした結果できる、実際に動かすためのファイル(.jar、.zip など)。
・ステージング:本番に出す前に一時的な場所(テスト用 S3 など)に成果物を配置して確認すること。
・ブランチ保護ルール:指定したブランチに対して、レビューや承認なしに直接変更できないようにする設定。
【読み解きのコツ】問題文の要件①〜④を整理すると、①=開発用パイプラインを本番と分ける、②=自動テスト、③=成果物の置き場所を環境ごとに分ける、④=承認なしに本番マージさせない、という 4 つのチェック項目になる。各選択肢がこの 4 つをすべて満たすかどうかを確認する。特に「環境分離」は S3 バケットやアカウントの分離であり、リポジトリの分離とは異なる点に注意。フィーチャーブランチ用パイプラインで、CodeBuild によるテストとテスト用アカウント S3 への成果物配置、および CodePipeline の承認アクションによる本番ブランチ統制というキーワードに着目する。
【SAP-245】映像配信プラットフォームを運営するある企業では、アップロードされた動画からメタデータを抽出し、利用者がタイトルや出演者名で即時検索できる機能を提供している。
処理は S3 への配置を契機に SNS トピックへ通知し、購読する複数の Lambda 関数がファイルを解析して RDS PostgreSQL インスタンスへメタデータを書き込む構成としている。
新たに「アップロード後 5 分以内に検索結果へ反映する」という SLA を顧客と締結したが、繁忙時間帯にはメタデータの反映が遅延・欠落し、苦情が増えている。
調査の結果、同時間帯はデータベース CPU が飽和し、Lambda からの接続数増加に起因する呼び出し失敗も発生している。
運用チームは少数で、保守コストを抑えつつ自動スケールするマネージドサービスを優先したい。
ビジネス上の狙いは SLA 準拠と顧客満足度向上、技術的には DB 負荷の平準化と Lambda 処理の再試行保証である。
ソリューションアーキテクトはインフラ設計レベルでどのアクションを組み合わせて採用すべきか。
最適な 2 つの選択肢はどれか?
『Lambda 多数+RDS 負荷スパイク』には、RDS Proxy で接続をプールしつつ、SNS→SQS→Lambda でバッファと再試行を挟むパターンを押さえておく。なお、RDS Proxy は読み取りだけでなく書き込み(INSERT/UPDATE)にも有効であり、コネクション管理の最適化は SQL の種類に依存しない点も覚えておく。
【SAP-246】オンラインニュース配信サービスを運営するある会社では、読者向けに記事や動画を配信する Web アプリケーションを Amazon VPC 上で提供している。
パブリックサブネット(10.0.0.0/24)にはインターネット向けのアプリケーションロードバランサー(ALB)を配置し、プライベートサブネット(10.0.1.0/24)では複数の Amazon EC2 がポート80で Web サーバを稼働させている。
運用チームはオートスケールに備えてサブネット単位でステートレスに通信を制御する方針を採っており、各サブネット専用のネットワーク ACL を利用している。
最近のセキュリティ監査で「外部や他サブネットからの不要な横方向通信を排除し、ALB からバックエンドへの HTTP トラフィックのみに限定せよ」との指摘があり、NACL のルールを最小限にしたいと考えている。
ビジネス上は閲覧性能を保ったまま攻撃面を縮小することが目的で、技術的には ALB からプライベートサブネットへのポート80通信と、その戻りトラフィックだけを許可する必要がある。
ソリューションアーキテクトはインフラレベルでどの NACL ルールを設定すべきか。
該当する選択肢はどれか?(2つ選択)
【NACL(ネットワークACL)とは】NACL(Network Access Control List)とは、VPC のサブネット単位で通信の許可・拒否を制御するファイアウォール機能である。セキュリティグループが EC2 インスタンス単位で制御するのに対し、NACL はサブネットを出入りするすべてのトラフィックに適用される。最大の特徴は「ステートレス」である点で、行きの通信を許可しても戻りの通信は自動的に許可されず、両方向のルールを明示的に設定する必要がある。
【ポート80とは】ポート番号とは、コンピュータ上で動作する複数のアプリケーションを区別するための番号(0〜65535)である。ポート80は HTTP(Webサイトの閲覧に使う通信プロトコル)に標準的に割り当てられた番号であり、「ポート80で Web サーバを稼働」とは、そのサーバが HTTP リクエストをポート80で待ち受けている状態を意味する。HTTPS の場合はポート443が標準となる。
NACL はステートレスなので、『ALB→EC2 の 80 番インバウンド』と『EC2→ALB へのエフェメラルポート宛ての戻りアウトバウンド』の 2 本を CIDR とポートでペアにして許可するイメージを持つ。NACL ルールで指定するポートは宛先ポートである点にも注意する。
【エフェメラルポートとは】クライアント(ここでは ALB)が通信を開始するとき、OS が自動的に割り当てる一時的な送信元ポート(1024〜65535)のこと。サーバ(EC2)はレスポンスをこのポートに返すため、戻り方向の NACL ではこの範囲を宛先ポートとして許可する必要がある。問題文に「ポート80で Web サーバを稼働」とあれば、行きは宛先ポート80、戻りは宛先ポートがエフェメラルポート範囲になる、とセットで考えるのが定石である。
【SAP-247】あるモバイルゲームを提供するオンラインエンターテインメント企業は、Amazon RDS の Multi-AZ 構成でプレイヤーのスコアを管理し、アプリからランキング画面を即時表示しています。
イベント施策により日次アクティブユーザーが増加し、各プレイヤーの順位を取得する SELECT クエリが徐々に遅延しており、経営陣は表示速度の低下がユーザー離脱に直結すると危惧しています。
次期大型アップデートではさらに利用者が急増すると想定しており、瞬間的な読み取り負荷を自動で吸収しながら高可用性を維持することがビジネス上不可欠です。
運用部門は既存の RDS 運用フローやフェイルオーバー手順を変えず、書き込みの整合性も保持したい意向です。
ビジネス目標は「スコアが即座に反映される快適な体験」を提供することであり、技術的課題は読み取り性能向上と水平スケールの両立にあります。
ソリューションアーキテクトはこれらの要件を満たすインフラ設計として、どの構成を採用すべきか?
RDS はソース・オブ・トゥルース(正式なデータの保管場所)のままにして、読み取り負荷は ElastiCache for Redis に逃がすパターンをイメージすると解きやすいです。リードレプリカも読み取り分散に使えますが、「サブミリ秒のレイテンシ」「ソート済みセットによる効率的なランキング取得」「瞬間スパイクへの高い弾力性」といった点で ElastiCache が優位です。DynamoDB+DAX や Kinesis+Redshift も高スループットな読み取りは可能ですが、本問では RDS を中心に据えたままリアルタイムなランキング表示をどう実現するかがポイントです。なお、「ElastiCache はインメモリだからデータが消える」と心配になるかもしれませんが、データの永続保管は RDS が担い、ElastiCache は読み取り専用のキャッシュ層です。消えても RDS から再構築できるため、揮発性は問題になりません。また、書き込み整合性は RDS Multi-AZ の同期レプリケーションで引き続き保証されます。「永続化・整合性は RDS」「高速読み取りは ElastiCache」と役割を分けて考えましょう。
【SAP-248】ある企業は中古品売買プラットフォームを運営しており、スマートフォンアプリ経由で出品者が撮影した商品画像を Amazon S3 に保存し、Amazon Rekognition で自動タグ付けした結果を通知しています。
平日 8 時〜17 時に需要が集中し、ピーク時には毎分数千枚の画像がアップロードされるため、バッチではなくリアルタイム処理が欠かせません。
最近のテレビ CM により流通量が急増しており、経営層は「即時プレビューが売上転換率を高める」と判断して、遅延を最小化しつつインフラコストを営業時間外に抑制したいと考えています。
運用担当は少人数で 24 時間の手動対応が難しく、自動スケーリングとマネージドサービスの活用が必須という制約があります。
ソリューションアーキテクトは、画像取込から分析、結果通知までのパイプラインをインフラレベルでどのように設計・設定すべきかを検討している。
ビジネス上の狙いは「ピークに合わせた弾力的スケール」と「非ピーク時のコスト最適化」、技術的な要件は「高スループットな保存先」「イベント駆動型の並列処理」「処理完了後のユーザー即時通知」である。
これらを同時に満たす構成/アプローチを組み合わせた正しい選択肢はどれか?(3 つ選べ)
大量画像のリアルタイム処理では、S3→SQS→Lambda→SNS というサーバレスなイベントチェーンをイメージすると整理しやすい。
解き方のコツとして、問題文にある3つの技術要件「①高スループットな保存先」「②イベント駆動型の並列処理」「③処理完了後のユーザー即時通知」をそれぞれ独立した観点として捉え、各選択肢がどの要件を担当するかをマッピングすると効率的に絞り込める。①→S3 直接アップロード+SQS バッファ、②→SQS トリガーの Lambda+Rekognition、③→SNS プッシュ通知、のように対応付けてみよう。
【SAP-249】広告配信プラットフォームを運営するある企業では、Webログを解析して広告効果レポートを生成する仕組みをAmazon EMRで提供しており、国内外のマーケティング担当者が日次で分析結果を参照している。
最近の原価高騰を受けてCFOが「部門単位でクラウド費用を可視化し、予算超過時は速やかに是正せよ」と指示したため、各チームにEMR専用の月次予算を割り当て、しきい値到達時には共通の予算管理メーリングリストへ通知する方針となった。
同社は複数AWSアカウントを組織単位で運用しており、財務部は個別アカウントに手作業で設定を入れる工数を確保できない。
さらに、拡張やアカウント追加が頻繁に発生するため、設定は自動的に横展開され、運用チームが一元的に統制できることが必須条件となる。
ソリューションアーキテクトは、このマルチアカウント環境において、コスト配分タグを保持したままEMRクラスタの予算通知を中央から積極的かつ集中的に強制適用する仕組みを設計する必要がある。
インフラレベルで採用すべきステップの組み合わせとして最も適切な選択肢はどれか?(2つ選択)
マルチアカウントのコスト統制では『CloudFormation で Budgets を配布』『Service Catalog 経由で標準テンプレートだけ起動』という組み合わせを思い出す。問題文に「手作業不可」「自動横展開」「一元統制」のキーワードがあれば、IaC(コード化)+ガバナンスサービスが正解パターン。不正解の選択肢は「手動監視(選択肢3)」「分散管理・独自スクリプト(選択肢4)」「予算未設定・後追いレポートのみ(選択肢5)」のように、中央統制や自動通知が欠けている点で除外できる。
【SAP-250】ある旅行予約プラットフォームを運営する企業では、顧客や提携航空会社にフライト検索結果を返すサーバーレス API を公開している。
API は Amazon API Gateway のリージョナルエンドポイントで提供され、検索ロジックは複数の AWS Lambda 関数、在庫やキャッシュは Amazon DynamoDB に格納している。
現在は eu-west-1 のみで稼働しているが、米国ユーザー増加による待機時間短縮とリージョン障害時の事業継続を目的に、us-east-1 でも同一 API を展開し、両リージョンから同一データへ即時アクセスできる体制が必要となった。
Lambda 関数は既に us-east-1 へデプロイ済みで、運用チームは IaC による統一管理を維持しつつ、アプリ側改修や手動同期を極力避けたいと考えている。
また、急激なトラフィック増に追従できる水平スケールを前提とし、管理負荷を最小化することが経営上の要件である。
ソリューションアーキテクトは、高可用性とデータ整合性を満たすインフラレベルの追加対応として何を実施すべきか。
最適な選択肢を二つ選べ。
多リージョン DynamoDB ではまずグローバルテーブルを想起し、API Gateway は各リージョンに Regional エンドポイントをデプロイするパターンを押さえてください。グローバルテーブル(現行バージョン)ではレプリカリージョンを追加するだけでレプリケーションが自動管理されます(内部的に DynamoDB Streams を利用)。リージョナルエンドポイントとは、CloudFront を介さずにそのリージョンで直接 API リクエストを受け付ける方式で、リージョンごとに異なる URL が発行されます。ユーザーを自動で最寄りリージョンに振り分けるには Route 53(レイテンシベースルーティング等)+カスタムドメインの構成が一般的です。「Lambda と統合する」とは、API Gateway が受けたリクエストをバックエンドの Lambda 関数に転送する設定のことで、同一リージョン内で API Gateway と Lambda を紐付けるのが基本です。エッジ最適化や DAX だけでは DR とデータ整合性の要件を満たせません。
この教材の改善リクエストがある場合は、お気軽にご報告ください。
カテゴリを選択のうえ、詳細をご記入いただけますと幸いです。
CloudTech(クラウドテック)は多くのユーザーの皆様から改善リクエストをご協力いただき運営できております。
あなたの視点での気づきは他の学習者の迷いを解決する手助けとなります。
運営側でもチェックをしておりますが限界があるため、誠に恐縮ではございますが細かい点でもご遠慮なくご指摘をお願いいたします。
※ 匿名での報告となり、内容は一般公開されません。
※ 技術的なご質問への回答を行うフォームではございませんのでご注意ください。
