以下に「問題1」をご指定のフォーマットで整理いたしました。
✅ 問題1の整理
📝 問題文(原文)
企業は、 AWS Organizations の組織で数百の AWS アカウントを一元的に管理しています。同社は最近、製品チームが自分のアカウント内に独自の S3 アクセスポイントを作成および管理できるようにしました。S3 アクセスポイントは、インターネット上ではなく、VPC 内でのみアクセス可能です。
この要件を実施するための最も運用効率の高い方法を選択してください。
🔢 選択肢(正解がわからない形式)
- A:
S3 アクセスポイントのリソースポリシーを設定して、s3:AccessPointNetworkOrigin
条件キーが VPC と評価されない限り、s3:CreateAccessPoint
アクションを拒否します。 - B:
組織のルートレベルに SCP を作成し、s3:AccessPointNetworkOrigin
条件キーが VPC と評価されない限り、s3:CreateAccessPoint
アクションを拒否します。 - C:
AWS CloudFormation StackSets を使用して、s3:AccessPointNetworkOrigin
条件キーが VPC と評価される場合にのみs3:CreateAccessPoint
アクションを許可する新しい IAM ポリシーを各 AWS アカウントに作成します。 - D:
S3 バケットポリシーを設定して、s3:AccessPointNetworkOrigin
条件キーが VPC と評価されない限り、s3:CreateAccessPoint
アクションを拒否します。
📌 問題文の要件の概要
項目 | 内容 |
---|---|
管理単位 | AWS Organizations を使った多数のアカウントの一元管理 |
要件 | 製品チームがS3 アクセスポイントを作成可、かつVPC からのみのアクセスを強制 |
評価基準 | 運用効率の高さ(スケーラブルかつ一貫した制御) |
✅ 正解の選択肢と解説
- 正解:B
解説:
- AWS Organizations の SCP(Service Control Policy) を使えば、組織全体にわたって一括でポリシー制御が可能。
s3:AccessPointNetworkOrigin
条件キーを使って、「VPC からのアクセスでない限り拒否」というルールを明示。- 各アカウントに個別設定をせずに済み、最も運用効率が高い方法となる。
例(SCP):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnforceVpcOnlyAccessPoints",
"Effect": "Deny",
"Action": "s3:CreateAccessPoint",
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"s3:AccessPointNetworkOrigin": "vpc"
}
}
}
]
}
❌ 不正解の選択肢の理由
選択肢 | 理由 |
---|---|
A | リソースポリシーは個々のアクセスポイント単位。組織全体で一貫した制御は不可能。 |
C | s3:AccessPointNetworkOrigin は IAM ポリシーでは使えない条件キー。そのため CloudFormation + IAM ポリシーでは要件を満たせない。 |
D | S3 バケットポリシーでは s3:CreateAccessPoint を制御できず、また s3:AccessPointNetworkOrigin はこの文脈で使用できない。 |
🧠 SAP試験で押さえておくべきポイント
トピック | ポイント |
---|---|
Service Control Policy (SCP) | AWS Organizations 全体でポリシーを適用するための手段。IAM やリソースポリシーより広域的で、スケーラブルな制御に適する。 |
条件キーの使い分け | s3:AccessPointNetworkOrigin などの条件キーはSCPでのみ使用可能なものもある。IAM やリソースポリシーでの可否を要確認。 |
アクセス制御戦略 | アカウントが数百単位に及ぶ場合、**一括で制御できる方法(SCPなど)**が望ましい。個別ポリシーの配布は非効率。 |
次の問題も同じ形式で整理可能です。
必要であれば、該当トピックの模擬SCP作成や図解もお手伝いできます。
以下に「問題2」を指定の形式で整理しました。
✅ 問題2の整理
📝 問題文(原文)
ある企業が、オンプレミスのデータセンターを AWS に移行することを計画しています。同社は現在、Linux ベースの VMware VM 上でデータセンターをホストしています。ソリューションアーキテクトは、VM 間のネットワーク依存関係に関する情報を収集する必要があります。この情報は、ホストの IP アドレス、ホスト名、およびネットワーク接続情報を詳細に示す図の形式である必要があります。
これらの要件を満たすソリューションを選択してください。
🔢 選択肢(正解がわからない形式)
- A:
AWS Application Discovery Service を使用します。AWS Migration Hub のホームリージョンを選択します。データ収集のために、オンプレミスサーバーに AWS Application Discovery Agent をインストールします。Migration Hub ネットワーク図を使用するために、Application Discovery Service にアクセス許可を付与します。 - B:
サーバーのデータ収集に AWS Application Discovery Service Agentless Collector を使用します。AWS Migration Hub からネットワーク図を .png 形式でエクスポートします。 - C:
AWS Application Migration Service エージェントをオンプレミスサーバーにインストールし、データ収集を行います。Workload Discovery on AWS で AWS Migration Hub のデータを使用してネットワーク図を生成します。 - D:
AWS Application Migration Service エージェントをオンプレミスサーバーにインストールしてデータを収集します。AWS Migration Hub のデータを .csv 形式で Amazon CloudWatch ダッシュボードにエクスポートし、ネットワーク図を生成します。
📌 問題文の要件の概要
項目 | 内容 |
---|---|
対象環境 | VMware 上で動作する Linux ベースのオンプレミス VM 群 |
要件 | VM 間のネットワーク依存関係(IP/ホスト名/接続)の図形式での可視化 |
評価基準 | AWS 移行前の依存関係把握の正確性と網羅性 |
✅ 正解の選択肢と解説
- 正解:A
解説:
- AWS Application Discovery Service を使用することで、オンプレミス環境の IP、ホスト名、接続情報などを詳細に自動収集できます。
- その中でも Application Discovery Agent(エージェント型) を使用すれば、プロセス、ポート、通信相手などの細かい依存関係情報まで収集可能。
- Migration Hub に統合することで、ネットワーク図として視覚化され、マイグレーション設計に活用できます。
- これらは ホームリージョンを設定してから有効になります。
❌ 不正解の選択肢の理由
選択肢 | 理由 |
---|---|
B | Agentless Collector では OS やネットワーク依存関係の詳細情報は取得不可。また、Migration Hub にPNG形式でネットワーク図をエクスポートする機能は存在しない。 |
C | Application Migration Service は実際の移行に使うツールであり、ネットワーク依存関係の可視化機能はない。また、Workload Discovery on AWS を使っても代替にはならない。 |
D | CloudWatch ダッシュボードはモニタリングツールであり、ネットワーク図の作成には使えない。Migration Hub のデータを .csv 出力してもネットワーク図にはならない。 |
🧠 SAP試験で押さえておくべきポイント
トピック | ポイント |
---|---|
Application Discovery Service | 移行前に 依存関係マッピングを行うための主要サービス。**Agent(エージェント型)とAgentless(エージェントレス)**があるが、詳細なネットワーク情報が必要なら Agent 一択。 |
Migration Hub | 移行プロジェクト全体の可視化・進行管理に使用。ネットワーク図などの可視化やアプリケーション単位での管理が可能。 |
ホームリージョンの設定 | Migration Hub の機能を使用する前にホームリージョンを明示的に設定する必要あり。 |
次の問題も必要であれば、同様のフォーマットで整理いたします。お気軽にどうぞ!
ありがとうございます。以下、問題3を指定のフォーマットで整理します。
📝 問題文(原文)
ある企業は、オンプレミスで画像データを分析して保存するアプリケーションがあります。このアプリケーションは、毎日数百万の新しい画像ファイルを受信します。ファイルのサイズは平均 1 MB です。ファイルは 1 GB のバッチで分析されます。バッチを分析する際、アプリケーションは画像をまとめて zip に圧縮します。次に、アプリケーションは画像を 1 つのファイルとしてオンプレミスの NFS サーバーにアーカイブし、長期保存します。
同社は、オンプレミスに Microsoft Hyper-V 環境を持ち、コンピューティング能力は利用できます。同社は、ストレージ能力がないため、画像を AWS にアーカイブしたいと考えています。同社は、リクエストから 1 週間以内にアーカイブされたデータを取得できる必要があります。
同社は、オンプレミスのデータセンターと AWS の間に 10 Gbps の AWS Direct Connect 接続があります。同社は、帯域幅制限を設定し、アーカイブされた画像が営業時間外に AWS にコピーされるようにスケジュールを設定する必要があります。
これらの要件を最もコスト効率よく満たすソリューションを選択してください。
🔢 選択肢(原文のまま)※順不同・正誤の明示なし
- AWS DataSync エージェントを新しい GPU ベースの Amazon EC2 インスタンスにデプロイします。DataSync エージェントを設定して、NFS オンプレミスサーバーから Amazon S3 Glacier Instant Retrieval にファイルのバッチをコピーします。コピーが成功したら、オンプレミスのストレージからデータを削除します。
- AWS DataSync エージェントをオンプレミスの Hyper-V VM としてデプロイします。DataSync エージェントを設定して、オンプレミスの NFS サーバーから Amazon S3 Glacier Deep Archive にバッチファイルをコピーします。コピーが成功したら、オンプレミスのストレージからデータを削除します。
- AWS DataSync エージェントを新しい汎用 Amazon EC2 インスタンスにデプロイします。DataSync エージェントを設定して、NFS オンプレミスサーバーから Amazon S3 標準 にファイルのバッチをコピーします。コピーが成功したら、オンプレミスのストレージからデータを削除します。1 日後にオブジェクトを S3 Standard から S3 Glacier Deep Archive に移行する S3 ライフサイクルルールを作成します。
- AWS Storage Gateway テープゲートウェイをオンプレミスの Hyper-V 環境にデプロイします。テープゲートウェイを AWS に接続します。自動テープ作成を使用します。Amazon S3 Glacier Deep Archive プールを指定します。イメージのバッチがコピーされたらテープを取り出します。
📌 問題文の要件の概要
- データ量:毎日数百万枚(合計数GB~数TB)の画像
- バッチ単位:1 GB 単位で分析・圧縮
- ストレージがないため AWS にアーカイブしたい
- データ取得要件:リクエストから1週間以内
- 帯域制限とスケジュール制御必要(営業時間外に転送)
- オンプレに Hyper-V 環境あり
- Direct Connect(10 Gbps)利用可能
✅ 正解の選択肢と解説
選択肢(該当の選択肢)
AWS DataSync エージェントをオンプレミスの Hyper-V VM としてデプロイします。DataSync エージェントを設定して、オンプレミスの NFS サーバーから Amazon S3 Glacier Deep Archive にバッチファイルをコピーします。コピーが成功したら、オンプレミスのストレージからデータを削除します。
解説:
- DataSync は NFS サーバーと連携して効率的に転送でき、帯域幅制限やスケジュール実行にも対応。
- Hyper-V 環境での DataSync エージェントのデプロイもサポート済。
- S3 Glacier Deep Archive は最安ストレージで「取得が1週間以内に可能」という要件に合致。
- 最初から Deep Archive に保存することでライフサイクル管理も不要でシンプルかつコスト効率が高い。
❌ 不正解の選択肢と理由
選択肢 | 不正解理由 |
---|---|
GPUベースのEC2+Glacier Instant Retrieval | EC2 インスタンス(GPU)は不要でコスト高。Instant Retrieval は即時取得用でコストが高い。1週間以内なら Deep Archive で十分 |
EC2+S3 Standard+ライフサイクル | S3 Standard は高コスト。1日後に移行するライフサイクルも運用が複雑。最初から Deep Archive に送る方がコスト効率が良い |
Storage Gateway テープゲートウェイ | 仮想テープライブラリ向けで、画像バッチ処理や NFS との相性が悪い。運用も複雑になりがちで不適 |
🎯 SAP試験で押さえるべきポイント
- DataSync は NFS/SMB から AWS へのデータ転送に最適。帯域制御・スケジュール設定が可能
- S3 Glacier Deep Archive は最安で長期保存に向くが、最大取り出し時間は12時間以内(≒1週間以内の要件に対応)
- **Storage Gateway(テープゲートウェイ)**はバックアップ系(VTL用途)で、画像バッチ処理用途には不向き
- Hyper-V でも DataSync エージェントを直接動かせる
- ライフサイクルポリシーより最初から目的のストレージクラスに保存する方が安価・効率的
次の問題の整理も必要であれば、そのまま貼り付けてください。
以下にご指定の形式で整理しました。
■ 問題文
ある企業が、大量の IoT デバイスからデータを収集しています。データは、Amazon S3 データレイクに保存されています。データサイエンティストは、別の AWS アカウントの VPC にある 2 つのパブリックサブネットで実行されている Amazon EC2 インスタンスで分析を実行します。
データサイエンティストは、EC2 インスタンスからデータレイクにアクセスする必要があります。EC2 インスタンスには、Amazon S3 へのアクセス権限を持つロールがすでに割り当てられています。
会社のポリシーによれば、許可されたネットワークだけが IoT データにアクセスできます。
これらの要件を満たすために、実行する必要がある手順の組み合わせを選択してください。(2 つ選択)
■ 選択肢(順番通り・正解が分からないように表示)
- A. データサイエンティストの VPC に Amazon S3 のゲートウェイ VPC エンドポイントを作成します。
- B. データサイエンティストの AWS アカウントに、データレイク用の S3 アクセスポイントを作成します。
- C. EC2 インスタンスのロールを更新します。s3:DataAccessPointArn 条件キーの値が有効なアクセスポイント ARN である場合に、s3:GetObject アクションを許可する条件付きポリシーを追加します。
- D. VPC のルートテーブルを更新して、S3 トラフィックを S3 アクセスポイントにルーティングします。
- E. s3:DataAccessPointArn 条件キーの値が有効なアクセスポイント ARN である場合に、s3:GetObject アクションを許可する条件を含む S3 バケットポリシーを追加します。
■ 問題文の要件の概要
- データサイエンティストが別アカウントの S3 データレイクにアクセスする必要がある
- アクセス元は特定のネットワークのみ許可する必要がある(セキュリティポリシー)
- すでに EC2 インスタンスの IAM ロールには S3 アクセス権限がある
■ 正解の選択肢と解説
正解:B と E
- B:S3 アクセスポイントをデータサイエンティストのアカウント内に作成することで、VPC アクセスモードを有効化でき、指定された VPC からのみデータレイクにアクセス可能にすることができる。
- E:S3 バケットポリシーに
s3:DataAccessPointArn
条件を設定することで、指定されたアクセスポイント経由からのアクセスのみに制限できる。これにより、VPC を通じた特定経路のみのアクセスが実現できる。
■ 不正解の選択肢の理由
- A:ゲートウェイ VPC エンドポイントは VPC 内の通信をプライベートに保つ手段だが、S3 アクセスポイントに関連する
s3:DataAccessPointArn
条件を適用できないため、要件を満たせない。 - C:IAM ロールに条件を付けても、S3 側(バケットポリシー)で制限していないとアクセス制御が不完全。バケット側の制御が優先されるため、これだけでは要件を満たせない。
- D:VPC のルートテーブルは CIDR ベースであり、S3 アクセスポイントのような論理リソースを直接ルーティング先に設定できない。無効な構成。
■ SAP試験で押さえておくべきポイント
- S3 アクセスポイントは、クロスアカウントアクセス制御やネットワーク制限の要件に強力な機能。
s3:DataAccessPointArn
条件は、特定のアクセスポイント経由でのアクセスを許可するためにバケットポリシーで使用される。- IAM ポリシーとバケットポリシーの優先順位:アクセス制御の主導権はリソースポリシー(バケットポリシー)にあることを理解する。
- ネットワーク制御(VPCからのみアクセス可)とアクセス権限(IAMやバケットポリシー)はセットで考えることが重要。
次の問題があれば、続けてお送りください。
以下に、問題5についてご指定の形式に従って整理しました。
■ 問題文
ある企業は、単一の AWS リージョンで実行される重要なアプリケーションの災害対策を実装する必要があります。アプリケーションのユーザーは、Application Load Balancer (ALB) の背後にある Amazon EC2 インスタンスでホストされているウェブフロントエンドとやり取りします。アプリケーションは、Amazon RDS for MySQL DB インスタンスに書き込みます。アプリケーションはまた、Amazon S3 バケットに保存される処理済みドキュメントを出力します。
同社の財務チームは、レポートを実行するために直接データベースにクエリを行います。繁忙期には、これらのクエリがリソースを消費し、アプリケーションのパフォーマンスに悪影響を及ぼします。
ソリューションアーキテクトは、災害時に回復力を提供するソリューションを設計する必要があります。ソリューションは、データ損失を最小限に抑え、財務チームのクエリによって生じるパフォーマンスの問題を解決する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢(順番を維持・正解がわからないように表示)
- A. データベースを Amazon DynamoDB に移行し、DynamoDB グローバルテーブルを使用します。財務チームに、別のリージョンでグローバルテーブルをクエリするように指示します。AWS Lambda 関数を作成して、元の S3 バケットの内容を別のリージョンにある新しい S3 バケットに定期的に同期します。EC2 インスタンスを起動し、別リージョンに ALB を作成します。新しい S3 バケットを指すようにアプリケーションを構成します。
- B. 別のリージョンに、アプリケーションをホストする EC2 インスタンスを追加で起動します。追加インスタンスを既存の ALB に追加し、別のリージョンで RDS DB インスタンスのリードレプリカを作成します。財務チームに、リードレプリカに対してクエリを実行するよう指示します。元の S3 バケットから別のリージョンの新しい S3 バケットに S3 クロスリージョンレプリケーション (CRR) を使用します。災害発生時には、リードレプリカをスタンドアロン DB インスタンスに昇格します。新しい S3 バケットと新しく昇格したリードレプリカを指すようにアプリケーションを構成します。
- C. 別のリージョンで RDS DB インスタンスのリードレプリカを作成します。財務チームに、リードレプリカに対してクエリを実行するように指示します。アプリケーションフロントエンドをホストする EC2 インスタンスの AMI を作成します。AMI を別のリージョンにコピーします。元の S3 バケットから別のリージョンの新しい S3 バケットに S3 クロスリージョンレプリケーション (CRR) を使用します。災害発生時には、リードレプリカをスタンドアロン DB インスタンスに昇格します。AMI から EC2 インスタンスを起動し、エンドユーザーにアプリケーションを提供するための ALB を作成します。新しい S3 バケットを指すようにアプリケーションを構成します。
- D. RDS DB インスタンスのスナップショットを 1 時間ごとに作成します。スナップショットを別のリージョンにコピーします。既存の RDS データベースの前に Amazon ElastiCache クラスターを追加します。アプリケーションフロントエンドをホストする EC2 インスタンスの AMI を作成します。AMI を別のリージョンにコピーします。元の S3 バケットから別のリージョンの新しい S3 バケットに S3 クロスリージョンレプリケーション (CRR) を使用します。災害発生時には、最新の RDS スナップショットからデータベースを復元します。AMI から EC2 インスタンスを起動し、エンドユーザーにアプリケーションを提供するための ALB を作成します。新しい S3 バケットを指すようにアプリケーションを構成します。
■ 問題文の要件の概要
- 単一リージョン構成に災害対策(DR: Disaster Recovery)を加えたい
- データ損失は最小限にしたい(RPOの低減)
- 財務チームのクエリ負荷による性能低下を防ぎたい(RDSへの読み取り負荷を分離)
■ 正解の選択肢と解説
正解:C
- RDS リードレプリカ(クロスリージョン):別リージョンでリードレプリカを作成すれば、災害時の回復先としても、読み取り専用負荷分散先としても使える。
- 財務チームの読み取りクエリはリードレプリカに向ける:アプリケーション本体のパフォーマンスを守ることができる。
- AMI コピー + ALB 作成:フロントエンドも別リージョンに迅速に展開できる準備。
- S3 CRR(クロスリージョンレプリケーション):S3 バケットも多リージョン化してデータ保護。
■ 不正解の選択肢の理由
- A:RDS を DynamoDB に移行するにはデータモデルの変更が必要で、非現実的かつコスト・移行リスクが高い。
- B:Application Load Balancer(ALB)はリージョンをまたいでインスタンスを追加できないため、技術的に誤り。
- D:スナップショットからの復元には時間がかかり、迅速な災害復旧に不向き。また、ElastiCache は読み取りクエリ全体に有効とは限らず、万能な解決策ではない。
■ SAP試験で押さえておくべきポイント
- RDS クロスリージョンリードレプリカは、災害復旧と読み取りスケーリングの両方を実現可能
- ALB はリージョンローカルリソースであり、別リージョンの EC2 を追加は不可
- DynamoDB への移行は、RDS とは根本的に異なるデータモデルであることを理解する
- **S3 クロスリージョンレプリケーション(CRR)**の利用でリージョン障害への備えを行う
次の問題も引き続き対応可能ですので、必要であればご送信ください。
以下に、問題6を指定フォーマットに沿って整理しました。
■ 問題文
ある企業は、機械学習の学習アルゴリズム用のトレーニングドキュメントを取得するために、ターゲット URL のリストに対してウェブクローリングプロセスを実行しています。Amazon EC2 t2.micro インスタンスのフリートは、Amazon Simple Queue Service (Amazon SQS) キューからターゲット URL を取得します。次に、インスタンスは、クロールアルゴリズムの結果を .csv ファイルとして Amazon Elastic File System (Amazon EFS) ボリュームに書き込みます。EFS ボリュームは、フリートのすべてのインスタンスにマウントされています。
別のシステムが URL を SQS キューに不定期に追加します。インスタンスは、各 URL を 10 秒以内にクロールします。
SQS キューに URL がない場合、一部のインスタンスがアイドル状態であることがメトリクスで示されています。ソリューションアーキテクトは、コストを最適化するためにアーキテクチャを再設計する必要があります。
これらの要件を最もコスト効率よく満たす手順の組み合わせを選択してください。(2 つ選択)
■ 選択肢(順番通り・正解は伏せています)
- A. ウェブクローリングプロセスに、t2.micro インスタンスの代わりに m5.8xlarge インスタンスを使用します。フリート内のインスタンス数を 50 % 削減します。
- B. ウェブクローリングプロセスを AWS Lambda 関数に変換します。SQS キューから URL をプルするように Lambda 関数を設定します。
- C. Amazon Neptune に結果を保存するように、ウェブクローリングプロセスを修正します。
- D. Amazon Aurora Serverless MySQL インスタンスに結果を保存するように、ウェブクローリングプロセスを修正します。
- E. Amazon S3 に結果を保存するように、ウェブクローリングプロセスを修正します。
■ 問題文の要件の概要
- EC2 インスタンスのアイドル時間が発生しており、コスト最適化が必要。
- URLはSQS経由で不定期に到着。
- クローリング結果は
.csv
ファイル形式で保存。 - 10秒以内で処理できる軽量なバッチ処理。
■ 正解の選択肢と解説
正解:B, E
- B. Lambda を使用して SQS からトリガー実行する構成に変更
→ Lambda + SQS によってアイドル時間ゼロ・リクエストベースの課金が可能。イベントドリブンな処理に最適。
→ Lambda は短時間(10秒程度)の処理に向いており、スケーリングも自動。 - E. 結果保存先を EFS から S3 に変更
→ S3 は高い耐久性・低コスト・スケーラビリティを提供。.csv
ファイルの保存に最適。
→ EFS は常時マウント・高コストであり、サーバーレスには不要。
■ 不正解の選択肢の理由
- A. m5.8xlarge でフリート数削減
→ 単価が高いため t2.micro 複数よりコスト増。スパイク対応に非効率。 - C. Amazon Neptune に保存
→ Neptune はグラフDBであり、.csv
保存やクローリング結果とは無関係。 - D. Aurora Serverless に保存
→ DB に保存する必要がなく、構造化された.csv
の用途にも不適切。無駄なコスト増。
■ SAP試験で押さえておくべきポイント
- SQS + Lambda:イベントドリブン・非同期処理でアイドル時間をゼロにしコスト最適化
- EFS vs S3:継続的接続・共有が必要ならEFS、静的ファイル保存ならS3
- LambdaのSQSイベントソースマッピング:標準/FIFO対応、バッチサイズ設定可能
- AuroraやNeptuneの用途とコスト:ファイル保存目的には不適。用途に応じた適材適所が重要
次の問題も準備できましたら送信してください。順に整理していきます。
以下に、指定の形式に従って問題7を整理・解説します。
■ 問題文(原文のまま)
あるスタートアップ企業が最近、大規模な e コマースサイトを AWS に移行しました。このウェブサイトの売上は 70 % 増加しました。ソフトウェアエンジニアは、GitHub のプライベートリポジトリを使用してコードを管理しています。DevOps チームは、ビルドと単体テストに Jenkins を使用しています。エンジニアは、ビルド不良の通知を受け取り、デプロイ中のダウンタイムをゼロにする必要があります。エンジニアはまた、本番環境への変更がユーザーにとってシームレスであり、重大な問題が発生した場合にロールバックできるようにする必要があります。
ソフトウェアエンジニアは、ビルドとデプロイのプロセスを管理するために AWS CodePipeline を使用することに決定しました。
これらの要件を満たすソリューションを選択してください。
■ 選択肢(順番通り・正解が分からないように)
A.
GitHub Websocket を使用して CodePipeline パイプラインをトリガーします。AWS CodeBuild の Jenkins プラグインを使用して単体テストを実行します。ビルド不良がある場合は、Amazon SNS トピックにアラートを送信します。AWS CodeDeploy を使用して、インプレースの all-at-once デプロイ構成でデプロイします。
B.
GitHub Webhook を使用して CodePipeline パイプラインをトリガーします。AWS CodeBuild の Jenkins プラグインを使用して単体テストを実行します。ビルド不良がある場合は、Amazon SNS トピックにアラートを送信します。AWS CodeDeploy を使用してブルー / グリーンのデプロイを行います。
C.
GitHub Websocket を使用して CodePipeline パイプラインをトリガーします。単体テストと静的コード解析に AWS X-Ray を使用します。ビルド不良がある場合は、Amazon SNS トピックにアラートを送信します。AWS CodeDeploy を使用してブルー / グリーンのデプロイを行います。
D.
GitHub Webhook を使用して CodePipeline パイプラインをトリガーします。単体テストと静的コード解析に AWS X-Ray を使用します。ビルド不良がある場合は、Amazon SNS トピックにアラートを送信します。AWS CodeDeploy を使用して、インプレースの all-at-once デプロイ構成でデプロイします。
■ 問題文の要件の概要
- DevOps チームは Jenkins を使用中
- 本番環境にゼロダウンタイムでのデプロイが求められる
- 問題発生時にはロールバックが可能であること
- ビルド不良時にアラートを送信したい
- GitHub と連携してパイプラインを自動実行したい
■ 正解の選択肢と解説
正解:
B. GitHub Webhook + CodePipeline + CodeBuild + SNS + CodeDeploy(ブルー/グリーン)
解説:
- GitHub Webhook:変更をトリガーにして自動で CodePipeline を実行
- CodeBuild(Jenkinsプラグイン):Jenkins と統合して単体テスト実行
- SNS:失敗時に通知
- CodeDeploy(ブルー/グリーン):ゼロダウンタイム + ロールバック対応
■ 不正解の選択肢の理由
A.
Websocket
は AWS との連携には使用しないインプレースの all-at-once
デプロイではゼロダウンタイムが実現できない
C.
AWS X-Ray
はトレーシング用であり、単体テストや静的解析の用途には不適切
D.
AWS X-Ray
の誤用途に加え、インプレースの all-at-once
でゼロダウンタイム不可
■ SAP試験で押さえておくべきポイント
- CodeDeploy のデプロイ方式の違い:
- インプレース:既存環境上書き、ダウンタイム発生リスクあり
- ブルー/グリーン:新環境でテスト後、トラフィック切替。ロールバック容易・ゼロダウンタイム
- Webhook vs Websocket:GitHub 連携では Webhook 使用(HTTP 通知)
- X-Ray の用途:パフォーマンスボトルネックや依存関係の可視化用。ビルド用途では使わない
- CI/CD パイプライン設計では、要件(可用性・通知・連携)に合った AWS サービス構成を選ぶことが重要
次の問題もあればどうぞ。丁寧に整理・解説いたします。