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】あるオンライン小売向け分析プラットフォームを展開する企業では、商品在庫や売上統計を Amazon DynamoDB の複数テーブルに保管している。
このデータを外部パートナーやサードパーティ開発者に公開し、HTTPS で呼び出せるシンプルな API として提供することで、連携サービスを増やし市場シェアを拡大したいと考えている。
新 API はリクエスト数が時間帯によって 10 倍以上変動するため、ピーク時でも過剰キャパシティを持たず自動的にスケールし、インフラ運用を最小化する完全サーバーレスであることが前提となる。
可用性 99.9% 以上を維持しつつ既存の DynamoDB テーブル構造を変更しないという技術制約もある。
ソリューションアーキテクトはインフラストラクチャレベルで、これらのビジネス上の狙いと技術的条件を同時に満たす構成を選定する必要がある。
どのアプローチを採用すべきか、最適な組み合わせを二つ選べ。
完全サーバーレスかどうかと、API 管理機能(認証・スロットリング・ステージングなど)がどこで提供されるかに注目してください。API Gateway と DynamoDB あるいは Lambda の組み合わせがキーワードであり、ロードバランサー系サービスや Global Accelerator は本問の用途には過剰であることを意識すると選びやすくなります。
【SAP-282】あるオンライン広告分析会社は、クライアントへリアルタイムのクリックストリーム解析レポートを配信している。
Amazon EMR クラスター上で Spark ジョブを実行し、各ジョブは複数の Amazon SQS キューを取り込む Step Functions Express Workflow から随時呼び出されている。
トラフィックは日々大きく変動し、CloudWatch では CPU 使用率がピークでも 25% にとどまり、残りの時間はほぼアイドル状態である。
経営層はジョブ完了時間を延長させずに運用コストを大幅に削減する方針を打ち出しており、運用チームは手動スケールや複雑なオペレーションを増やさずに済む構成を求めている。
ビジネス上は即時レポート提供が必須である一方、技術的には SQS のメッセージを遅延なく処理できるスケーラビリティと、アイドル時のコスト最適化が制約条件となる。
この分析基盤は既存の長時間稼働 EMR クラスターを前提としており、ソリューションアーキテクトはクラスターのインスタンス構成レベルでどのアプローチを採用すべきか。
最もコスト効率が高い選択肢はどれか?
EMR クラスタのコスト最適化では、オンデマンドを土台にしてタスクノードに容量最適化された Spot フリートとオートスケーリングを組み合わせる構成を最優先で検討する。
【SAP-283】ある SaaS 企業は、顧客に分析ダッシュボードを提供するマルチテナント基盤を、単一の AWS アカウント上で API、ETL バッチ、リアルタイム処理など複数のワークロードとして稼働させている。
利用者と機能が急増するなか、経営陣はガバナンス強化とコスト予測精度向上を目的に、「エンジニアは承認済みリソースだけを AWS CloudFormation 経由でプロビジョニングする」という新方針を策定した。
運用部門はアカウント分割を行わず現行の自動化とスケーラビリティを維持したいと考えている。
技術面では、未承認サービスやリージョンへの直接操作を禁止しつつ、CloudFormation がスタック作成時に必要とする IAM 権限は阻害しないことが要件である。
これらの条件を満たすため、ソリューションアーキテクトはエンジニアが Assume する IAM ロールにどのような機能を組み込み、どのレベルで制御を適用すべきか。
最も適切な選択肢はどれか?
『エンジニアロールは CloudFormation だけ実行』『実リソース権限は CloudFormation サービスロールに集約』という二段構えをイメージする。
【SAP-284】オンライン決済サービスを展開するある企業では、単一リージョン内で 決済本番/分析用/監査用 の 3 つの AWS アカウントを使い分け、利用者に24時間稼働の決済APIと管理ポータルを提供している。
セキュリティ監査強化方針により、各アカウントの Elastic Load Balancer が出力するアクセスログを一元的に保管し、事後分析や不正取引調査に即座に活用できる体制を整える必要が生じた。
ログは中央管理専用アカウントの既存 S3 バケット sample-s3-bucket に集約し、保存データは必ず暗号化状態で保持することが経営層から求められている。
中央アカウントでは ELB を運用せず、他のワークロードも置かないため、最小限の権限で運用負荷を抑える構成が望ましい。
各アカウントにおける運用担当者はスケーラビリティを損なわず自動でログが転送される仕組みを維持しつつ、暗号化やアクセス制御の設定ミスが発生しないよう Infrastructure as Code で共通設定を適用しようと考えている。
ソリューションアーキテクトは、これらの技術的要件(保存時暗号化、マルチアカウント集約)とビジネス上の狙い(監査対応迅速化、運用コスト削減)を同時に満たすため、インフラ設計レベルでどの手順の組み合わせを選択すべきか。
最適な2つの選択肢はどれか?
各アカウント個別バケット案は集約と運用コスト削減の狙いと矛盾する。中央アカウント単一バケット+書き込み専用クロスアカウント権限+SSE-S3 デフォルト暗号化、という組み合わせになっているかどうかを確認してください。
【SAP-285】あるITサービス企業は、OSSコミュニティ向けのディスカッションフォーラムを提供している。
ユーザーはブラウザやモバイルアプリから投稿・検索し、リアルタイムに回答を得ている。
アプリケーションは Application Load Balancer と Amazon ECS 上の Docker コンテナで稼働し、データは Amazon RDS for MySQL、コンテナイメージは Amazon ECR に保存している。
有償サブスクリプション開始に伴い、顧客契約に「RTO 24 時間以内、RPO 8 時間以内」の災害対策 SLA を明記する必要が生じた。
運用チームは小規模で、通常運用コストを抑えつつ自動スケーリングとパッチ適用をマネージドサービスに委ねる方針である。
ビジネス上はサービス停止による解約率を低減することが狙いで、技術的にはステートレスなアプリケーション層の複製と RDS スナップショット/レプリケーションを組み合わせたリージョン間復旧が必須となる。
ソリューションアーキテクトは、上記のビジネス要件と技術要件を満たし、かつ最も費用対効果の高い構成を採用する必要がある。
採用すべきアプローチはどれか?
RTO/RPO 要件とコストのバランスを見るときは、「どこまでを常時起動にするか」「どこからをスナップショット+IaC で復旧するか」に注目してください。RTO 24h・RPO 8h なら、セカンダリをフル常時稼働にする必要はありません。
【SAP-286】ある会社は家電や日用品を扱うオンライン小売事業を展開し、全国の顧客がブラウザやモバイルアプリから商品を検索・購入できるECサイトを提供している。
ユーザー急増により、オンプレミスのWebサーバーとMySQLではピーク性能と障害対応が限界に近く、少人数の運用部門でも扱えるスケーラブルかつマネージドな基盤への移行が経営課題となった。
経営陣は「信用を損なう停止や不正アクセスを防ぎ、配送遅延を抑制して全国展開を加速する」ことを最優先とし、その手段としてAWSへのリフト&シフトを採択している。
技術的には、通信およびデータ暗号化とWAFによる攻撃防御でセキュリティを高める、マルチAZ構成とオートスケールによって高可用性と低レイテンシーを得る、フルマネージドサービスでパッチ適用やバックアップを自動化して運用負荷を下げる、という三つの狙いがある。
ソリューションアーキテクトはこれらの要件を満たすインフラ設計レベルの移行手順を策定しなければならない。
提示された選択肢のうち、最適な手順の組み合わせはどれか。
(3つ選択)
セキュリティ・可用性・運用自動化の 3 つの観点を「アプリ層(ALB+ASG)」「DB 層(Aurora MySQL マルチ AZ)」「静的コンテンツ+WAF(S3+CloudFront+WAF)」にそれぞれ対応させて考えると整理しやすくなります。オンプレの自己管理要素をできるだけフルマネージドサービスに置き換えているかを確認してください。
【SAP-287】あるオンライン学習プラットフォームを運営する会社は、動画変換 API を SaaS 形式で顧客に提供している。
ユーザーは教材動画をアップロードするだけで数分以内にマルチビットレート版を取得できる。
バックエンドは Amazon EC2 Auto Scaling グループ上のインスタンスで稼働し、CI/CD パイプラインには AWS CodePipeline と CodeDeploy を利用している。
需要変動でインスタンスが頻繁に入れ替わるため、これまでは新バージョンを出すたびに担当者が各インスタンスへ CodeDeploy エージェントを手動でインストールし、デプロイメントグループへ登録してきた。
24 時間後に控える新機能リリースを機に、少人数の運用チームはこの反復作業を完全に排除したいと考えている。
ビジネス上は、今後のユーザー増加に伴うスケールアウト時でも継続的デリバリーが遅延せず、ヒューマンエラーも抑制できることが求められる。
一方、技術的には既存の Auto Scaling 構成と CodePipeline を変更せずに、アプリケーションコードのデプロイを全自動化する必要がある。
ソリューションアーキテクトは、インフラレベルでどのアプローチを採用すべきか。
最も適切な選択肢はどれか?
Auto Scaling で増える EC2 へ手作業なしに CodeDeploy を適用するには、どこにエージェントを仕込んで、何をデプロイメントターゲットにすべきかを意識する。
【SAP-288】ある金融分析企業では、取引ログを集約したデータレイクを Amazon S3 上で運用し、複数 AWS アカウントにまたがる数百のアプリケーションがこのデータを用いて社内アナリスト向けダッシュボードをリアルタイム提供している。
最新の金融規制への対応を背景に、経営層は「S3 バケットを公共インターネットに一切公開しない」「各アプリケーションには業務遂行に必要な最小権限のみ付与する」というセキュリティ方針を強化した。
運用部門は今後もアカウントや VPC が増えていくことを想定し、統治コストを抑えつつスケールできる権限制御モデルを求めている。
技術的要件としては、全アプリケーションが高スループットで S3 に読み書きできること、ただし通信経路は社内ネットワークないし VPC エンドポイントに限定されることが必須である。
この状況を踏まえ、ソリューションアーキテクトはアプリケーションごとに特定 VPC に制限した S3 アクセスポイントを導入する構想を立てている。
インフラ設計レベルで何を作成し、どのリソース間にどのような関連付けやポリシー設定を行うべきかを判断しなければならない。
ソリューションアーキテクトは最終的にどの手順の組み合わせを採用すべきか?(2つ選択)
データレイク用 S3 をインターネットに出さずにマルチアカウントから安全に使いたいときは、『バケット所有アカウントで S3 アクセスポイントを作成+各 VPC に S3 ゲートウェイエンドポイント+両方のポリシーで最小権限』という組み合わせを思い出す。
【SAP-289】ヨーロッパ各国でECプラットフォームを展開するある大手小売企業では、注文処理システム一式をオンプレミスから AWS に段階的に移行している。
利用者は Web とモバイルアプリを通じてリアルタイム在庫照会と購入を行っており、開発者は CI/CD パイプライン経由で頻繁に機能をデプロイしている。
同社は事業部門ごとに複数の AWS アカウントを保有し、中央のクラウド CoE がガバナンスを統括している。
EU 一般データ保護規則(GDPR)への準拠を強化するため、経営陣は「開発者が AWS マネジメントコンソールおよび各種 API を通じて操作できるリージョンを欧州リージョン(例: eu-west-1、eu-central-1)に限定する」という新方針を決定した。
将来の M&A によりアカウント数が増えても一元的に適用でき、日常運用の手間を増やさないことが条件である。
ソリューションアーキテクトは、この制約を各アカウントに横断的かつスケーラブルに反映し、追加設定やロールオーバー発生時の管理コストを最小に抑えるためにどのアプローチを採用すべきか?
リージョン制限のような全社ポリシーは、Organizations の OU+SCP で一括管理し、IAM ロール/ユーザー側では細かな権限付与に専念させる。
【SAP-290】あるSaaS型プロジェクト管理ツールを展開するITサービス企業では、世界10都市の拠点から東京リージョンのVPC上で稼働するAPIとRDBに1 Gbps AWS Direct Connect(DX)経由でアクセスしている。
オンプレミス側には単一のプライベート仮想インターフェースを設定し、1つのVPCとだけ通信している状態だ。
新たに大口顧客とSLA99.9%の契約を締結したため、回線断があっても業務停止しない冗長性が必須となった。
さらに来期には北米リージョンへ同一システムを展開する計画があり、追加のDXを増やさず既存のDXペア経由でマルチリージョン接続を実現したい、という経営上の要望がある。
運用チームは少人数で、リージョンごとに個別の接続を管理するオーバーヘッドは避けたい。
ソリューションアーキテクトは、同一リージョン内で冗長DX接続を確保しつつ、将来のリージョン拡張にもスケールするインフラ設計として、どの構成を採用すべきか。
要件をすべて満たす選択肢はどれか?
Direct Connect ゲートウェイは「DX 側のハブ」、トランジットゲートウェイは「VPC 側のハブ」として役割が異なります。DX を増やさずに複数リージョンへ広げたい、という要件には DX ゲートウェイを使う構成かどうかに注目すると選びやすくなります。
教材の改善ご提案やご指摘を承るフォームです。
この教材の改善リクエストがある場合は、お気軽にご報告ください。
カテゴリを選択のうえ、詳細をご記入いただけますと幸いです。
CloudTech(クラウドテック)は多くのユーザーの皆様から改善リクエストをご協力いただき運営できております。
あなたの視点での気づきは他の学習者の迷いを解決する手助けとなります。
運営側でもチェックをしておりますが限界があるため、誠に恐縮ではございますが細かい点でもご遠慮なくご指摘をお願いいたします。
※ 匿名での報告となり、内容は一般公開されません。
※ 技術的なご質問への回答を行うフォームではございませんのでご注意ください。
