第1回 問題集（CI/CD・自動化）

正解: B. 各マイクロサービスごとに個別のCodePipelineを作成し、CodeCommitのトリガーにパスフィルタ（file path filter）を設定して該当ディレクトリの変更時のみ起動する

正解の根拠・詳細解説

CodeCommit（またはCodeStar Connections経由のGitHub等）のトリガーにはパスフィルタ機能があり、特定のディレクトリ配下のファイルが変更された場合のみパイプラインを起動できる。モノレポでマイクロサービスごとに独立したパイプラインを構成し、パスフィルタで起動条件を絞ることで、不要なビルド・デプロイを避けて効率化できる。

正解: B. buildspec.ymlのartifactsセクションでname属性に環境変数CODEBUILD_BUILD_IDやCODEBUILD_RESOLVED_SOURCE_VERSIONを組み込んだ動的なパスを指定する

正解の根拠・詳細解説

buildspec.ymlのartifacts.nameフィールドでは環境変数を使った動的な命名が可能。CODEBUILD_BUILD_ID等を使えばビルドごとに一意のS3パスにアーティファクトを保存でき、過去のビルドを個別に参照・ロールバックに利用できる。S3バージョニングだけでは同一キーへの上書き履歴管理になり、パスでの明示的な世代管理より運用が複雑になる。

正解: B. CloudWatchアラームをデプロイグループに関連付け、アラームがALARM状態になった場合に自動ロールバックをトリガーするよう設定する

正解の根拠・詳細解説

CodeDeployのデプロイグループには、CloudWatchアラームに基づく自動ロールバック機能がある。指定したアラームがALARM状態になると、CodeDeployは自動的に直前の正常なリビジョンにロールバックできる。これによりLambdaでのポーリングなど手動の仕組みを構築せずに、宣言的な自動ロールバックが実現できる。

正解: B. ツールアカウントのCodePipelineサービスロールに対し、各メンバーアカウントでクロスアカウントロールを作成してAssumeRoleを許可し、KMSキーのクロスアカウントポリシーとS3バケットポリシーも更新する

正解の根拠・詳細解説

クロスアカウントのCI/CDパイプラインでは、ツールアカウントのCodePipelineサービスロールがメンバーアカウントのデプロイ用ロールをAssumeRoleできるよう信頼関係を設定し、アーティファクト用S3バケットとKMSキーのポリシーにもメンバーアカウントからのアクセスを許可する必要がある。アクセスキーの共有やルート認証情報の共有はセキュリティベストプラクティスに反する。

正解: A. Lambdaのエイリアスを使い、AWS SAMまたはCodeDeployのAWS Lambdaデプロイ設定（Canary10Percent5Minutesなど）を使用し、CloudWatchアラームを関連付けて自動ロールバックを有効化する

正解の根拠・詳細解説

AWS CodeDeployはLambda関数のデプロイをサポートし、Canary・Linear・All-at-onceなどの事前定義デプロイ設定を提供する。Lambdaエイリアスのトラフィックシフティングと組み合わせ、CloudWatchアラームを関連付けることで、異常検知時の自動ロールバックも実現できる。SAMやCDKを使うとこの設定をコードで管理できる。

正解: B. 外部接続（external connection）をCodeArtifactリポジトリに設定し、npmjs.comをアップストリームリポジトリとして登録する

正解の根拠・詳細解説

CodeArtifactはリポジトリに対して外部接続（external connection）を設定でき、npmjs.comやPyPIなどの公開リポジトリをアップストリームとして登録できる。一度取得したパッケージはCodeArtifact内にキャッシュされ、以降のリクエストはキャッシュから高速に提供されるため、外部障害やネットワーク遅延の影響を軽減できる。

正解: B. パイプラインのデプロイ前ステージで cdk diff を実行し、出力を承認ステップ（manual approval）のレビュー対象として提示する

正解の根拠・詳細解説

cdk diffコマンドは、現在デプロイされているスタックと新しいコードから生成されるテンプレートの差分を表示する。CI/CDパイプラインのデプロイ前ステージでこれを実行し、結果を手動承認ステップの判断材料として提示することで、意図しないリソース変更（特に削除）を本番反映前に検知できる。

正解: B. CodeDeployのデプロイグループでBlue/Green設定の「Wait time before terminating original task set」（元タスクセットの終了待機時間）を適切な値に設定する

正解の根拠・詳細解説

ECS Blue/GreenデプロイをCodeDeployで実施する場合、新タスクセット（Green）へのトラフィック切り替え後、元のタスクセット（Blue）をすぐに終了せず一定時間維持する「Bake time」を設定できる。この待機時間中に問題が発見されれば、迅速にBlueへロールバックできる。

正解: B. CodeCommitのブランチでプッシュを承認ルールテンプレート（approval rule template）とブランチの承認ルールに関連付け、加えてIAMポリシー条件キーでmainブランチへの直接プッシュを拒否する

正解の根拠・詳細解説

CodeCommitは承認ルールテンプレートをリポジトリ・ブランチに関連付けてプルリクエストの最低承認数を強制できる。さらにIAMポリシーの条件キー（codecommit:References等）を使ってmainブランチへの直接プッシュを拒否することで、必ずプルリクエスト経由でのみ変更を反映させる運用を実現できる。

正解: A. 承認ステージにManual Approvalアクションを追加し、SNSトピックを通知先として設定、SNSサブスクリプションでメール通知やChatbot連携でSlack通知を行う

正解の根拠・詳細解説

CodePipelineのManual Approvalアクションには通知先としてSNSトピックを指定できる。SNSサブスクリプションでメールアドレスを登録したり、AWS Chatbotと連携させることでSlackチャンネルへ承認待ちの通知を自動的に送ることができ、承認の見落としを防げる。

正解: B. CodeBuildプロジェクトの環境設定（Environment）で「特権付与（Privileged）」のチェックボックスを有効にする

正解の根拠・詳細解説

CodeBuildでDockerイメージのビルド（Docker in Docker）を行うには、プロジェクトの環境設定で「特権付与（Privileged）」を有効にする必要がある。これによりビルドコンテナ内でDockerデーモンを起動できるようになる。buildspec.yml内の設定ではなく、プロジェクトレベルの環境設定項目である。

正解: B. プラットフォームチームが定義したサービステンプレートを使い、開発チームがセルフサービスでインフラとCI/CDパイプラインを標準化された形でプロビジョニングできる

正解の根拠・詳細解説

AWS Protonは、プラットフォーム（インフラ）チームがサービステンプレートとして環境・パイプライン・インフラ構成を定義し、開発チームがそのテンプレートを使ってセルフサービスでデプロイできるようにするサービスである。組織全体でのインフラとデプロイパターンの標準化に役立つ。

正解: A. CodeStar Connections経由でGitHubと連携し、トリガー設定でイベントタイプを「Pull request merged」やブランチフィルタでmainブランチのみに限定する

正解の根拠・詳細解説

CodePipelineのV2パイプラインタイプでは、CodeStar Connections経由のGitHub連携でトリガー設定が柔軟になり、Push・Pull Request（Open/Updated/Merged等）のイベントタイプとブランチ・ファイルパスフィルタを組み合わせて、起動条件を細かく制御できる。

正解: A. ECRの「プッシュ時のスキャン（Scan on push）」を有効にし、CodeBuildのビルドステップでスキャン結果をAPIで取得し、重大な脆弱性があればビルドを失敗させるロジックを追加する

正解の根拠・詳細解説

Amazon ECRの拡張スキャン（Enhanced scanning、Inspectorとの統合）またはベーシックスキャンを「プッシュ時」に有効化し、CodeBuildのbuildspec内でdescribe-image-scan-findings APIの結果を取得・評価して、重大な脆弱性が検出された場合はビルドを失敗（exit 1）させることで、パイプラインの後続デプロイステージへの進行を防げる。

正解: A. CodePipelineのCloudFormationデプロイアクションを各リージョンに対応するステージとして複数追加し、クロスリージョンアクションのアーティファクトバケットとKMSキーをリージョンごとに設定する

正解の根拠・詳細解説

CodePipelineはクロスリージョンアクションをサポートしており、パイプライン定義内でリージョンごとのアーティファクトストア（S3バケット・KMSキー）を指定した上で、各リージョン向けのCloudFormationデプロイアクションをステージとして追加することで、マルチリージョンデプロイを自動化できる。

正解: A. CodeBuildプロジェクトのキャッシュ機能（ローカルキャッシュまたはS3キャッシュ）を有効にし、依存関係ディレクトリをキャッシュパスとして指定する

正解の根拠・詳細解説

CodeBuildにはキャッシュ機能があり、S3キャッシュまたはローカルキャッシュ（ソースキャッシュ・Dockerレイヤーキャッシュ・カスタムキャッシュ）を使うことで、依存関係ディレクトリなどをビルド間で再利用でき、毎回のダウンロード時間を削減してビルドを高速化できる。

正解: B. Amazon EKS上にArgoCDやFluxなどのGitOpsツールをデプロイし、CodeCommitやGitHub等のリポジトリと同期させる

正解の根拠・詳細解説

GitOpsはKubernetesクラスターの構成をGitリポジトリで宣言的に管理し、ArgoCDやFluxなどのツールがリポジトリの状態とクラスターの実際の状態を継続的に比較・同期する手法である。AWSではEKS上にこれらのOSS GitOpsツールをデプロイして運用するのが一般的なパターンである。

正解: B. Rolling with additional batch、かつヘルスチェックに基づく自動ロールバックを有効化したImmutableまたはBlue/Greenデプロイ

正解の根拠・詳細解説

Elastic Beanstalkでダウンタイムを避けつつ安全にデプロイするには、Immutable（新しいインスタンスセットを別途起動し正常性確認後に切替）やBlue/Greenデプロイ（環境スワップ）が適している。さらに環境のヘルスチェックと連動した自動ロールバック設定を有効にすることで、デプロイ失敗時に直前の状態へ戻すことができる。

正解: A. AWS Signerを使ってコード署名を行い、デプロイ先（Lambda関数やIoTデバイス等）で署名検証を強制する設定を行う

正解の根拠・詳細解説

AWS Signerはコード署名サービスで、Lambda関数やコンテナイメージ、IoTデバイス向けのコードに署名し、デプロイ時に署名検証を強制できる（Lambdaの場合はコード署名設定をデプロイ前検証として関連付け可能）。これにより、ビルド済みアーティファクトが意図したパイプラインで生成され改ざんされていないことを保証するサプライチェーンセキュリティが実現できる。

正解: B. sam local start-api を使ってローカルでAPI Gatewayエンドポイントをエミュレートし、Lambda関数の動作を確認する

正解の根拠・詳細解説

AWS SAM CLIのsam local start-apiコマンドは、ローカルにDockerコンテナを使ってAPI GatewayとLambda関数の統合をエミュレートし、実際にAWSへデプロイする前にAPIエンドポイントの動作をローカルで確認できる。これによりデプロイ前の高速なフィードバックループを実現できる。

正解: B. CloudFormationのMappingsとParametersを活用し、環境名をパラメータとして受け取り、Mappingsで環境別の値を切り替える

正解の根拠・詳細解説

CloudFormationのParametersで環境名（dev/stg/prod等）を受け取り、Mappingsセクションに環境別の設定値（インスタンスタイプ、スケーリング数等）を定義してFn::FindInMapで参照することで、単一テンプレートを複数環境で再利用しつつ環境差分を管理できる。テンプレートの複製は保守性が低く非推奨。

正解: B. Change Set（変更セット）を作成し、内容を確認してから実行する

正解の根拠・詳細解説

CloudFormationの変更セット（Change Set）を作成すると、実際にスタックを更新する前に、どのリソースが追加・変更・削除（置換含む）されるかを事前にプレビューできる。CI/CDパイプラインでは変更セットを作成し、内容を確認（または承認ステップで人間がレビュー）した上で実行するのがベストプラクティスである。

正解: B. CloudFormation StackSetsを使い、Organizationsと統合してターゲットOU配下の全アカウントに自動展開・自動更新する

正解の根拠・詳細解説

CloudFormation StackSetsはAWS Organizationsと統合でき、指定したOU（組織単位）配下の全アカウント・全リージョンに対してスタックを一括展開・自動更新できる。新規アカウントが追加された場合も自動的に同じ設定が適用されるため、マルチアカウント環境でのガバナンス・セキュリティ設定の一貫性確保に最適である。

正解: B. CDKコンストラクトをnpm/PyPIパッケージとして作成し、AWS CodeArtifactにプライベートパッケージとして公開してバージョン管理する

正解の根拠・詳細解説

CDKのコンストラクトは通常のプログラミング言語のパッケージとして作成できるため、npm（TypeScript/JavaScript）やPyPI（Python）形式でパッケージ化し、CodeArtifactのプライベートリポジトリに公開することで、バージョン管理された再利用可能なコンポーネントとして社内の複数チームに配布できる。

正解: A. AWS Systems Manager（SSM Agent経由のRun Command、Patch Manager、State Manager）

正解の根拠・詳細解説

AWS Systems Managerは、EC2インスタンスにインストールされたSSM Agentを通じて、Run Commandによるコマンド実行、Patch Managerによるパッチ適用、State Managerによる構成状態の維持など、フリート全体の構成管理を一元的に行える。Inspectorは脆弱性スキャン、Configは構成変更の記録・評価、Macieはデータ分類・保護のサービスであり目的が異なる。

正解: B. S3バケットをバックエンドとして状態ファイルを保存し、DynamoDBテーブルを使ったステートロック（state locking）を有効にする

正解の根拠・詳細解説

TerraformのS3バックエンドはリモートで状態ファイルを共有保存でき、DynamoDBテーブルを使ったロック機構（dynamodb_table設定）と組み合わせることで、複数人・複数CI/CDジョブからの同時実行時に発生する状態ファイルの競合・破損を防止できる、AWS上でのTerraform運用における標準的なベストプラクティスである。

正解: A. AWS Systems Manager State ManagerとAWS CloudFormation（またはCDK）

正解の根拠・詳細解説

OpsWorksの構成管理（Chef/Puppet）からの移行先としては、インフラのプロビジョニングをCloudFormationやCDKで行い、インスタンスの構成状態の継続的な維持・適用はSystems Manager State Managerで行うのが、AWSネイティブなマネージドアプローチとして適切である。なお、AWS OpsWorksは2024年5月にサービス終了が発表されている点も実務上重要である。

正解: A. Lambda関数内でCloudFormationへのレスポンス送信（SUCCESS/FAILEDのシグナル）を必ず行い、タイムアウトしないよう処理する

正解の根拠・詳細解説

CloudFormationのカスタムリソースを実装するLambda関数は、処理完了後に必ずpre-signed S3 URL（ResponseURL）に対してSUCCESSまたはFAILEDのレスポンスを送信する必要がある。これを怠るとCloudFormationスタックの作成・更新・削除処理がタイムアウトするまでハングしてしまう。AWS CDKのProvider Frameworkやcfn-response moduleを使うと実装が簡素化される。

正解: B. ネストされたスタックを使うか、Exports（Fn::ExportName）とFn::ImportValueを使ってスタック間で値を受け渡す

正解の根拠・詳細解説

CloudFormationでは、出力（Outputs）にExportNameを設定したリソース値を、別スタックからFn::ImportValueで参照できる。これによりスタック間の依存関係がCloudFormation側で追跡され、エクスポートされた値を使用中のスタックがある場合は元のスタックを誤って削除・変更できないよう保護される。あるいはネストされたスタック構成でも値を受け渡せる。

正解: A. クラスターはCloudFormationまたはCDK/Terraformで作成し、Kubernetesリソースの定義はYAMLマニフェストやHelmチャートをGitで管理し、CI/CDパイプラインでkubectlやHelmを実行して適用する

正解の根拠・詳細解説

EKSクラスター自体（コントロールプレーン、ノードグループ等）はCloudFormation/CDK/Terraformなどのインフラ用IaCツールで管理し、クラスター上で動作するKubernetesリソース（Deployment、Service、ConfigMap等）はYAMLマニフェストやHelmチャートとしてGitで管理し、CI/CDパイプライン内でkubectl applyやhelm upgradeを実行して反映するのが一般的なパターンである。

正解: B. 複数のAWS Configルールとリマediationアクションをパッケージ化し、組織全体やアカウント全体に一括展開してコンプライアンス基準を統一的に評価・適用する

正解の根拠・詳細解説

AWS Config Conformance Packは、複数のConfigルール（マネージドルール・カスタムルール）と自動修復アクションをひとつのテンプレートとしてパッケージ化し、単一アカウントや組織全体（Organizations統合）に一括デプロイできる。PCI-DSSやNIST等の業界標準に対応したサンプルパックも提供されており、コンプライアンス基準の統一的な適用に役立つ。

正解: B. パラメータタイプをAWS::SSM::Parameter::Valueとして指定し、Secrets ManagerまたはSSM Parameter Store（SecureString）に保存した値を参照する。RDSの場合はManageMasterUserPassword機能でSecrets Managerに自動生成・管理させることも検討する

正解の根拠・詳細解説

機密情報をCloudFormationテンプレートに直接記述するのは避けるべきであり、SSM Parameter StoreのSecureStringパラメータやSecrets Managerに値を保存し、テンプレート側ではAWS::SSM::Parameter::Value型のパラメータや動的参照（{{resolve:secretsmanager:…}}）で参照するのが安全である。RDSではManageMasterUserPassword機能を使うとSecrets Manager上でのパスワード生成・管理も自動化できる。

正解: A. AWS CloudFormation Guard（cfn-guard）やcfn-lintをCI/CDパイプラインのデプロイ前ステージに組み込み、ポリシー違反があればビルドを失敗させる

正解の根拠・詳細解説

AWS CloudFormation Guard（cfn-guard）はポリシー・コンプライアンスルールをコードとして定義し、CloudFormationテンプレートに対して静的に検証できるオープンソースツールである。cfn-lintは構文・ベストプラクティスのチェックを行う。これらをCI/CDパイプラインのデプロイ前段階に組み込むことで、デプロイ前にルール違反を検出しビルドを失敗させ、問題のあるテンプレートが本番に到達するのを防げる。

正解: B. CDKのデプロイに必要なS3バケット（アセット格納用）、ECRリポジトリ、IAMロールなどの基本的なリソース（CDKToolkitスタック）をAWS環境内に作成する

正解の根拠・詳細解説

cdk bootstrapコマンドは、CDKがデプロイ時に使用するアセット保存用S3バケット、Dockerイメージ用ECRリポジトリ、CloudFormation実行用のIAMロール群などをCDKToolkitという名前のCloudFormationスタックとして対象のアカウント・リージョンに作成する。これらのリソースがないとCDKによるデプロイは実行できない。

正解: A. AWS Config の高度なクエリ（Advanced Query）またはAWS Resource Explorer を使い、アグリゲータ経由で組織全体のリソース構成情報を集約・検索する

正解の根拠・詳細解説

AWS Config Aggregatorを使うと組織内の複数アカウント・複数リージョンの構成情報を集約し、高度なクエリ（SQLライクな構文）でリソースを検索できる。また、AWS Resource Explorerはマルチリージョン・マルチアカウントにわたるリソースの検索を簡素化する専用サービスである。これらにより手動でのアカウント巡回を避け、効率的にリソースを可視化・検索できる。

正解: B. AWS CDKを使ってコンストラクトの階層で論理的にコードを分割し、最終的に1つまたは少数のCloudFormationテンプレートとして合成（synthesize）する、あるいはマイクロサービスごとに独立したスタックに分割しスタック間の参照は最小限にする

正解の根拠・詳細解説

ネストされたスタックの管理が複雑化する場合、CDKを使ってプログラミング言語のモジュール性（クラス、関数）でコードを分割しつつ最終的なテンプレート合成はCDKに任せる方法や、サービス・マイクロサービス単位で独立したスタックに分割し、スタック間の依存（Exports/ImportValueやSSM Parameter経由）を最小限に保つ設計が推奨される。

正解: B. State Managerのアソシエーション（Association）を作成し、対象インスタンス（タグやインスタンスIDで指定）に対してSSMドキュメントを定期的に適用するスケジュールを設定する

正解の根拠・詳細解説

Systems Manager State Managerの「アソシエーション」は、SSMドキュメント（例：AWS-ConfigureAWSPackageやカスタムドキュメント）を対象インスタンスに対して指定したスケジュール（rate式やcron式）で継続的に適用する仕組みである。これにより、インスタンスが起動するたびや定期的に、CloudWatchエージェントのインストールなどの構成状態を強制・維持できる。

正解: B. L2コンストラクトはAWSリソースのベストプラクティスに基づいたデフォルト値や便利なヘルパーメソッドを提供し、L1（CFNリソース）よりも少ないコード量で安全な構成を実現できる

正解の根拠・詳細解説

CDKのコンストラクトはL1（CloudFormationリソースの薄いラッパー、Cfn*クラス）、L2（ベストプラクティスのデフォルト値や便利なメソッドを持つ高レベルコンストラクト）、L3（複数リソースを組み合わせたパターン）の3階層に分かれる。L2コンストラクトを使うことで、暗号化やIAM権限の最小化などのベストプラクティスがデフォルトで適用され、コード量を減らしながら安全な構成を実現できる。

正解: A. terraform planを実行して差分を確認し、必要に応じてterraform refreshやterraform importで状態を同期し、再度applyして意図した構成に戻す

正解の根拠・詳細解説

Terraformでドリフトが疑われる場合、terraform planを実行することで実際のリソース状態とコード・状態ファイルとの差分を確認できる。差分が手動変更によるものであれば、コードを更新してapplyで意図した構成に戻すか、必要に応じてterraform importなどで状態ファイルを実態に合わせて修正する対応を行う。

正解: B. スタックの作成・更新・削除の操作が実行される前に、カスタムの検証ロジック（Lambda関数）を呼び出し、ポリシー違反があれば操作を失敗させたり警告を出したりする（プロアクティブなガードレール）

正解の根拠・詳細解説

CloudFormation Hooksは、スタック操作（CREATE/UPDATE/DELETE）の実行前にカスタムのLambda関数ベースの検証ロジックをフックとして呼び出せる機能である。これにより、組織のポリシーに違反するリソース構成（例：暗号化されていないS3バケットの作成）をデプロイ前にブロックする、プロアクティブなガードレールを実装できる。CloudFormation Guardより柔軟なロジックが必要な場合に有効。

正解: B. Auto Scalingグループを複数AZに跨って構成し、Application Load Balancerでクロスゾーン負荷分散を行い、各AZで十分なキャパシティを確保する

正解の根拠・詳細解説

高可用性を実現するには、Auto Scalingグループを複数のAZに跨って構成し、ALB（クロスゾーン負荷分散が既定で有効）でトラフィックを分散する。各AZで単独でも十分なキャパシティ（N+1構成等）を確保しておくことで、1つのAZで障害が発生してもサービス全体への影響を最小化できる。

正解: B. DynamoDB Global Tablesを使い、複数リージョンにテーブルをレプリケートし、リアルタイムに近い同期を行う

正解の根拠・詳細解説

DynamoDB Global Tablesはマルチリージョンでのアクティブ-アクティブなレプリケーションを実現し、各リージョンへの書き込みが他のリージョンに自動的に（通常1秒未満で）レプリケートされる。これによりRPO（許容できるデータ損失時間）を最小限に抑えたマルチリージョンDR構成が実現できる。オンデマンドバックアップは復旧に時間がかかりRPOが大きくなる。

正解: B. Multi-AZ配置でRDSインスタンスを構成し、読み取り専用のRead Replicaを追加してアプリケーションの読み取りクエリをReplicaに振り分ける

正解の根拠・詳細解説

RDSのMulti-AZ配置はプライマリの同期レプリカを別AZに自動的に維持し、障害時に自動フェイルオーバーする（可用性目的）。これとは別に、読み取り負荷分散のためにはRead Replica（非同期レプリケーション、性能目的）を追加し、読み取り専用クエリをReplicaにルーティングすることで、可用性と読み取りスケーラビリティの両方を実現できる。

正解: B. MFA Delete を有効化し、バージョン削除時にMFA認証を必須にする。さらにS3 Object Lock（コンプライアンスモードまたはガバナンスモード）を使い一定期間の削除・上書きを禁止する

正解の根拠・詳細解説

S3のMFA Deleteを有効にすると、バージョン削除や バージョニングの無効化操作にMFA認証が必須になり、誤削除・不正操作のリスクを下げる。さらにS3 Object Lockを使うとWORM（Write Once Read Many）モデルで指定期間オブジェクトの削除・上書きを禁止でき、ランサムウェア対策やコンプライアンス要件に対応した多層防御が実現できる。

正解: A. ALBはクロスゾーン負荷分散がデフォルトで有効になっており、登録された全ターゲットに対しAZを意識せず均等にトラフィックを分配する

正解の根拠・詳細解説

Application Load Balancer（ALB）はデフォルトでクロスゾーン負荷分散が有効になっており、各AZのターゲット数に関わらず、登録されているすべてのターゲットに対して均等にトラフィックを分配する。一方、Network Load Balancer（NLB）はクロスゾーン負荷分散がデフォルトで無効（オプトインで有効化可能）という違いがある点も実務上重要。

正解: A. 送信元・宛先バケットの両方でバージョニングを有効化する必要がある

正解の根拠・詳細解説

S3のレプリケーション機能（CRRおよびSRR）を設定するには、送信元バケットと宛先バケットの両方でバージョニングを有効にしておく必要がある。これによりオブジェクトの変更履歴を保持しながら、新規作成・更新されたオブジェクトを別リージョン（CRR）または同一リージョンの別バケット（SRR）に自動的にレプリケートできる。

正解: B. デッドレターキュー（DLQ）を設定し、最大受信回数（maxReceiveCount）を超えたメッセージを自動的にDLQへ移動させ、メインキューの処理を継続できるようにする

正解の根拠・詳細解説

SQSのRedrive Policyでデッドレターキュー（DLQ）と最大受信回数を設定すると、指定回数処理に失敗したメッセージは自動的にDLQへ移動し、メインキューでの処理をブロックしなくなる。これにより1つの問題のあるメッセージ（ポイズンメッセージ）が全体の処理を停止させることを防ぎ、DLQ側で個別に調査・再処理できる。

正解: B. Auto Scalingのライフサイクルフック（Lifecycle Hook）を使い、スケールイン前にインスタンスをTerminating:Wait状態にし、処理完了後にCompleteLifecycleActionを呼び出して終了を進める

正解の根拠・詳細解説

Auto Scalingのライフサイクルフックを使うと、スケールイン（終了）時にインスタンスを即座に終了せず、Terminating:Wait状態で一定時間待機させることができる。この間にアプリケーション側で進行中の処理を完了させ、SQSキューのドレインなどのクリーンアップを行った後、CompleteLifecycleActionを呼び出してインスタンスの終了を進めることで、グレースフルシャットダウンを実現できる。

正解: A. Route 53のフェイルオーバールーティングポリシーを使い、ヘルスチェックと組み合わせてプライマリリージョンの異常を検知したら自動的にセカンダリリージョンのエンドポイントへ切り替える

正解の根拠・詳細解説

Route 53のフェイルオーバールーティングポリシーは、ヘルスチェックの結果に基づいてプライマリレコードが異常な場合に自動的にセカンダリレコード（別リージョンのエンドポイント等）へ切り替える。これによりDNSレベルでのリージョン間フェイルオーバーを自動化できる。

正解: A. Amazon Data Lifecycle Manager（DLM）を使い、スケジュール・保持ルールを定義してEBSスナップショットの作成・削除を自動化する

正解の根拠・詳細解説

Amazon Data Lifecycle Manager（DLM）を使うと、タグベースでEBSボリュームを指定し、スナップショット取得のスケジュール（頻度、時刻）と保持ルール（世代数や期間）をポリシーとして定義し、自動的にスナップショットの作成・削除を行える。これにより手動オペレーションなしでバックアップ運用を維持できる。

正解: A. ECSサービススケジューラが、サービスに設定されたdesired countと実際の実行中タスク数を比較し、不足分のタスクを自動的に起動する

正解の根拠・詳細解説

ECSのサービススケジューラは継続的にサービスの状態を監視し、実行中のタスク数が指定されたdesired countより少ない場合（タスクの異常終了、インスタンス障害等）、自動的に不足分の新しいタスクを起動して目標数を維持する。これはECSサービスの基本的な自己回復（self-healing）の仕組みである。

正解: B. 当該サブスクライバーのSQSキューに対するConsumer（処理側）の数をAuto Scalingで増やし、キューの可視化メトリクス（ApproximateNumberOfMessagesVisible）に基づいてスケーリングポリシーを設定する

正解の根拠・詳細解説

SQSキューに溜まったメッセージの処理が遅延している場合、CloudWatchメトリクス（ApproximateNumberOfMessagesVisibleなど）を基にAuto Scalingのターゲット追跡スケーリングポリシーを設定し、コンシューマー（EC2やECSタスク、Lambdaの同時実行数）を動的にスケールさせることで、処理能力を需要に応じて増減させ滞留を緩和できる。

正解: B. セカンダリリージョンのクラスターは通常読み取り専用だが、Managed Planned Failoverまたは手動でのフェイルオーバー操作によって書き込み可能なプライマリクラスターに昇格できる。通常のレプリケーションラグは1秒未満だが、フェイルオーバー操作自体には数十秒〜数分かかる場合がある

正解の根拠・詳細解説

Aurora Global Databaseのセカンダリリージョンのクラスターは通常時は読み取り専用だが、リージョン障害時にはManaged Planned Failover（計画的フェイルオーバー、データ損失なし）や、緊急時の手動フェイルオーバー（detach-from-global-cluster等）によって書き込み可能なスタンドアロンクラスターに昇格させることができる。完全自動のフェイルオーバーではなく、手順の実行が必要である点を理解しておく必要がある。

正解: B. 各AZにそれぞれNATゲートウェイを配置し、各AZのプライベートサブネットのルートテーブルを同AZのNATゲートウェイに向けることで、AZ障害の影響を他AZに波及させない構成にする

正解の根拠・詳細解説

高可用性を確保するため、NATゲートウェイは各AZに1つずつ配置し、各AZ内のプライベートサブネットのルートテーブルは同一AZ内のNATゲートウェイを参照するよう設定する。これにより1つのAZでNATゲートウェイに障害が発生しても、他AZのワークロードへの影響を防げる（AZ単位の障害分離）。

正解: A. Lambda関数内で指数バックオフを伴うリトライロジックを実装し、さらに非同期呼び出しの場合はLambdaの組み込みリトライ設定とDLQ（またはLambda Destinations）を活用してエラー処理を行う

正解の根拠・詳細解説

外部依存先が不安定な場合、Lambda関数内で指数バックオフとジッターを用いたリトライロジックを実装することが推奨される。さらに非同期呼び出しの場合は、Lambdaの組み込みリトライ（デフォルト2回）に加えて、最終的な失敗時の処理のためにDLQやLambda Destinations（成功時・失敗時の送信先）を設定し、確実にエラーハンドリングと可観測性を確保する。

正解: B. Direct ConnectのバックアップとしてSite-to-Site VPN接続を設定し、Direct Connect障害時に自動的にVPN経由のルートにフェイルオーバーするようBGPルーティングを設定する

正解の根拠・詳細解説

Direct Connectの可用性を高めるための一般的なパターンは、Direct Connect接続に加えてSite-to-Site VPN接続をバックアップとして構成し、BGPルーティング（VPNのパスにより高いASPathコストを設定する等）により通常時はDirect Connectを優先的に使用し、障害時には自動的にVPN経由にフェイルオーバーする構成である。専用線の新設より低コストで冗長性を確保できる。

正解: B. Multi-AZ配置でレプリケーショングループを構成し、自動フェイルオーバー（Automatic Failover）を有効化する。クラスターモードを有効にしてシャーディングを行うことでスケーラビリティも向上できる

正解の根拠・詳細解説

ElastiCache for Redisでは、レプリケーショングループをMulti-AZ配置で構成し自動フェイルオーバーを有効にすることで、プライマリノードの障害時にレプリカが自動的にプライマリへ昇格し、ダウンタイムを最小化できる。さらにクラスターモードを有効にすることでデータをシャード分割し、読み書きのスケーラビリティも向上させられる。

正解: B. API Gatewayの使用量プラン（Usage Plan）でスロットリング（レート・バーストの制限）とクォータを設定し、APIキーごとにアクセス制御する

正解の根拠・詳細解説

API Gatewayの使用量プラン（Usage Plan）では、APIキー単位でリクエストのレート制限（steady-state rate）とバースト制限、および期間あたりのクォータ（日次・週次・月次のリクエスト数上限）を設定できる。これによりクライアント単位での過剰なリクエストを制御し、バックエンドサービスを過負荷から保護できる。メソッドレベルのスロットリング設定も別途可能。

正解: A. 自動バックアップ（継続的バックアップ、ポイントインタイムリカバリ対応）を有効にしつつ、Auroraの場合はBacktrack機能やクローン機能を活用し、迅速なロールバックやテスト用クローン作成を可能にする

正解の根拠・詳細解説

RDSの自動バックアップを有効にしておくことで、保持期間内の任意の時点（秒単位）へのポイントインタイムリカバリが可能になりRPOを大幅に改善できる。Aurora MySQLではさらにBacktrack機能で迅速に直前の状態にロールバックでき、クローン機能で本番データに影響を与えずにテスト・調査用のクラスターを高速作成できるため、RTOの短縮にも寄与する。

正解: B. Pilot Light（最小限のコアリソース、例えばDBレプリカのみを常時稼働させ、障害時に残りのリソースを起動）

正解の根拠・詳細解説

DR戦略は一般的にコストとRTOのトレードオフで4段階に分類される：Backup and Restore（最も低コスト、RTOは長い）、Pilot Light（DBレプリケーション等のコアデータのみ常時稼働、障害時に他のリソースを起動してRTOを数十分程度に短縮）、Warm Standby（縮小版のフルスタックを常時稼働、RTOはさらに短い）、Multi-Site Active-Active（最もRTOが短いが最もコストが高い）。コストを抑えつつ数十分程度のRTOを目指す場合はPilot Lightが適している。

正解: A. AWS X-Ray を使い、各サービスにトレーシングを有効化してサービスマップとトレース詳細でリクエストの経路とレイテンシーを可視化する

正解の根拠・詳細解説

AWS X-Rayは分散トレーシングサービスで、リクエストが複数のサービス（Lambda、ECS、EC2、API Gateway等）を経由する際の各セグメントの処理時間やエラー情報を収集し、サービスマップとして可視化する。これによりボトルネックやエラー発生箇所を迅速に特定できる。

正解: A. CloudWatch Logsのメトリクスフィルタを作成し、該当パターンに一致するログイベントの数をカスタムメトリクスとして発行し、CloudWatchアラームで閾値を監視する

正解の根拠・詳細解説

CloudWatch Logsのメトリクスフィルタを使うと、ロググループに対して指定したパターン（フィルタパターン構文）に一致するログイベントの発生をカウントし、カスタムCloudWatchメトリクスとして発行できる。これにCloudWatchアラームを設定することで、エラーパターンの発生頻度が閾値を超えた場合にリアルタイムに近い形で通知できる。

正解: B. CloudWatchのクロスアカウントオブザーバビリティ機能を使い、モニタリングアカウントを設定して複数のソースアカウントのメトリクス・ログ・トレースを一元的に検索・可視化する

正解の根拠・詳細解説

Amazon CloudWatchのクロスアカウントオブザーバビリティ（CloudWatch Observability Access Manager）を使うと、複数のソースアカウントのメトリクス、ログ、X-Rayトレースを、単一のモニタリングアカウントから一元的に検索・可視化・分析できる。これによりマルチアカウント環境での運用監視を効率化できる。

正解: B. CloudWatch Agentまたはput-metric-data APIを使ってアプリケーション独自のメトリクスをCloudWatchのカスタムメトリクスとして発行し、これをターゲット追跡スケーリングポリシーの対象メトリクスとして指定する

正解の根拠・詳細解説

CloudWatch Agentやput-metric-data APIを使うことで、アプリケーション固有のカスタムメトリクス（キュー長、アクティブセッション数等）をCloudWatchに送信できる。これをAuto Scalingのターゲット追跡スケーリングポリシーの対象メトリクスとして指定することで、ビジネスロジックに即したスケーリングを実現できる。

正解: B. CloudTrailのイベントをEventBridgeルールでパターンマッチングし、該当イベントが発生した際にSNS通知やLambda関数による自動対応をトリガーする

正解の根拠・詳細解説

CloudTrailのイベントはEventBridge（旧CloudWatch Events）に自動的に配信されるため、EventBridgeルールでイベントパターン（例：eventName: PutUserPolicy等）をマッチングし、該当イベント発生時にSNS通知やLambda関数の起動など即時的な自動対応をトリガーできる。バッチ処理やAthenaクエリでは即時性に欠ける。

正解: A. CloudWatch LambdaInsightsまたは標準メトリクスのDuration、ColdStartに関連する指標（X-Rayのセグメントでのinitialization時間）を確認し、Provisioned Concurrencyの効果測定にも活用する

正解の根拠・詳細解説

Lambda関数のパフォーマンス分析には、CloudWatch Lambda Insights（拡張モニタリング）やX-Rayのトレースに含まれるInitializationセグメント（コールドスタート時の初期化処理時間）が有効である。これらを使って継続的にコールドスタートの発生状況やDurationを追跡し、Provisioned Concurrencyの導入効果を測定できる。

正解: B. CloudWatch LogsからS3へのエクスポートタスクまたはサブスクリプションフィルタ経由でKinesis Data Firehoseを使ってS3にアーカイブし、S3のライフサイクルルールでGlacierなどの低コストストレージクラスに段階的に移行する

正解の根拠・詳細解説

CloudWatch Logsのエクスポート機能やサブスクリプションフィルタ（Kinesis Data Firehose経由）を使ってログをS3にアーカイブし、S3のライフサイクルルールでStandard→Infrequent Access→Glacier（Deep Archive含む）へ段階的に移行することで、アクセス頻度の低下に応じたコスト最適化と長期保持を両立できる。

正解: A. CloudWatch メトリクスマス（成功率やレイテンシー等）を組み合わせたカスタムダッシュボードを作成し、CloudWatch Alarmsの複合アラーム（Composite Alarm）でSLO違反の兆候を統合的に検知する

正解の根拠・詳細解説

CloudWatchでは、可用性やレイテンシーなどのSLIに相当するメトリクスを組み合わせたダッシュボードを作成し、複合アラーム（Composite Alarm）で複数の条件を統合的に評価することで、SLO違反やエラーバジェットの消費傾向を運用上モニタリングできる。専用のSLO管理機能ではないが、既存のメトリクス・アラーム機能を組み合わせて実現可能。

正解: A. VPC Flow Logsを有効化し、ACCEPT/REJECTのアクション情報を含むログをCloudWatch LogsまたはS3に出力し、CloudWatch Logs InsightsやAthenaで分析する

正解の根拠・詳細解説

VPC Flow Logsは、ENI（ネットワークインターフェース）を通過するトラフィックの送信元・宛先IP、ポート、プロトコル、そしてACCEPT（許可）またはREJECT（セキュリティグループ/NACLによる拒否）のアクション結果を記録する。これをCloudWatch Logs InsightsやAthenaで分析することで、ブロックされた通信のパターンや原因を調査できる。

正解: B. 構造化ログ（JSON形式）への統一を推進し、CloudWatch Logs Insightsで一貫したクエリ構文（フィールド名）による横断的な検索・分析を可能にする

正解の根拠・詳細解説

各サービスが構造化ログ（JSON形式など）で統一的なフィールド名（timestamp、level、service名、request_id等）を出力するよう標準化することで、CloudWatch Logs Insightsのクエリで複数のロググループを横断して一貫した条件で検索・集計・分析が可能になり、トラブルシューティングの効率が大幅に向上する。

正解: A. CloudWatchメトリクスの統計（Statistics）でパーセンタイル（p99等）を指定してアラームを作成する

正解の根拠・詳細解説

CloudWatchメトリクスでは、平均値・最大値・最小値に加えて、パーセンタイル統計（p50、p90、p99など）を指定してアラームやダッシュボードを作成できる。平均値だけでは一部のリクエストで発生する深刻なレイテンシー悪化（テールレイテンシー）を見逃す可能性があるため、p99などのパーセンタイル監視がユーザー体験の品質保証に重要である。

正解: B. 正規ユーザーのように外部からエンドポイント（Webサイト、APIなど）に対して定期的に合成監視（Canary）を実行し、可用性やパフォーマンス、特定のUIフローの正常性を継続的に検証する

正解の根拠・詳細解説

CloudWatch Syntheticsは「Canary」と呼ばれるスクリプト（Node.jsやPythonで記述）を定期的に実行し、実際のユーザー視点でWebサイトやAPIエンドポイントの可用性、応答時間、特定のUIフロー（ログインなど）が正常に機能しているかを継続的に検証する合成監視サービスである。問題を実際のユーザーが気づく前に検知できる。

正解: A. タスク定義のlogConfigurationでawslogsログドライバーを指定し、ロググループ名・リージョン・ストリームプレフィックスを設定する

正解の根拠・詳細解説

ECS（Fargate起動タイプ含む）のタスク定義では、コンテナ定義のlogConfigurationにawslogsログドライバーを指定することで、コンテナの標準出力・標準エラー出力を自動的にCloudWatch Logsの指定ロググループに送信できる。これが最も標準的でシンプルなログ収集方法である。

正解: A. 評価期間（Evaluation Periods）やデータポイント数、Missing data treatment（欠損データの扱い：notBreaching、breaching、ignore、missingなど）の設定を見直し、メトリクスの発行間隔に適した設定に調整する

正解の根拠・詳細解説

CloudWatchアラームには「Missing data treatment」の設定があり、欠損データを「正常範囲内とみなす（notBreaching）」「異常とみなす（breaching）」「無視する（ignore）」「INSUFFICIENT_DATA状態にする（missing、デフォルト）」のいずれかを選択できる。メトリクスの発行間隔やAuto Scalingでのインスタンスの増減パターンに合わせてこれらと評価期間を調整することで、不要な誤通知を減らせる。

正解: A. X-Rayのトレースヘッダー（X-Amzn-Trace-Id）をサービス間のHTTPリクエストで伝播させ、各サービスのログ出力にこのトレースIDを含める

正解の根拠・詳細解説

AWS X-Rayでは、サービス間のHTTPリクエストヘッダーにX-Amzn-Trace-Idというトレースヘッダーを伝播させることで、リクエスト全体を一意に追跡できる。このトレースIDを各サービスの構造化ログにも含めることで、CloudWatch Logs InsightsでX-Rayのトレースとログを関連付けて、サービスを跨いだ詳細な問題調査が可能になる。

正解: B. AWSサービス自体の障害やメンテナンス、予定されているサービス変更など、自分のアカウントのリソースに影響を与えうるAWS基盤側のイベントを通知・追跡する

正解の根拠・詳細解説

AWS Health Dashboardは、利用しているAWSサービスに関する障害情報やスケジュールされたメンテナンス、リソースに影響する変更などを、自分のアカウントの利用状況に基づいてパーソナライズして通知する。EventBridgeと統合することで、これらのAWS基盤側のイベントに対する自動対応（通知、Runbook起動等）も構築できる。

正解: A. AWS Configのカスタムルール（または required-tagsマネージドルール）でタグ付けのコンプライアンスを評価し、非準拠リソースが検出された場合にEventBridge経由でSNS通知をトリガーする

正解の根拠・詳細解説

AWS Configのrequired-tagsマネージドルール（または独自のカスタムルール）を使うと、指定したタグキーが付与されていないリソースを自動的に評価・検出できる。Config ルールの評価結果（NON_COMPLIANT）はEventBridge経由でイベントとして配信できるため、これをトリガーにSNS通知を行うことで、タグ未設定リソースを継続的かつ自動的に検出・通知する仕組みを構築できる。

正解: B. CloudFormationやCDKでCloudWatchダッシュボード（AWS::CloudWatch::Dashboard）をコードとして定義し、ウィジェット配置やメトリクス選択をバージョン管理する

正解の根拠・詳細解説

CloudWatchダッシュボードはCloudFormation（AWS::CloudWatch::Dashboard）やCDKのコンストラクトを使ってコードとして定義できる。これによりダッシュボードの構成（ウィジェット、メトリクス、レイアウト）をGitでバージョン管理し、CI/CDパイプラインで一貫してデプロイ・更新でき、手動作成による設定のばらつきや消失を防げる。

正解: A. GuardDutyの検出結果をEventBridgeルールでフィルタリングし、重要度の高いFindingをトリガーとしてSNS通知とLambda関数（隔離アクションを実行）の両方を起動する

正解の根拠・詳細解説

GuardDutyの検出結果（Finding）はEventBridgeに自動配信されるため、severity（重要度）でフィルタリングしたEventBridgeルールを作成し、複数のターゲット（SNSトピックでの通知、Lambda関数での自動対応）を設定することで、重要度の高い脅威検知時に通知と自動隔離（該当インスタンスのセキュリティグループを隔離用に変更するなど）を即座に実行する自動化されたインシデント対応を構築できる。

正解: B. クエリ言語を使ってログデータに対しその場でアドホックな検索・フィルタリング・集計（統計関数や時系列のbin化等）を実行でき、複数ロググループを横断したクエリも可能

正解の根拠・詳細解説

CloudWatch Logs Insightsは専用のクエリ言語を使い、CloudWatch Logsに保存されたログデータに対して事前のスキーマ定義やETL処理なしにアドホックな検索・フィルタ・集計（stats、count、bin関数による時系列集計等）を実行できる。複数のロググループを同時に指定して横断的にクエリすることも可能で、インシデント調査やトレンド分析に有用である。

正解: A. CloudWatchアラームのアクションとしてEventBridge経由でSystems Manager Automationのランブックを起動し、診断コマンドの実行やスナップショット取得などの初期対応を自動化する

正解の根拠・詳細解説

CloudWatchアラームの状態変化をEventBridgeでキャッチし、Systems Manager Automationのランブック（事前定義された自動化ワークフロー）を起動することで、診断情報の収集（ログのエクスポート、メトリクスのスナップショット等）やよくある問題への対応アクションを自動化できる。これにより初期対応の速度と一貫性が向上する。

正解: A. AWS Systems Manager Incident Manager

正解の根拠・詳細解説

AWS Systems Manager Incident Managerは、インシデント発生時に事前定義されたレスポンスプラン（対応計画）に基づいてオンコール担当者への通知、関係者の招集、チャットチャネルの自動作成、タイムラインの記録などを行い、インシデント対応のプロセスを体系化・効率化するための専用サービスである。

正解: B. Post-incident analysis（インシデント後分析）機能を使い、タイムラインの自動記録やメトリクスを基にしたレビュー用のテンプレートを生成し、振り返りプロセスを支援する

正解の根拠・詳細解説

Systems Manager Incident Managerには、インシデント対応中に記録されたタイムラインやチャットログ、関連するメトリクス・アラームの情報を活用してポストモーテム（インシデント後分析）のドキュメント作成を支援する機能がある。これにより、再発防止策の議論やナレッジの蓄積を体系的に行いやすくなる。

正解: B. Lambda関数で、当該インスタンスのセキュリティグループを隔離専用（インバウンド・アウトバウンドを最小限に制限）のものに変更し、EBSボリュームのスナップショットを取得してフォレンジック専用アカウントにコピーする自動化ワークフローを構築する（GuardDutyのFinding検出をトリガーに）

正解の根拠・詳細解説

セキュリティインシデント対応の自動化パターンとして、GuardDutyなどの検出をトリガーにLambda関数を起動し、(1) 該当インスタンスのセキュリティグループを隔離用に変更してネットワークアクセスを制限し、(2) EBSスナップショットを取得してフォレンジック専用アカウント等に安全にコピーする、という初動対応を自動化することで、証拠保全と被害拡大の防止を迅速に行える。

正解: A. エスカレーションプラン（Escalation Plan）とレスポンスプランを作成し、インシデントの重大度（severity）に応じて通知対象や手順を自動的に変える

正解の根拠・詳細解説

Incident Managerでは、オンコールスケジュール（Contacts and Escalation Plan）とレスポンスプランを組み合わせて設定できる。レスポンスプランにはインシデントの重大度（severity）ごとの対応手順や通知先を定義でき、エスカレーションプランでは初回通知から一定時間応答がない場合に次の担当者へ自動的にエスカレーションする段階的な通知フローを構築できる。

正解: B. CloudWatch異常検知（Anomaly Detection）を使い、メトリクスの過去のパターンを機械学習モデルで学習し、動的な期待値の範囲（バンド）からの逸脱を検知するアラームに切り替える

正解の根拠・詳細解説

CloudWatch異常検知（Anomaly Detection）は、過去のメトリクスデータからトラフィックの周期的なパターン（時間帯・曜日変動等）を機械学習で学習し、動的な「正常範囲帯（バンド）」を生成する。固定閾値の代わりにこのバンドからの逸脱を検知条件にすることで、自然な変動による誤検知を減らしつつ実際の異常を検知しやすくなる。

正解: B. CloudWatchアラームをトリガーにAWS Step Functionsのステートマシンを起動し、各対応アクション（Lambda、API呼び出し等）を順序やエラーハンドリングを含めて編成（オーケストレーション）する

正解の根拠・詳細解説

複数のステップを順序立てて実行し、エラーハンドリングや条件分岐、リトライを含む複雑なワークフローを構築する場合は、AWS Step Functionsが適している。CloudWatchアラーム（EventBridge経由）をトリガーにStep Functionsのステートマシンを起動し、チケット起票・通知・自動対応などの各ステップを視覚的かつ堅牢にオーケストレーションできる。

正解: A. インシデントごとに自動的にタイムラインが作成され、チャットの発言、ステータス変更、関連するCloudWatchアラームなどのイベントが時系列で記録される

正解の根拠・詳細解説

Systems Manager Incident Managerはインシデントごとにタイムラインを自動生成し、ステータス変更、関係者のコメント、関連するアラームのトリガー等のイベントを時系列で記録する。これにより関係者がリアルタイムで状況を正確に把握でき、対応後の振り返り（ポストモーテム）にも活用できる。

正解: A. CloudWatchアラームのアクションとしてEC2 Auto Recovery、またはSystems Manager Automationのランブックを直接アクションとして設定し、既知のパターンに対する復旧処理を自動実行する

正解の根拠・詳細解説

CloudWatchアラームのアクションには、EC2の自動復旧（Auto Recovery、基盤ハードウェア障害時の自動再起動）の他、Systems Manager Automationのランブックを直接トリガーする設定が可能である。既知の問題パターンに対する復旧手順（再起動、設定リセット等）をランブックとして定義しておくことで、アラーム発火時に人手を介さず自動的に復旧処理を実行できる（自己修復・auto-remediation）。

正解: A. AWS Health Dashboardのイベントをトリガーに EventBridgeルールを作成し、Systems Manager Incident Managerのインシデント作成やSNS通知を自動的に行う

正解の根拠・詳細解説

AWS Health Dashboardのイベント（特にPersonal Health Dashboardの自分のリソースに影響するイベント）はEventBridgeに配信できる。これをトリガーに、Incident Managerでのインシデント自動作成や、SNS経由での運用チームへの即時通知を構成することで、AWS基盤側の問題に対しても迅速な検知と対応開始ができる。

正解: A. インシデントのチャットチャネル連携（Chatbot/Slack統合）とタイムライン機能を併用し、関連ドキュメントのリンクをタイムラインに記録、インシデント終了後はそのままアーカイブとして保持する

正解の根拠・詳細解説

Incident ManagerはChatbot等を通じたチャットチャネル連携と組み合わせて使うことが多く、対応中のコミュニケーションやドキュメントへの参照をタイムラインに記録できる。インシデント終了後もこれらの記録はアーカイブとして保持され、後の振り返りやナレッジベースの構築に活用できる。

正解: A. CodeDeployのデプロイ完了後のBake timeを延長し、CloudWatchアラームによる自動ロールバックの監視期間をデプロイ完了直後だけでなく一定時間継続させる、あるいは独立した運用監視のアラームとSystems Manager Automationを組み合わせて遅延性の問題にも対応できるロールバック機構を別途用意する

正解の根拠・詳細解説

CodeDeployの自動ロールバックはデプロイ完了直後の監視に主眼があるが、デプロイ後しばらく経ってから発生する遅延性の問題（メモリリークの蓄積等）に対応するには、Bake time（待機時間）を適切に延長することに加え、デプロイ完了後も継続する独立した運用監視のCloudWatchアラームとSystems Manager Automationのランブックを組み合わせ、いつでも安全にロールバック処理を起動できる仕組みを別途備えておくことが望ましい。

正解: A. VPC Flow Logs、Direct ConnectのCloudWatchメトリクス（仮想インターフェースの状態等）、およびオンプレミス側のネットワーク監視ツールのログを統合的に確認する

正解の根拠・詳細解説

ハイブリッド環境での障害切り分けには、AWS側のVPC Flow Logs（AWS内のトラフィック状況）、Direct ConnectやVPNのCloudWatchメトリクス（仮想インターフェースの状態、BGPステータス等）と、オンプレミス側のネットワーク監視ツールやログを組み合わせて確認することで、問題がAWS側・オンプレミス側・接続部分のどこにあるかを迅速に切り分けられる。

正解: B. 自動対応のランブックには影響範囲を限定するガードレール（対象リソースの厳密な絞り込み、ドライランオプション、重大な操作には人間の承認ステップを残す等）を組み込み、段階的に自動化の範囲を拡大していく

正解の根拠・詳細解説

自動修復（auto-remediation）の導入は有用だが、誤動作のリスクもあるため、対象リソースを正確にスコープするタグやフィルタ、破壊的な操作には人間の承認ステップ（Systems Manager Automationの承認機能等）を残す、まずは低リスクなアクションから自動化し段階的に範囲を拡大する、といったガードレールを設けることが推奨される。

正解: A. AWS Health Dashboard（および必要に応じてAWS Service Health Dashboard）で該当リージョン・サービスの障害状況を確認し、自社のCloudWatchアラームやログと合わせて影響範囲を特定する

正解の根拠・詳細解説

AWS基盤側の障害が疑われる場合、まずAWS Health Dashboard（アカウント固有の影響を確認）やAWS Service Health Dashboard（サービス全体のステータス）を確認することで、問題がAWS側の既知の障害によるものかを迅速に判断できる。これと自社のCloudWatchメトリクス・ログを組み合わせることで、影響範囲を正確に特定し、適切な対応（フェイルオーバー等）を判断できる。

正解: A. エスカレーションプランで初回通知への応答タイムアウトを設定し、応答がない場合は自動的に次のオンコール担当者へエスカレーションする仕組みを構築する

正解の根拠・詳細解説

Incident ManagerのエスカレーションプランではStage（段階）ごとに通知対象者と応答待機時間を設定でき、設定した時間内に確認（acknowledge）がない場合は自動的に次の段階の担当者へエスカレーションする。これにより、重大度の高いインシデントに対して一定時間内に必ず誰かが対応を開始する体制を技術的に保証できる。

正解: A. Shield AdvancedのDDoS Response Team（DRT）への連絡や、WAFのレートベースルール・カスタムルールの調整によるブロック、CloudWatchメトリクス（リクエスト数、ブロック数）の確認を行う

正解の根拠・詳細解説

AWS Shield Advancedを契約している場合、大規模なDDoS攻撃時にはAWS DDoS Response Team（DRT）に連絡してサポートを受けられる。また、AWS WAFのレートベースルールやカスタムルールで悪意のあるトラフィックパターンをブロックし、関連するCloudWatchメトリクス（許可数、ブロック数、カウント数等）を確認しながら、サービスを完全に停止せず正当なユーザーへの影響を抑えつつ対応することが望ましい。

正解: B. 5 Whys（ファイブ・ホワイズ）分析

正解の根拠・詳細解説

5 Whys分析は、発生した問題に対して「なぜ」を5回程度繰り返し問いかけることで、表面的な事象から根本的な原因（プロセスやシステム設計上の問題）まで掘り下げる手法である。ポストモーテムにおいて、単一の技術的な原因だけでなく、組織的・プロセス的な要因まで特定するために広く使われる。

正解: A. AWS Fault Injection Service（FIS）を使い、EC2インスタンスの停止、APIレイテンシーの注入、AZ全体の障害シミュレーションなど、制御された条件下でカオスエンジニアリングの実験を実施する

正解の根拠・詳細解説

AWS Fault Injection Service（FIS）は、カオスエンジニアリングの手法に基づき、制御された安全な条件下でEC2インスタンスの停止、APIエラー・レイテンシーの注入、AZ全体の電源遮断シミュレーションなどの障害実験を実施できるマネージドサービスである。これにより本番相当の環境でシステムの耐障害性を事前に検証し、運用チームの対応プロセスも実践的に訓練できる。本番でやみくもに障害を起こすのではなく、停止条件（Stop Condition）を設定して安全に実験を行える点が特徴。

正解: A. Incident Managerのインシデント記録（タイムライン、対応時間、関連リソース等）をエクスポートまたはAPI経由で取得し、QuickSightなどのBIツールでMTTA（平均確認時間）・MTTR（平均復旧時間）などのKPIを可視化・トレンド分析する

正解の根拠・詳細解説

Incident Managerに記録されたインシデントデータ（発生時刻、確認時刻、解決時刻、関連するレスポンスプラン等）をAPIやエクスポート機能で取得し、Amazon QuickSightなどのBIツールでMTTA（Mean Time to Acknowledge）やMTTR（Mean Time to Resolve）といったKPIを可視化することで、インシデント対応プロセスの継続的な改善点（特定の原因の頻発、対応の遅延傾向等）を客観的に特定できる。

正解: B. AWS IAM Identity Center（旧AWS SSO）を使い、Organizationsと統合して一元的なID管理とアカウント間のシングルサインオン、Permission Setによる権限管理を行う

正解の根拠・詳細解説

AWS IAM Identity Center（旧AWS SSO）は、AWS Organizationsと統合し、外部のID provider（Azure AD、Okta等）または組織内ディレクトリと連携して一元的なID管理を行い、Permission Setを使ってユーザー・グループに対するアカウントごとの権限割り当てを管理しながらシングルサインオンを実現できる。IAMユーザーの個別管理やRoot/アクセスキーの共有はセキュリティリスクが高く非推奨。

正解: B. AWS Organizationsのサービスコントロールポリシー（SCP）でS3のパブリックアクセスを許可するAPI呼び出し自体を拒否し、さらにS3 Block Public Accessをアカウントレベルで有効化する

正解の根拠・詳細解説

組織全体でS3のパブリックアクセスを防止するには、アカウントレベルでS3 Block Public Access設定を有効化することに加え、SCP（Service Control Policy）でPutBucketPolicyやPutBucketAclなどパブリックアクセスを許可する可能性のあるAPI呼び出し自体を拒否することで、IAM権限に関わらず組織全体で強制的に制限できる。これは個別バケットの目視確認よりも確実でスケーラブルなガバナンス手法である。

正解: B. CodeBuildプロジェクトやLambda関数にIAMロール（サービスロール）を関連付け、一時的な認証情報を自動的に取得・利用する

正解の根拠・詳細解説

CodeBuildやLambda、EC2などのAWSサービスからAWS APIを呼び出す際は、長期的なアクセスキーを使うのではなく、サービスにIAMロールをアタッチし、AWS STSが発行する一時的な認証情報を自動的に利用するのがベストプラクティスである。これにより認証情報のローテーション管理の負担やキー漏洩のリスクを大幅に低減できる。

正解: A. AWS Secrets Managerを使い、RDSなどのデータベース認証情報を保存し、自動ローテーション機能を有効にしてLambda関数による定期的なパスワード変更を行う

正解の根拠・詳細解説

AWS Secrets Managerはデータベース認証情報やAPIキーなどの機密情報を暗号化して保存し、RDS・Redshift・DocumentDBなどと統合した自動ローテーション機能を提供する。これにより、アプリケーションコードに認証情報を直接記述する必要がなくなり、定期的なパスワード変更も自動化でき、セキュリティリスクを大幅に低減できる。

正解: A. KMSキーのキーポリシーで他アカウントのIAMプリンシパルに対しkms:Decrypt等の権限を許可し、S3バケットポリシーでも該当アカウントからのアクセスを許可する

正解の根拠・詳細解説

KMSのカスタマー管理キー（CMK）はキーポリシーで他のAWSアカウントのIAMプリンシパルに対し、Decrypt・GenerateDataKey等の権限を許可することでクロスアカウントでの利用が可能になる。これと合わせてS3バケットポリシーでも該当アカウントからのバケット・オブジェクトへのアクセスを許可することで、暗号化を維持したまま安全にデータを共有できる。

正解: A. AWS Security Hubを有効化し、複数のセキュリティ標準（CISベンチマーク等）に対する自動チェックを実施し、GuardDutyやInspector、Configなど他サービスの検出結果も統合的に集約・可視化する

正解の根拠・詳細解説

AWS Security Hubは、CISベンチマークやAWS Foundational Security Best Practices、PCI-DSSなどの業界標準・ベストプラクティスに対する自動コンプライアンスチェックを実施し、GuardDuty、Inspector、Macie、Configなど他のセキュリティサービスの検出結果も一元的に集約・可視化するハブとして機能する。これにより組織全体のセキュリティ態勢を統一的に評価できる。

正解: A. IAM Access Analyzerのポリシー検証機能（カスタムポリシーチェック含む）をパイプラインに組み込み、デプロイ前にポリシードキュメントを検証し、セキュリティ警告やエラーがあればデプロイを停止する

正解の根拠・詳細解説

IAM Access Analyzerには、ポリシーの検証機能（IAM Policy Validation）があり、構文エラーやセキュリティ上の警告（過度に広い権限、未使用のアクション等）、ベストプラクティス違反を検出できる。さらにカスタムポリシーチェック機能を使うことで、組織独自のルール（特定アクションの禁止等）に対する検証もCI/CDパイプラインに組み込み、デプロイ前に問題のあるポリシーをブロックできる。

正解: A. IAM Access Analyzer の「未使用アクセスの検出」機能、またはIAMのアクセスアドバイザー（最終アクセス情報）を使い、実際に使用されているサービス・アクションを確認した上でポリシーを絞り込む

正解の根拠・詳細解説

IAM Access Analyzerの未使用アクセス分析（Unused access analyzer）機能やIAMコンソールのアクセスアドバイザータブでは、ロールやユーザーが実際にどのサービス・アクションに最終アクセスしたかの情報を確認できる。これにより、付与されているが使用されていない過剰な権限を特定し、最小権限の原則に基づいてポリシーを段階的に絞り込むことができる。

正解: A. ベースイメージを信頼できるソース（Amazon ECR Public、検証済みのベンダー提供イメージ等）から取得し、ECRの脆弱性スキャンを有効化し、ビルドプロセスへのアクセス権限を最小化し、可能であればイメージに署名（AWS Signer等）して検証する

正解の根拠・詳細解説

コンテナサプライチェーンのセキュリティ強化には、信頼できるベースイメージの使用、ECRのイメージスキャン（プッシュ時・定期スキャン）による脆弱性検出、ビルド環境・パイプラインへのアクセス権限の最小化（誰がビルド定義を変更できるか）、そして可能であればイメージの署名と検証（AWS Signer、cosignなど）を組み合わせることが推奨される多層的なアプローチである。

正解: B. 対象OUに対しSCP（Service Control Policy）を適用し、特定のAPIアクション（ec2:ModifyInstanceAttribute、ec2:DeleteSecurityGroup等）を拒否するルールを定義する。これによりOU配下のすべてのアカウント・ロールに対して強制的に制限される

正解の根拠・詳細解説

AWS OrganizationsのSCP（Service Control Policy）は、指定したOUやアカウントに対して、IAMロール・ユーザーの権限に関わらず特定のAPIアクションを拒否する「ガードレール」を設定できる。本番環境用OUにSCPを適用してEC2のインスタンスタイプ変更やセキュリティグループ削除などの操作を拒否することで、IAMポリシーの設定ミスがあっても組織レベルで確実に制限を強制できる。

正解: B. Inspector v2は、SSM AgentがインストールされたEC2インスタンスやECRに保存されたコンテナイメージに対して自動的かつ継続的に脆弱性スキャンを実行し、新しいCVE情報が公開された際にも再評価する

正解の根拠・詳細解説

Amazon Inspector（v2）は、SSM Agentが有効なEC2インスタンスやLambda関数、ECRにプッシュされたコンテナイメージに対して、エージェントベースまたはエージェントレスで自動的・継続的に脆弱性スキャンを実行する。新たな脆弱性（CVE）情報が公開された際には、既存のスキャン結果を自動的に再評価し、新たに該当する脆弱性があれば検出結果を更新する。

正解: A. S3バケットポリシーでクロスアカウントアクセスを許可する場合や、Lambda関数のリソースベースポリシーで特定のAWSサービス（S3、API Gateway等）からの呼び出しを許可する場合など、リソース側でアクセス許可を定義する必要がある場合

正解の根拠・詳細解説

リソースベースポリシー（S3バケットポリシー、KMSキーポリシー、Lambdaのリソースベースポリシー、SQS/SNSのアクセスポリシー等）は、特にクロスアカウントアクセスの許可や、AWSサービス（S3イベントからLambdaを呼び出す等）からのリソースへのアクセスを許可する際に有用である。IDベースポリシー（IAMロール・ユーザーのポリシー）と組み合わせて、アクセス許可の評価が行われる。

正解: A. IAMロールを作成し、外部IDやMFA条件を付与した上で、AssumeRoleによる一時的な認証情報の発行を許可し、アクセス期間が終了したらロールの信頼関係を解除または削除する

正解の根拠・詳細解説

第三者への一時的なアクセス許可には、IAMロールを作成し、外部ID（External ID）やMFA条件などの追加のセキュリティ条件を信頼ポリシーに含めた上でAssumeRoleを許可するパターンが推奨される。これにより一時的な認証情報（有効期限あり）のみが発行され、アクセス終了後はロールの信頼関係を解除するだけで即座にアクセスを無効化でき、長期的なクレデンシャルの管理負担も避けられる。

正解: B. AWS WAFの マネージドルールグループ（AWS Managed Rules、特にIP reputation listを含むAmazon IP reputation list）を有効化し、AWSが継続的に更新する脅威インテリジェンス情報を活用してブロックする

正解の根拠・詳細解説

AWS WAFのマネージドルールグループには、Amazon IP reputation list（AWSの脅威インテリジェンスに基づき悪意のあるIPアドレスを継続的に更新するリスト）などが含まれており、これを有効化することで、自社で個別にIPリストを管理せずとも、最新の脅威情報に基づいた自動ブロックを実現できる。手動更新よりも迅速かつ正確に新たな脅威に対応できる。

正解: A. IAMポリシーやSCPでaws:RequestedRegion条件キーを使い、許可されたリージョン以外でのリソース作成・操作を拒否する

正解の根拠・詳細解説

IAMポリシーやSCPの条件キーaws:RequestedRegionを使うことで、許可されたリージョン以外でのAPIリクエスト（リソースの作成等）を拒否できる。これにより、GDPRなどのデータ居住性（data residency）要件に対応するため、特定のリージョン外でのデータ保存・処理を技術的に強制的に防止できる。

正解: A. IAM Access AnalyzerのカスタムポリシーチェックやOPA（Open Policy Agent）等のポリシー検証ツールをCI/CDパイプラインに組み込み、CloudFormation Guardやcfn-lintと併用してデプロイ前に静的にチェックする

正解の根拠・詳細解説

IaCパイプライン内でIAMポリシーの安全性を担保するには、IAM Access Analyzerのポリシー検証・カスタムポリシーチェック機能や、CloudFormation Guard、cfn-lin、あるいはOPA（Open Policy Agent）のようなポリシー as コードの検証ツールをデプロイ前のステージに組み込み、過度に広い権限を含むポリシーを自動的に検出してデプロイをブロックすることが効果的である。

正解: A. ACMで発行されたパブリック証明書はDNS検証またはメール検証を使った自動更新がデフォルトでサポートされており、DNS検証を使い証明書がACM管理かつ使用中であれば、有効期限切れ前に自動的に更新される

正解の根拠・詳細解説

ACMで発行されたパブリック証明書は、DNS検証方式を使っている場合、証明書がAWSリソース（ALB、CloudFront等）で実際に使用されており、検証用のDNSレコードがRoute 53等に残っている限り、有効期限切れ前に自動的に更新（renewal）される。これにより手動更新の運用負荷を大幅に削減できる。メール検証の場合は手動対応が必要になる点に注意が必要。

正解: B. CloudTrailでS3のデータイベント（Data Events、GetObject/PutObject等のオブジェクトレベルの操作）を該当バケットに対して有効化し、ログをS3やCloudWatch Logsに記録する

正解の根拠・詳細解説

CloudTrailのデフォルトでは管理イベント（API呼び出しの管理操作）のみが記録され、S3オブジェクトレベルの操作（GetObject、PutObject等）は記録されない。詳細なオブジェクトレベルの監査が必要な場合は、CloudTrailでデータイベント（Data Events）を該当するS3バケットに対して明示的に有効化する必要があり、これにより誰が・いつ・どのオブジェクトにアクセスしたかを追跡できる。

正解: A. Amazon GuardDuty を有効化し、CloudTrailのログやVPC Flow Logs、DNSログを分析して異常なAPIコールパターンや既知の脅威インジケーターに基づく検出結果（Finding）を生成させる

正解の根拠・詳細解説

Amazon GuardDutyは、CloudTrailの管理イベント・データイベント、VPC Flow Logs、DNSクエリログなどを継続的に分析し、機械学習や脅威インテリジェンスに基づいて、通常と異なる地域からのAPIコール、認証情報の漏洩が疑われる挙動、権限昇格の試みなどの異常なアクティビティを検出結果（Finding）として生成する脅威検出サービスである。

正解: A. CodePipelineの実行履歴とCloudTrailのAPIログ（承認アクション、StartPipelineExecution等）を組み合わせて記録し、CloudTrailログファイルの整合性検証（log file validation）を有効化した上でS3にエクスポートし、必要に応じてS3 Object Lockで改ざん防止と長期保持を行う

正解の根拠・詳細解説

CodePipelineの各ステージの実行・承認アクションはCloudTrailに記録される。CloudTrailのログファイル整合性検証（log file validation）を有効にすることでログの改ざんを検知可能にし、さらにS3にエクスポートした上でObject Lock（WORM）を設定することで、改ざん不可能な形での長期保存が実現でき、コンプライアンス監査の要件に対応できる。