Uncategorized

#44

 

■問題文（そのまま）

ある会社で、Amazon EC2 インスタンスを Auto Scaling グループで使用するアプリケーションがあります。品質保証 (QA) 部門は、アプリケーションをテストするために、短期間の環境を多数起動する必要があります。

アプリケーション環境は、現在、AWS CloudFormation テンプレートを使用して、部門のマネージャーによって起動されています。スタックを起動するために、マネージャーは CloudFormation、EC2、および Auto Scaling API を使用する権限を持つロールを使用します。

マネージャーは、テスターが自分の環境を起動できるようにすることを望んでいますが、各ユーザーに幅広いアクセス許可を付与することは望んでいません。これらの目標を達成する方法を選択してください。

■選択肢（そのまま）

A. AWS CloudFormation テンプレートを Amazon S3 にアップロードします。QA 部門のユーザーに、マネージャーのロールを引き受ける権限を与え、テンプレートとそれが作成するリソースへの権限を制限するポリシーを追加します。CloudFormation コンソールからテンプレートを起動するようにユーザーを訓練します。

B. 環境テンプレートから AWS Service Catalog 製品を作成します。既存のロールで製品に起動制約を追加します。QA 部門のユーザーに AWS Service Catalog API のみを使用する許可を与えます。AWS Service Catalog コンソールからテンプレートを起動するようにユーザーを訓練します。

C. AWS CloudFormation テンプレートを Amazon S3 にアップロードします。QA 部門のユーザーに CloudFormation と S3 の API を使用するためのアクセス許可を付与え、その許可をテンプレートとそれが作成するリソースに制限する条件を付与します。CloudFormation コンソールからテンプレートを起動するようにユーザーを訓練します。

D. 環境テンプレートから AWS Elastic Beanstalk アプリケーションを作成します。QA 部門のユーザーに、ElasticBeanstalk のアクセス許可のみを使用するアクセス許可を付与します。Elastic Beanstalk CLI で、既存のロールをサービスロールとして環境に渡し、Elastic Beanstalk 環境を起動するようにユーザーを訓練します。

■問題文の要件の概要

  • QA部門が短期間で大量のテスト環境を自分で起動できるようにしたい
  • 既存はCloudFormationテンプレートをマネージャーが実行
  • 各ユーザーに広範な権限は付与したくない（最小権限の原則）
  • セルフサービス環境の提供と権限制御が両立する仕組みが必要

■正解の選択肢と解説

正解：B

  • AWS Service Catalog を利用し、CloudFormationテンプレートを製品として登録
  • 起動制約（Launch Constraint） により、既存のマネージャーロールを製品起動時に使用させる
  • QAユーザーには Service Catalog API権限のみ を付与し、CloudFormationやEC2の直接操作権限は不要
  • この構成により、承認済みテンプレートだけを安全に起動でき、最小権限かつセルフサービスが実現

■不正解の選択肢の理由

  • A
    • AssumeRoleでマネージャーロールを渡すと、EC2やAuto Scalingの広範な権限がそのまま移譲され、誤操作やリソース増大リスクが残る
  • C
    • CloudFormationやS3権限に条件を付けても、テンプレート内で呼び出すEC2やAuto Scaling APIの直接制御は難しく、最小権限を担保しにくい
  • D
    • Elastic Beanstalkは現行構成（Auto Scaling＋EC2ベース）と整合せず、サービス設計や操作方法の変更を伴い、運用・学習コストが増す

■SAP試験で押さえておくべきポイント

  • 最小権限の原則を守りつつ、承認済みリソースをセルフサービス提供するには AWS Service Catalog が有効
  • Launch Constraint で実行ロールを固定できるため、ユーザーはそのロール経由でのみリソースを作成可能
  • CloudFormationを直接ユーザーに実行させる場合は、テンプレートが利用する下位サービスの権限制御が難しい
  • Service Catalogはポートフォリオ管理、承認フロー、バージョン管理も可能で、大規模組織の運用に向く

この形式で次の問題も整理できますが、このまま残りの問題も同じ構成でまとめていきますか？

■問題文（そのまま）

ある企業が、複数のお客様に対して REST ベースの API で気象データを提供しています。API は Amazon API Gateway によってホストされ、各 API 操作のために異なる AWS Lambda 関数と統合されています。同社は DNS に Amazon Route 53 を使用し、weather.example.com のリソースレコードを作成しています。同社は、API 用のデータを Amazon DynamoDB のテーブルに保存しています。同社は、API が別の AWS リージョンにフェイルオーバーできるようにするソリューションを必要としています。

これらの要件を満たすソリューションを選択してください。

■選択肢（そのまま）

A. 新しいリージョンに新しい一連の Lambda 関数をデプロイします。API Gateway API を更新し、両方のリージョンからの Lambda 関数をターゲットとしてエッジ最適化 API エンドポイントを使用します。DynamoDB テーブルをグローバルテーブルに変換します。

B. 別のリージョンに新しい API Gateway API と Lambda 関数をデプロイします。Route 53 の DNS レコード を 複数値回答レコードに変更します。両方の API Gateway API を回答に追加します。ターゲットのヘルスモニタリングを有効にします。DynamoDB テーブルをグローバルテーブルに変換します。

C. 別のリージョンに新しい API Gateway API と Lambda 関数をデプロイします。Route 53 の DNS レコードをフェイルオーバーレコードに変更します。ターゲットのヘルスモニタリングを有効にします。DynamoDB テーブルをグローバルテーブルに変換します。

D. 新しいリージョンに新しい API Gateway API をデプロイします。Lambda 関数をグローバル関数に変更します。Route 53 の DNS レコード を 複数値回答レコードに変更します。両方の API Gateway API を回答に追加します。ターゲットのヘルスモニタリングを有効にします。DynamoDB テーブルをグローバルテーブルに変換します。

■問題文の要件の概要

  • API Gateway + Lambda + DynamoDB構成のAPIをマルチリージョン冗長化したい
  • Route 53を使ったDNSフェイルオーバーを実現する必要がある
  • データはリージョン間で同期し、フェイルオーバー後も継続利用可能にする必要がある
  • 各AWSサービスのリージョン制約を考慮して構成すること

■正解の選択肢と解説

正解：C

  • マルチリージョンデプロイ
    • プライマリとセカンダリの両リージョンにAPI GatewayとLambda関数を同一構成でデプロイ
  • Route 53フェイルオーバーレコード
    • プライマリ側のヘルスチェックが失敗した場合、自動でセカンダリのエンドポイントに切替
  • DynamoDBグローバルテーブル
    • マルチマスター非同期レプリケーションで両リージョンから読み書き可能
    • フェイルオーバー後もデータ整合性を確保
  • この構成により、API層とデータ層の両方で高可用性・低RTOのフェイルオーバーが可能

■不正解の選択肢の理由

  • A
    • API Gatewayはリージョンごとにデプロイされ、別リージョンのLambdaを直接統合できない
    • エッジ最適化エンドポイントはグローバルではなく単一リージョン依存
  • B
    • 複数値回答レコードは負荷分散用でフェイルオーバー用途に不向き
    • 障害リージョンのエンドポイントが返却される可能性がある
  • D
    • Lambdaには“グローバル関数”という概念はなく、リージョン単位でのデプロイが必要
    • さらに、Bと同じく複数値回答レコードでは明確なフェイルオーバー制御ができない

■SAP試験で押さえておくべきポイント

  • Route 53ルーティングポリシーの違い
    • フェイルオーバー：明確なプライマリ／セカンダリ切替が可能
    • 複数値回答：負荷分散用でフェイルオーバー制御はできない
  • サービスのリージョン制約
    • API Gateway・Lambdaはリージョン単位サービス → 各リージョンに同一構成をデプロイ
    • DynamoDBグローバルテーブルでデータ同期を確保
  • 高可用性設計
    • API層とデータ層の両方で冗長化を行い、RTOを短縮

この形式で残りの問題も整理できます。
このまま続けて処理していきますか？

■問題文（そのまま）

ある企業では、何千もの Amazon EC2 インスタンスからなるワークロードを実行しています。ワークロードは、複数のパブリックサブネットとプライベートサブネットを含む VPC で実行されています。パブリックサブネットには、既存のインターネットゲートウェイへの 0.0.0.0/0 のルートがあります。プライベートサブネットには、既存の NAT ゲートウェイへの 0.0.0.0/0 のルートがあります。ソリューションアーキテクトは、EC2 インスタンス全体を IPv6 を使用するために移行する必要があります。プライベートサブネットにある EC2 インスタンスは、パブリックインターネットからアクセスできないようにする必要があります。

これらの要件を満たすための最適な方法を選択してください。

■選択肢（そのまま）

A. 既存の VPC を更新し、カスタム IPv6 CIDR ブロックを VPC とすべてのサブネットに関連付けます。すべての VPC ルートテーブルを更新し、::/0 のルートをインターネットゲートウェイに追加します。

B. 既存の VPC を更新し、Amazon が提供する IPv6 CIDR ブロックを VPC とすべてのサブネットに関連付けます。すべてのプライベートサブネットの VPC ルートテーブルを更新し、::/0 のルートを NAT ゲートウェイに追加します。

C. 既存の VPC を更新し、Amazon が提供する IPv6 CIDR ブロックを VPC とすべてのサブネットに関連付けます。Egress-Only インターネットゲートウェイを作成します。すべてのプライベートサブネットの VPC ルートテーブルを更新し、::/0 のルートを Egress-Only インターネットゲートウェイに追加します。

D. 既存の VPC を更新し、カスタム IPv6 CIDR ブロックを VPC とすべてのサブネットに関連付けます。新しい NAT ゲートウェイを作成し、IPv6 サポートを有効にします。すべてのプライベートサブネットの VPC ルートテーブルを更新し、::/0 のルートを IPv6 対応の NAT ゲートウェイに追加します。

■問題文の要件の概要

  • EC2 インスタンスを IPv6 化
  • プライベートサブネットの EC2 はインターネットから直接アクセス不可
  • IPv6 環境でアウトバウンド通信のみ許可
  • IPv4 の NAT ゲートウェイに相当する仕組みが IPv6 にも必要

■正解の選択肢と解説

正解：C

  • Amazon 提供 IPv6 CIDR ブロック
    • AWSから割り当てられるため、BYOIPv6のような手続き不要で即時利用可能
  • Egress-Only インターネットゲートウェイ
    • IPv6トラフィック専用のアウトバウンド専用ゲートウェイ
    • インターネットへの送信は許可するが、外部からの新規接続は遮断
    • IPv6でプライベートサブネットを安全にインターネット接続する唯一の方法
  • ルートテーブル設定
    • プライベートサブネットのルートテーブルに ::/0 → Egress-Only IGW を追加

この構成により、IPv6通信が必要なアウトバウンドアクセスは可能になりつつ、外部からの着信はブロックできる。

■不正解の選択肢の理由

  • A
    • インターネットゲートウェイをプライベートサブネットに設定すると、外部から直接アクセス可能となり「非公開」要件を満たせない
    • カスタムIPv6 CIDRは運用負荷増加
  • B
    • NATゲートウェイはIPv4専用であり、IPv6を扱えないため通信不可
  • D
    • NATゲートウェイにはIPv6対応版が存在しない
    • カスタムIPv6 CIDRは不要であり要件外

■SAP試験で押さえておくべきポイント

  • IPv6ではNATゲートウェイの代わりにEgress-Only IGWを使用
  • Egress-Only IGWの特徴
    • IPv6専用
    • アウトバウンドは許可、インバウンドは遮断
    • ステートフルで戻り通信は自動許可
  • Amazon提供IPv6 CIDRブロックのメリット
    • 即時利用可能
    • 複雑なルーティングや申請不要
  • 試験の狙い所
    • 「IPv6＋プライベートサブネット＋非公開アクセス」の組み合わせでは必ずEgress-Only IGWを選ぶ

この出力フォーマット、次回以降の問題にもそのまま適用できます。

■問題文（そのまま）

ある企業が新しい API を AWS にデプロイしています。API は、Amazon API Gateway を使用し、リージョン API エンドポイントと AWS Lambda 関数をホスティングに使用します。API は、外部ベンダーの API からデータを取得し、Amazon DynamoDB グローバルテーブルにデータを保存し、DynamoDB グローバルテーブルからデータを取得します。ベンダーの API の API キーは AWS Secrets Manager に保存され、AWS Key Management Service (AWS KMS) のカスタマーマネージドキーで暗号化されます。同社は独自の API を単一の AWS リージョンにデプロイしました。

ソリューションアーキテクトは、会社の API の API コンポーネントを変更して、コンポーネントがアクティブ / アクティブ構成で複数のリージョンにわたって実行できるようにする必要があります。

操作上のオーバーヘッドを最小限に抑えてこの要件を満たす変更の組み合わせを選択してください。(3 つ選択)

■選択肢（そのまま）

A. API を複数のリージョンにデプロイします。各リージョンの API エンドポイントにトラフィックをルーティングするカスタムドメイン名で Amazon Route 53 を構成します。Route 53 の複数値回答ルーティングポリシーを実装します。

B. 新しい KMS マルチリージョンのカスタマーマネージドキーを作成します。スコープ内の各リージョンに、新しい KMS カスタマーマネージドレプリカキーを作成します。

C. 既存の Secrets Manager のシークレットを他のリージョンにレプリケートします。スコープ内のリージョンのレプリケートされたシークレットごとに、適切な KMS キーを選択します。

D. スコープ内の各リージョンに新しい AWS マネージドキーを作成します。既存のキーをマルチリージョンキーに変換します。他のリージョンでマルチリージョンキーを使用します。

E. スコープ内の各リージョンに新しい Secrets Manager のシークレットを作成します。既存のリージョンのシークレットを、スコープ内の各リージョンの新しいシークレットにコピーします。

F. Lambda 関数のデプロイプロセスを変更して、スコープ内のリージョン全体でデプロイを繰り返します。既存の API の multi-Region オプションを有効にします。各リージョンにデプロイされた Lambda 関数をマルチリージョン API のバックエンドとして選択します。

■問題文の要件の概要

  • API を単一リージョンから複数リージョンの アクティブ/アクティブ構成 に変更する
  • 運用オーバーヘッドを最小化することが条件
  • Secrets Manager のシークレットと KMS 暗号鍵もマルチリージョンで利用可能にする必要がある
  • DNS レベルでのルーティングが必要

■正解の選択肢と解説

正解：A, B, C

  • A: Route 53 の複数値回答ルーティングを使用して、複数リージョンの API Gateway エンドポイントにトラフィックを分散可能。カスタムドメイン名により、クライアントからは単一のエンドポイントに見える。設定だけで構成でき、運用負荷が小さい。
  • B: KMS マルチリージョンカスタマーマネージドキーを作成し、各リージョンにレプリカキーを作ることで、暗号化/復号のキーを統一できる。ローテーションやポリシーの管理も一元化可能。
  • C: Secrets Manager のシークレットを各リージョンにレプリケートし、適切な KMS レプリカキーで暗号化することで、全リージョンの Lambda から低遅延で安全に参照可能になる。

■不正解の選択肢の理由

  • D: AWS マネージドキーはサービス所有で、利用者がレプリカキーを作成したりマルチリージョンキーに変換することは不可。マルチリージョンキー化できるのはカスタマーマネージドキーのみ。
  • E: Secrets Manager には自動レプリケーション機能があり、手動コピーは不要。手動だと更新時に全リージョンで作業が発生し、オーバーヘッド増加。
  • F: API Gateway に「multi-Region オプション」は存在しない。複数リージョンでの API 運用は個別デプロイ＋Route 53 などの外部ルーティングが必要。

■SAP試験で押さえておくべきポイント

  • マルチリージョンAPI構成の基本: 各リージョンに API Gateway をデプロイし、Route 53 で DNS ベースのトラフィック分散を行う
  • KMS マルチリージョンカスタマーマネージドキー: 各リージョン間で同一キーを利用可能にし、暗号化の整合性と運用負荷軽減を実現
  • Secrets Manager シークレットレプリケーション: 自動で複数リージョンに複製でき、低遅延アクセスが可能
  • 試験の狙い所: 「運用負荷を最小限に」というキーワードが出たら、自動レプリケーションやマルチリージョンキーなどの AWS ネイティブ機能を選ぶ

この問題はマルチリージョン設計の全体像を問う典型パターンなので、同種の出題に備えて「DNSルーティング」「マルチリージョンキー」「Secrets Managerレプリケーション」の組み合わせは確実に押さえておく必要があります。

■問題文（そのまま）

企業には、AWS Organizations の組織のメンバーである 50 の AWS アカウントがあります。各アカウントには複数の VPC が含まれます。同社は、AWS Transit Gateway を使用して、各メンバーアカウントの VPC 間の接続を確立したいと考えています。新しいメンバーアカウントが作成されるたびに、同社は新しい VPC と Transit Gateway アタッチメントを作成するプロセスを自動化したいと考えています。

これらの要件を満たす最適な手順の組み合わせを選択してください。 (2 つ選択)

■選択肢（そのまま）

A. 管理アカウントから、AWS Resource Access Manager を使用して、 Transit Gateway をメンバーアカウントと共有します。

B. 管理アカウントから、AWS Organizations の SCP を使用して、Transit Gateway をメンバーアカウントと共有します。

C. 管理アカウントから AWS CloudFormation StackSets を起動し、メンバーアカウントに新しい VPC と VPC Transit Gateway アタッチメントを自動的に作成します。Transit Gateway ID を使用して、アタッチメントを管理アカウントの Transit Gateway に関連付けます。

D. 管理アカウントから AWS CloudFormation StackSets を起動し、メンバーアカウントに新しい VPC と Transit Gateway ピアリングアタッチメントを自動的に作成します。Transit Gateway のサービスにリンクされたロールを使用して、管理アカウントで Transit Gateway とアタッチメントを共有します。

E. 管理アカウントから、AWS Service Catalog を使用して、 Transit Gateway をメンバーアカウントと共有します。

■問題文の要件の概要

  • AWS Organizations配下の50アカウントのVPC間を 中央のTransit Gateway で接続する
  • 新しいアカウント追加時にも 自動でVPCとアタッチメントを作成 する
  • 各アカウントに個別作業をしないよう、運用負荷を最小化 する

■正解の選択肢と解説

正解：A, C

  • A:
    AWS Resource Access Manager (RAM) を利用すると、Transit Gatewayを組織単位で共有可能。新しいアカウントがOrganizationsに追加されても自動で利用権限が付与されるため、共有設定の手間がない。
  • C:
    AWS CloudFormation StackSets を管理アカウントから実行し、メンバーアカウントにVPCとVPCアタッチメントを自動作成可能。テンプレートに管理アカウントのTransit Gateway IDを設定することで、一元的に接続できる。Organizationsと連携すれば、新規アカウントにも自動でデプロイされる。

■不正解の選択肢の理由

  • B: SCPは権限制御ポリシーであり、リソース共有機能はない。Transit Gatewayの共有はできない。
  • D: ピアリングアタッチメントはTransit Gateway同士を接続するためのもので、VPC接続には利用できない。
  • E: Service Catalogは製品テンプレートを配布する仕組みであり、既存Transit Gatewayを直接共有する機能はない。

■SAP試験で押さえておくべきポイント

  • Transit Gatewayの共有はAWS Resource Access Managerで行う（Organizations単位で自動共有が可能）
  • VPCアタッチメントの自動作成はCloudFormation StackSetsとOrganizations連携が有効
  • ピアリングアタッチメントとVPCアタッチメントの用途の違いを明確に区別する
  • SCPやService Catalogはリソース共有用途ではないため、機能の役割を混同しない

この問題は「中央集約型ネットワークをマルチアカウント環境で自動化する設計」の典型例なので、Transit Gateway × RAM × StackSetsの組み合わせは必ず覚えておくべきです。

■問題文（そのまま）

あるソリューションアーキテクトは、厳しいディザスターリカバリ (DR) 要件を持つ政府機関で働いています。すべての Amazon Elastic Block Store (Amazon EBS) スナップショットは、少なくとも 2 つの追加の AWS リージョンに保存する必要があります。また、政府機関は、可能な限り低い運用オーバーヘッドを維持する必要があります。

これらの要件を満たすソリューションを選択してください。

■選択肢（そのまま）

A. AWS Backup を設定して、EBS スナップショットを作成します。Amazon S3 クロスリージョンレプリケーションを設定して、EBS スナップショットを追加のリージョンにコピーします。

B. Amazon Data Lifecycle Manager (Amazon DLM) で、EBS スナップショットを追加のリージョンにコピーするために毎日 1 回実行するようにポリシーを設定します。

C. Amazon EventBridge (Amazon CloudWatch Events) を使用して AWS Lambda 関数をスケジュールし、EBS スナップショットを追加のリージョンにコピーします。

D. AMI を作成し、AMI を追加のリージョンにコピーするために、Amazon EC2 Image Builder を毎日 1 回実行するようにスケジュールします。

■問題文の要件の概要

  • EBS スナップショットを 少なくとも 2 つの追加リージョン に保存
  • 運用オーバーヘッドをできるだけ低く保つ必要あり
  • マネージドかつ自動化されたコピー機能を選定する必要がある

■正解の選択肢と解説

正解：B

  • B: Amazon Data Lifecycle Manager (DLM) は EBS スナップショットの作成・保持・クロスリージョンコピーをポリシーで自動化できる。ポリシーを一度作成すれば、複数の追加リージョンへのコピーを継続的に実行可能。AWS 側で失敗時の再試行や暗号化キーの同期も処理され、運用負荷を最小限に抑えられる。

■不正解の選択肢の理由

  • A: S3 クロスリージョンレプリケーションは S3 オブジェクト用の機能であり、EBS スナップショットのコピーには利用できない。スナップショットは内部的にS3に保存されるが、ユーザーが直接S3操作で複製することは不可。
  • C: EventBridge＋Lambdaでcopy-snapshot APIを呼び出せるが、コピー先管理やリトライ、保持期間管理をコードで実装する必要があり、運用オーバーヘッドが高い。
  • D: AMIコピーはインスタンス起動テンプレートの複製であり、EBSスナップショット単位の厳密なDR要件を満たさない。AMIはスナップショットの直接的な代替ではない。

■SAP試験で押さえておくべきポイント

  • EBSスナップショットのマルチリージョンコピーはDLMが最適。ポリシー設定だけで自動化可能。
  • S3クロスリージョンレプリケーションはEBSには適用不可 — 保存基盤がS3でもユーザーは直接操作できない。
  • カスタム実装（EventBridge＋Lambda）は保守コストが高く非推奨 — マネージドサービス優先。
  • AMIコピーとスナップショットコピーは用途が異なる — 問題文でEBSスナップショットと明記されていればAMIコピーは誤答になりやすい。

この出題は「災害対策（DR）要件 × 運用負荷最小化」というキーワードから、マネージドかつ自動化されたクロスリージョンコピー機能を選べるかどうかがポイントです。

■問題文（そのまま）

ある会社は、1,000 台のオンプレミスサーバーを AWS に移行することを計画しています。サーバーは、会社のデータセンター内の複数の VMware クラスター上で動作しています。移行計画の一環として、同社は CPU の詳細、RAM 使用量、オペレーティングシステム情報、および実行中のプロセスなどのサーバーメトリクスを収集したいと考えています。そして、そのデータをクエリし、分析したいと考えています。

これらの要件を満たすソリューションを選択してください。

■選択肢（そのまま）

A. オンプレミスのホストに AWS Agentless Discovery Connector 仮想アプライアンスをデプロイして構成します。AWS Migration Hub で Data Exploration (データ探索) を構成します。AWS Glue を使用して、データに対して ETL ジョブを実行します。Amazon S3 Select を使用してデータをクエリします。

B. オンプレミスのホストから VM のパフォーマンス情報のみをエクスポートします。必要なデータを AWS Migration Hub に直接インポートします。Migration Hub で不足している情報を更新します。Amazon QuickSight を使用してデータをクエリします。

C. オンプレミスのホストからサーバー情報を自動的に収集するスクリプトを作成します。AWS CLI を使用して put-resourceattributes コマンドを実行し、詳細なサーバーデータを AWS Migration Hub に保存します。Migration Hub のコンソールで直接データをクエリします。

D. AWS Application Discovery Agent を各オンプレミスサーバーにデプロイします。AWS Migration Hub で Data Exploration (データ探索) を構成します。Amazon Athena を使用して、Amazon S3 のデータに対して事前定義されたクエリを実行します。

■問題文の要件の概要

  • オンプレミスの1,000台サーバーの CPU、RAM、OS情報、実行中プロセス を収集
  • データをクエリ・分析可能にする
  • 大規模環境に対応し、自動化・継続的収集・分析基盤 を備える

■正解の選択肢と解説

正解：D

  • D:
    AWS Application Discovery Agent を各サーバーにインストールすると、OSレベルで詳細なメトリクス（CPU詳細、RAM使用量、OS情報、プロセス、ネットワーク接続）を自動収集可能。Migration Hubの Data Exploration 機能を使えば収集データをAmazon S3にエクスポートでき、Amazon AthenaでSQLクエリによる分析が可能。サーバーレスでスケーラブル、運用負荷が低い。

■不正解の選択肢の理由

  • A: Agentless Discovery ConnectorはVMwareの構成情報・依存関係収集のみで、OSレベルの詳細メトリクスは取得不可。S3 Selectは単一オブジェクトへの簡易クエリ機能で、大量データ分析には不向き。
  • B: 手動エクスポート＋インポートは自動化されず、最新状態の継続収集ができない。QuickSightで可視化してもデータの網羅性不足で要件未達。
  • C: スクリプト＋CLI登録は大規模環境では管理が煩雑で保守性低下。Migration Hubコンソール自体は柔軟なクエリエンジンを持たず、直接分析は困難。

■SAP試験で押さえておくべきポイント

  • 詳細なOSレベルのメトリクスが必要ならAWS Application Discovery Agentを使用
  • Agentless Discovery ConnectorはVM構成レベルのみで、OS内部情報は取得不可
  • 大量データ分析はAthenaやRedshift Spectrumなどスケーラブルなクエリエンジンを選択
  • Migration HubのData Exploration機能はS3出力とAthena連携が前提
  • 手動データ収集やCLIベースの一括投入は大規模環境では非効率

この問題は「移行前評価に必要な詳細メトリクスの自動収集」と「スケーラブルな分析基盤」の組み合わせを理解しているかがポイントです。

RELATED POST