SAA-251-260

【SAP-251】あるファッション雑貨を扱うオンライン小売会社では、北米とアジアの顧客に24時間アクセス可能な EC サイトを提供している。
サイト基盤は複数リージョンの Amazon EC2 と ELB で構築し、決済・在庫情報を Amazon RDS for MySQL に保存している。
先月の大型セール中に発生した DB 障害で売上が大きく落ちたことを受け、経営陣は「単一点障害を排除し、自動フェイルオーバーで数分以内に復旧する」ことを必須の運用ポリシーと定めた。
運用チームは人的オペレーションを最小化しつつコスト増は許容するが、アプリケーション改修を伴う大規模移行は避けたいという制約がある。
リージョン間レイテンシは許容範囲であり、最優先はデータベース層の可用性である。
ソリューションアーキテクトはこれらの要件を満たすため、インフラレベルでどの構成を採用すべきか？最も高い可用性を実現する選択肢はどれか。

【SAP-252】国内外に店舗を展開する小売チェーン向け在庫管理 SaaS を運営するテック企業 A 社は、AWS Organizations 配下に 50 のメンバーアカウントを保持している。
各事業部が複数 VPC を所有し、アプリは VPC 間を横断してリアルタイム在庫 API を呼び出すことで統合ダッシュボードを提供している。
今後は M&A により新規アカウントが継続的に追加される計画があり、手動ネットワーク設定ではビジネス展開が遅れるとの経営判断から、ネットワーク部門は単一の AWS Transit Gateway で全 VPC を相互接続し、アカウント作成と同時に新規 VPC と Transit Gateway アタッチメントが自動生成される仕組みを求めている。
少人数運用でも拡張性と統制を両立させるのが狙いだ。
ソリューションアーキテクトは、Organizations と統合された自動デプロイ機構を用いて、どのサービスと設定を組み合わせればインフラレベルでこの自動化を実現できるかを評価しなければならない。
以下の選択肢から、要件を満たすステップの組み合わせを 2 つ選べ。

【SAP-253】総合ECプラットフォームを運営するある会社では、購入情報や在庫を管理する基幹システムを AWS 上で稼働させており、トランザクションデータは Amazon RDS for MySQL（マルチ AZ 配置）に永続化している。
利用者は Web とモバイルアプリから1秒以内の応答で注文を完了できる体験を期待しているため、年4回のセール期間中は特に可用性が重要となる。
先日の冗長化検証では、AZ 障害発生時のフェイルオーバーに約40 秒を要し、その間は購入処理が完全に停止した。
経営陣は「決済画面での離脱による売上損失を最小化したい」との理由から、同停止時間を 20 秒未満に短縮する方針を打ち出した。
運用チームは既存のマルチ AZ 構成を維持したまま、アプリケーション改修やスケールアウトの工数を最小化することを条件としている。
また、将来的なアクセス急増に備え、ストレージ性能と接続数が自動的に拡張できる仕組みを残す必要がある。
ビジネス上の狙いは「購入フローの継続性確保」と「障害時の顧客体験維持」であり、技術的には「フェイルオーバー判定の高速化」「接続プールの維持」「書き込み遅延の低減」が必須要件と整理された。
ソリューションアーキテクトは、インフラ設計の観点からどの構成／アプローチを採用すべきか。
停止時間を 20 秒未満に短縮し、前述の制約をすべて満たすために取るべき手順を3つ選択せよ。

【SAP-254】オンライン動画配信プラットフォームを運営するある企業では、ユーザーに低遅延でコンテンツを届けるため AWS 上にマイクロサービス基盤を構築している。
セキュリティ監査の結果、VPC やルートテーブルなどネットワーク設定を専門チームが一元管理し、他部門の開発アカウントはネットワークを変更できないよう統制を強める方針が示された。
ただし各開発チームは自アカウントで Auto Scaling グループや RDS を素早く立ち上げる必要があり、既存サブネットへ自由にデプロイできなければ事業拡大に対応できない。
現在、同社は AWS Organizations を利用して複数アカウントを統制しており、専用のインフラストラクチャアカウントには単一の VPC が作成されている。
ソリューションアーキテクトは、 ①ネットワークの設定権限をインフラチームのみに限定しつつ、②他アカウントの開発者が当該 VPC 内のサブネットへリソースを作成できる、という要件を満たすネットワーク共有方式を選定する必要がある。
インフラ／設計レベルでどのアプローチを採用すべきか、最も適切な方針を二つ選べ。

【SAP-255】あるデジタルマーケティング企業は、広告配信ログを収集し顧客にリアルタイム分析ダッシュボードを提供している。
複数アベイラビリティゾーンに分散した数百台規模の Linux Amazon EC2 解析クラスタを新たに構築し、アクセス急増時にはオートスケールでノードを増減させる運用を計画している。
ビジネス上は 24 時間無停止で高速集計を行う必要があり、全ノードが単一の共有ファイルシステムへ同時に読み書きできることが前提だ。
技術的には、①リージョン内でのマルチ AZ 冗長化による高可用性、②POSIX 互換 I/O、③数十 GB/秒クラスの高スループットという条件を満たす必要がある。
さらにインフラ側に追加ソフトウェアや複雑な運用を持ち込まず、マネージドサービスで管理負荷を抑えたいという制約もある。
ソリューションアーキテクトはこれらの要件を満たすストレージ基盤を選定する必要があるが、採用すべきサービスはどれか？

【SAP-256】あるITベンチャーは世界向け動画配信サービスを運営しており、EC2 上のアプリケーションが各種 AWS サービスへアクセスしてコンテンツメタデータやユーザ情報を処理している。
現状、アクセスキーとシークレットアクセスキーを各インスタンスにハードコードし、データベース認証情報もローカルに保存している一方、リモート保守用の SSH キーだけは暗号化済みの Amazon S3 バケットに格納している。
グローバル展開に伴う外部監査とセキュリティ認証取得の要件から、機密情報を分散配置したままではリスクが高いと判断している。
さらにインスタンスはオートスケールで日々急増減するため、手動でキーを配布・更新する運用は現実的でない。
ビジネス上は、漏えいリスクを最小化しつつ開発スピードと監査証跡を両立させることが急務となっている。
ソリューションアーキテクトは、インフラ設計レベルでどの構成と手順を採用すべきか、運用効率の観点で最善となる組み合わせを三つ選択せよ。

【SAP-257】あるEC事業者は、ECサイトと受注APIをAmazon EC2 Auto Scaling グループ上で提供し、常時数千件/秒のリクエストを処理している。
CI/CD には AWS CodePipeline を用い、インフラとアプリケーションは単一の AWS CloudFormation テンプレートで宣言的に管理している。
コードとビルド済み成果物は Amazon S3 に置き、インスタンスのユーザーデータスクリプトで展開しているが、最近の機能追加に伴うテンプレート修正でリソースが置き換わり、数分間のサイト停止が発生し売上に影響した。
経営層は「デプロイ速度を維持しつつ停止リスクを可視化し、重大変更は人の目で承認する」という新方針を提示している。
現行運用では本番スタックは一つだけで、検証・本番の２段階パイプラインしかなく、スタック更新結果の事前確認ができていない。
開発チームは可用性を損なわずに Auto Scaling の既存構成を活かしつつ、更新内容を自動的に比較・提示し、必要に応じて手動承認を挟める仕組みが必要と考えている。
ソリューションアーキテクトは本番インフラの構造を変えずに CI/CD パイプラインを改良する際、どのアプローチを採用すべきか？

【SAP-258】クラウド上で経営分析SaaSを展開するあるITコンサルティング会社は、開発速度向上のためプロジェクトごとにAWSアカウントを分離し、共通基盤用の共有サービスアカウントには社内データセンターと直結する AWS Direct Connect ゲートウェイを集約している。
同社の需要予測チームは、新規プロジェクトアカウントに構築する VPC から企業ネットワークへ低遅延で安全にアクセスし、オンプレミスの基幹データをリアルタイム参照する必要がある。
しかし運用部門は、接続設定を手作業で行うたびに申請とレビューが発生しており、リリースサイクルが遅延していると指摘している。
そこでチームは、VPC スタックを AWS CloudFormation でデプロイする際、事前にテスト済みの AWS Lambda を呼び出し、仮想プライベートゲートウェイと Direct Connect ゲートウェイの関連付けを自動化する方針をとった。
Lambda は AWS STS により共有サービスアカウントの適切な IAM ロールを一時的に引き受ける設計とし、監査要件を満たすためログは統合 CloudWatch Logs に出力する。
マルチアカウント運用の統制を崩さず、ネットワーク接続の自動化とセキュリティを両立させるため、ソリューションアーキテクトはどのステップの組み合わせを採用すべきか。
最適な三つの選択肢はどれか？

【SAP-259】あるEC系スタートアップは、コンテナ化した決済・在庫 API をパブリック IP 付きの複数の Amazon EC2 にデプロイし、同 EC2 上の Apache Kafka で注文イベントを配信している。
受注明細は Amazon RDS for PostgreSQL に格納する。
この仕組みによりユーザーは Web とモバイルアプリからリアルタイムで商品を購入できる。
次期フラグシップ商品の発売に伴いピーク時トラフィックは数倍に跳ね上がる見込みであり、インフラ担当 3 名ではキャパシティ計画とノードのパッチ適用を継続するのが難しいと判断された。
新機能開発へリソースを集中するため、スケールアウトは自動化しつつミドルウェア運用工数を最小化する方針である。
コンプライアンス上、データは単一リージョン内で完結してよいが、高可用性と数秒以内の再試行が必須という技術要件が残る。
ソリューションアーキテクトはインフラレイヤでどのサービスあるいは機能を採用し、どのように構成を変更すべきか？最も適切な選択肢はどれか。

【SAP-260】ある小売 EC 企業は、世界中の顧客に商品検索 API を低遅延で提供するため、Amazon CloudFront、Amazon API Gateway、AWS Lambda から成るサーバレス基盤を運用している。
1 日に複数回の新機能リリースがビジネス拡大の鍵となる一方、運用担当は少人数で、現在の AWS CLI ベースの手動デプロイではリードタイムが長く、障害発生時の影響範囲調査とリカバリにも時間がかかっている。
経営層は「リリースの高速化と自動復旧による顧客体験の維持」を重視しており、開発部門はアプリケーションコードを極力変更せずに実現したいと考えている。
技術要件としては、Lambda の新バージョンを段階的に公開しつつ CloudWatch アラームでエラー率を監視し、しきい値超過時には自動で旧バージョンへロールバックできることが必須だ。
こうした背景と制約を踏まえ、ソリューションアーキテクトはデプロイ作業をインフラストラクチャレベルで自動化するにあたり、どのデプロイ方式と AWS サービスの組み合わせを採用すべきか？