答え: B

解説: CodeDeployはCloudWatchアラームによってトリガーできる自動ロールバックをサポートします。デプロイグループを設定して特定のCloudWatchアラーム（エラー率など）を監視し、アラームが定義された期間内にALARM状態になった場合に自動的にロールバックします。これは手動介入やカスタムLambda関数を必要としない最も自動化されたネイティブな解決策です。

答え: B

解説: CodeBuildはビルド間で再利用可能なビルドアーティファクト（npmモジュール、Maven依存関係など）を保存するキャッシュをサポートします。キャッシュはビルド環境にローカルまたはS3に保存できます。変更されていない依存関係の再ダウンロードを避けることでビルド時間を大幅に短縮します。コンピュートタイプの増加（A）はビルド自体を高速化しますがダウンロード時間は短縮しません。

答え: B

解説: AWS CloudFormation StackSetsは1つの操作で複数のアカウントとリージョンにわたってCloudFormationスタックを作成、更新、削除することができます。マルチアカウント、マルチリージョンデプロイメント専用に設計されています。ネストされたスタック（A）は1つのアカウント内でスタックを階層的に整理します。CDK（C）はCloudFormationテンプレートを生成しますがクロスアカウントデプロイを管理しません。Service Catalog（D）は製品ポートフォリオを管理します。

答え: D

解説: 最も包括的なアプローチは、必要なタグなしのリソース作成を拒否するaws:RequestTag条件キーを持つIAMポリシーと、タグ値を標準化するAWS Organizationsタグポリシーを組み合わせることです。IAMポリシーのみ（A）は作成時のタグ付けを要求しますが値を標準化しません。Configルール（B）は事後検出です。SCPs（C）はアクションを拒否できますが慎重な設定が必要です。

答え: D

解説: CodeDeployは一度にデプロイするインスタンスの割合や数を指定するカスタムデプロイ設定の作成を許可します。最小健全ホスト値25%のカスタム設定は一度に25%のインスタンスにデプロイします。HalfAtATime（B）は50%ずつデプロイします。OneAtATime（C）は1インスタンムずつデプロイします。AllAtOnce（A）はすべてのインスタンスに同時にデプロイします。

答え: B

解説: KubernetesのGitOpsはGitの望ましい状態とKubernetesの実際の状態を継続的に調整するFluxまたはArgoCDのようなツールを使用します。AWS CodePipelineはこれらのツールをトリガーするか、独立して動作してCodeCommit/GitHubから継続的にプルできます。CodePipelineとCodeDeploy（A）は従来のデプロイ用です。Lambda（C）はGitOpsツールではありません。Elastic Beanstalk（D）はマネージドアプリケーションデプロイ用です。

答え: C

解説: AWS Secrets ManagerまたはSSMパラメータストアのSecureStringパラメータはIAMベースのアクセス制御を持つ暗号化ストレージを提供します。CodeBuildは環境変数でSecrets ManagerシークレットとSSMパラメータをネイティブに参照し、ビルド時に取得できます。環境変数にプレーンテキストを保存すること（A）はログに公開されます。リポジトリに保存すること（B）はセキュリティリスクです。S3（D）は追加のコードが必要でアクセス制御統合が劣ります。

答え: B

解説: AWS CodeArtifactはnpmをCodeArtifactをレジストリとして設定し一時的な認証トークンを取得するログインコマンド（aws codeartifact login --tool npm）を提供します。このコマンドはbuildspec.ymlのビルド前フェーズで実行する必要があります。package.jsonにURLを設定するだけ（A）では認証を処理しません。VPCエンドポイント（C）はネットワーク接続用です。環境変数のみ（D）はnpmクライアントを設定しません。

答え: A

解説: AWS CodePipelineは手動承認アクションをネイティブにサポートします。パイプラインが承認ステージに達すると、SNS（メールをトリガーできる）経由で通知を送り、レビュアーが承認または拒否するまで一時停止します。これが通知付きパイプライン承認のネイティブな目的に合った解決策です。SQS+Lambda（B）は不必要な複雑さを追加します。

答え: C

解説: AWS Configはリソース設定を継続的に監視し、Configルールに対して評価します。ルールが違反されると、ConfigはSystems Manager Automationドキュメントを使用してリソースをコンプライアンス状態に戻す修復アクションを自動的にトリガーできます。CloudTrail（A）はAPI呼び出しをログに記録します。Inspector（B）は脆弱性をスキャンします。Security Hub（D）は調査結果を集約しますが自動修復はしません。

答え: A

解説: ECSはCodeDeployと統合してブルー/グリーンデプロイメントを提供します。CodeDeployは古い（ブルー）から新しい（グリーン）タスクセットに段階的にトラフィックをシフトし、ヘルスチェックを監視し、ヘルスチェックが失敗した場合に自動的に前のバージョンにロールバックします。CloudFormationローリングアップデート（B）はEC2 Auto Scaling用です。ECSローリングアップデート（C）はより洗練されていなくロールバックが難しいです。手動更新（D）はエラーが発生しやすいです。

答え: B

解説: AWS Systems Manager Run CommandはSSHアクセスやAnsibleコントロールノードの管理なしに複数のEC2インスタンスでコマンドを実行できます。State Managerはインスタンス設定を維持するための望ましい状態設定を提供します。SSMエージェントはAmazon Linux/WindowsのAMIにプリインストールされています。Ansible（A）はコントロールノードの管理が必要です。OpsWorks（C）はChef/Puppetの専門知識が必要です。EC2ユーザーデータ（D）はインスタンス起動時にのみ実行されます。

答え: B

解説: CloudFormationスタックイベントはスタックの作成/更新中に何が起こったかの詳細なタイムライン（どのリソースが失敗したか、なぜ失敗したか、エラーメッセージなど）を提供します。スタックは失敗情報を保持しながら失敗状態（ROLLBACK_COMPLETEまたはUPDATE_ROLLBACK_COMPLETE）に留まります。CloudTrail（A）はAPI呼び出しを表示しますがリソースレベルの失敗は表示しません。CodeBuildログ（D）はビルドステージの失敗用です。

答え: B

解説: AWS Configルールはリソース設定を継続的に評価します。Configはコンプライアンスステータスが変化したとき（例：COMPLIANTからNON_COMPLIANTへ）にSNS経由で通知を送るよう設定できます。これはポリシーが違反されたときのリアルタイム通知を提供します。CloudTrailとEventBridge（A）はAPI呼び出しを検出し、設定コンプライアンスは検出しません。Inspector（C）は脆弱性スキャン用です。Security Hub（D）は複数のサービスから調査結果を集約します。

答え: B

解説: AWS CDKコンストラクトはnpm、PyPI、またはMavenを通じてライブラリとしてパッケージ化し共有できる再利用可能なインフラコンポーネントです。チームは暗号化とバージョニングが有効なセキュアなS3バケットコンストラクトなど、ベストプラクティスをカプセル化した独自のコンストラクトライブラリを作成できます。CDKアスペクト（C）はCDKツリーの走査と変更（タグの適用など）用です。CloudFormationテンプレート（A、D）はCDKではありません。

答え: B

解説: Lambda用CodeDeployはカナリアデプロイメントをサポートします。Canary10Percent5Minutesはトラフィックの10%を新しいLambdaバージョンにシフトし、5分待ち、CloudWatchアラームがトリガーされなければ残り90%をシフトします。これは要件と一致します。リニアデプロイメント（A、D）はトラフィックを均等な増分で段階的にシフトします。AllAtOnce（C）はすぐにすべてのトラフィックをシフトします。

答え: D

解説: CodeCommitでプルリクエストを強制するには2つのコンポーネントが必要です：（1）一般の開発者のメインブランチへの直接プッシュを拒否するIAMポリシー、（2）マージ前にプルリクエストに最小数の承認を要求するCodeCommit承認ルールテンプレート。承認ルールテンプレートのみでは直接プッシュを防止できません。IAMポリシーのみではPRの承認数を強制しません。

答え: A

解説: CloudWatchにカスタムメトリクスを公開し、ターゲット追跡スケーリングポリシーを持つApplication Auto Scalingを使用することで、キューの深さなどのカスタムメトリクスに基づいてさまざまなリソース（ECSタスク、DynamoDB容量など）を自動的にスケールできます。X-Ray（B）は分散トレーシング用です。Lambda+DynamoDB（C）は自動スケーリングを提供しません。EventBridge+Step Functions（D）はイベントオーケストレーション用です。

答え: D

解説: AWS ConfigはCloudFormationスタックをリソースタイプとして設定履歴を記録します。時間の経過とともにスタック設定へのすべての変更を追跡し、監査トレイルを提供します。CloudTrail（A）はAPI呼び出しをログに記録しますが各時点でのスタック設定全体ではありません。変更セット（B）は適用前に変更されるものを示します。ドリフト検出（C）はテンプレートと実際のリソースの現在の差異を示します。

答え: B

解説: 単一のCodePipelineはターゲットアカウントのIAMロールを引き受けることで複数のAWSアカウントにデプロイできます。ツールアカウントのパイプラインはデプロイするためにターゲットアカウント（dev、staging、prod）のロールを使用します。これはアカウント分離を維持しながらパイプラインの単一の情報源を提供します。別々のパイプライン（A）は設定を重複させ同期を困難にします。Elastic Beanstalk（C）はマルチアカウントデプロイに対応しません。

答え: B

解説: ELBヘルスチェックを持つEC2 Auto Scalingグループはヘルスチェックに失敗したインスタンスを自動的に終了して交換します。これはEC2のネイティブなセルフヒーリングメカニズムです。SNS通知を持つCloudWatchアラーム（A）は通知しますが自動的に交換しません。Lambda（C）は監視できますがカスタムの複雑さを追加します。メンテナンスウィンドウ（D）はスケジュールされたメンテナンス用です。

答え: B

解説: AWS CloudTrailはすべてのAPI呼び出しを記録します。EventBridgeは特定のCloudTrailイベント（不正なAPI呼び出し、ルートアカウントの使用、セキュリティグループの変更など）に一致するルールを作成し、SNS通知をトリガーできます。これはAPIレベルのアラートの標準パターンです。VPCフローログ（A）はネットワークトラフィックをキャプチャします。Config（C）はリソース設定を監視します。GuardDuty（D）はML ベースの脅威検出を提供します。

答え: C

解説: 最小権限の原則に従い、CodeBuildサービスロールには特定のECR権限が必要です：ecr:GetAuthorizationToken（Dockerログイン用）、ecr:BatchCheckLayerAvailability、ecr:PutImage、ecr:InitiateLayerUpload、ecr:UploadLayerPart、ecr:CompleteLayerUpload。AmazonEC2ContainerRegistryPowerUser（B）は必要な権限をすべて含みますが必要以上のものも含みます。FullAccess（A）は削除権限を含みます。AmazonECS-FullAccess（D）はECS管理用です。

答え: B

解説: CloudFormationリソース（RDSインスタンスなど）にDeletionPolicy: Retainを設定することで、スタックが削除されるときにリソースが保持（削除されない）されます。これはCloudFormationスタック操作による誤ったデータベース削除を防ぎます。ターミネーション保護（D）はスタック全体が削除されるのを防ぎますが、質問はデータベースリソースを具体的に尋ねています。

答え: A

解説: CodePipelineのCodeBuildステージは統合テストの実行に使用できます。テストフェーズのbuildspec.ymlは外部テストフレームワークを呼び出し、テストスクリプトを実行し、結果を報告できます。テストが失敗するとCodeBuildステージが失敗しパイプラインが停止します。これがAWS内で最も統合されたアプローチです。Lambda呼び出し（B）は単純なイベント駆動タスク用です。Jenkins（C）はJenkinsインフラの管理が必要です。手動承認（D）は自動化されていません。

答え: A

解説: AWS Systems Manager Patch Managerはパッチベースラインとパッチグループに基づいてEC2インスタンスを自動的にパッチできます。メンテナンスウィンドウはパッチ操作をスケジュールします。インスタンスのSSMエージェントはSSHを必要とせずにパッチ指示を受け取ります。EC2ユーザーデータ（B）は起動時にのみ実行されます。Ansible Tower（C）はインフラの管理が必要です。OpsWorks（D）はChefの専門知識が必要です。

答え: B

解説: AWS CodeDeployカナリアデプロイメントはトラフィックの一部を新バージョンにシフトしCloudWatchアラームを監視します。ベーキング期間中にアラームがトリガーされると、CodeDeployは自動的に前のバージョンにロールバックします。これにより完全に自動化されたカナリアデプロイメントとロールバックが提供されます。Route 53加重ルーティング（A）は手動ロールバックが必要です。ALB加重ターゲットグループ（C）はカスタム自動化が必要です。

答え: A

解説: NATゲートウェイなしのVPC内でCodeBuildを実行するとインターネットアクセスがなくなります。CodeCommit、ECR、S3、その他のAWSサービス用のVPCエンドポイントにより、ビルドはAWSプライベートネットワーク経由でプライベートリポジトリとECRにアクセスできます。すべてのアウトバウンドをブロックするセキュリティグループ（B）はAWSサービスアクセスもブロックします。制限付きNATゲートウェイ（C）はまだインターネットアクセスを提供します。

答え: B

解説: AWS AppConfigは再起動なしにアプリケーションへの動的設定デリバリーのために特別に設計されています。設定変更の段階的なロールアウト、検証、モニタリングをサポートします。アプリケーションはAppConfigエージェントまたはSDKを使用してリアルタイムで設定更新を受け取ります。SSMの定期的なポーリング（C）は機能しますがAppConfigほど洗練されていません。アプリケーションの再起動（A）はダウンタイムを引き起こします。DynamoDB（D）はカスタムポーリングコードが必要です。

答え: B

解説: Amazon CloudWatch LogsはEC2（CloudWatchエージェント経由）とLambda（自動統合）とネイティブに統合されています。CloudWatch Logs Insightsは集中ログ分析のための強力なクエリ機能を提供します。これが最も統合されたAWSネイティブな解決策です。S3 + Athena（A）は機能しますがログのエクスポートが必要です。Kinesis（C）はストリーミング用でログストレージ/分析用ではありません。EC2上のELK（D）はインフラの管理が必要です。

答え: B

解説: AWS X-Rayサービスマップはアプリケーションコンポーネントとその接続の視覚的な表現を提供します。トレース内の各セグメントとサブセグメントは作業の単位を表し、費やされた時間を示します。トレース詳細を調べることで、どの特定のダウンストリーム呼び出し（データベース、API、マイクロサービス）が高いレイテンシを引き起こしているか特定できます。CloudWatchメトリクス（A）は集計データを提供します。RDS拡張モニタリング（C）はデータベース内部用です。EC2 CPUメトリクス（D）は分散呼び出しレイテンシを示しません。

答え: B

解説: 最善のアプローチは複数のメカニズムを使用します：（1）CodeCommitイベント発生時にフィーチャーブランチビルドとPRチェックのためのCodeBuildプロジェクトをトリガーするEventBridgeルール、（2）本番デプロイのためにメインブランチのみでトリガーされるCodePipeline。各ブランチの別々のパイプライン（C）は大規模では実用的ではありません。すべてのブランチで単一パイプライン（A）は意図しないデプロイにつながる可能性があります。Jenkins（D）はインフラの管理が必要です。

答え: B

解説: AWS Secrets Managerはデータベース認証情報の自動ローテーションをサポートします。RDS用の組み込みローテーションLambda関数がSecrets ManagerとRDSインスタンスの両方でパスワードを更新します。アプリケーションはSecrets Managerから現在のシークレットを取得するため、ローテーションは透過的です。KMSキーローテーション（A）は暗号化キー用です。SSMパラメータストア（C）はカスタムLambdaでローテーションできますがより多くのカスタムコードが必要です。ACM（D）はSSL証明書用です。

答え: B

解説: CodeBuildがVPC内で実行されると、デフォルトのインターネットアクセスが失われます。外部インターネットリソース（npmパッケージなど）にアクセスするには、VPCにパブリックサブネットのNATゲートウェイが必要で、CodeBuildサブネットのルートテーブルはインターネット向けトラフィックをNATゲートウェイ経由でルーティングする必要があります。CodeArtifact（npmのプロキシ）を使用することもこれを解決します。インターネットゲートウェイの追加（A）だけではプライベートサブネットからのトラフィックをルーティングしません。VPCの外への移動（C）はプライベートリソースへのアクセスを失います。

答え: B

解説: AWS Fault Injection Simulator（FIS）はAWSインフラに障害を注入する（EC2インスタンスの終了、ネットワーク遅延の追加、CPU負荷の発生、API呼び出しのスロットリングなど）制御された実験を実行できるマネージドカオスエンジニアリングサービスです。Systems Manager Automation（A）は運用タスクを実行します。CloudFormationドリフト検出（C）は設定ドリフトを検出します。DevOps Guru（D）はMLを使用して運用上の異常を検出します。

答え: A

解説: Amazon InspectorはAmazon ECRと統合してコンテナイメージのソフトウェア脆弱性（CVE）を自動的にスキャンします。新しいイメージがECRにプッシュされると、InspectorはそれをスキャンしてFindings を報告します。パイプラインはAPI呼び出しまたはEventBridge通知経由でInspector Findingsを確認し、重大な脆弱性が見つかった場合にビルドを失敗させることができます。WAF（B）はウェブアプリ保護用です。GuardDuty（C）は脅威検出用です。Security Hub（D）は調査結果を集約します。

答え: B

解説: コントラクトテスト（サービスが正しく通信し続けることを確認する）と組み合わせたサービスごとの独立したデプロイメントパイプラインにより、チームは調整なしに独立してデプロイできます。コントラクトテストはサービスインターフェースの互換性を検証します。すべてを一緒にデプロイすること（A）は密結合を作ります。フィーチャーフラグ（C）は機能の可視性を制御しますが独立したデプロイメントパイプラインを有効にしません。手動デプロイメント（D）はCI/CDの利点を排除します。

答え: C

解説: CloudFormation動的参照は{{resolve:ssm:/path/to/parameter}}構文を使用してSSMパラメータストアの値をテンプレートで直接参照できます。スタックがデプロイまたは更新されると、CloudFormationはSSMから現在の値を取得します。これにより常に最新の承認済みAMIが使用されます。AWS::SSM::Parameter（B）はSSMパラメータを作成するためでなく取得するためのものではありません。Lambdaカスタムリソース（D）は複雑さを追加します。ハードコーディング（A）は手動更新が必要です。

答え: B

解説: AWS AppConfigはデプロイ戦略を使用して段階的にデプロイできるフィーチャーフラグ設定をサポートします。アプリケーションは実行時にフィーチャーフラグを評価して特定のユーザーや割合の機能を有効にできます。Route 53加重ルーティング（A）はDNSレベルでルーティングしユーザーごとではありません。ALBルール（C）はリクエスト属性に基づいてルーティングしますがフィーチャーフラグ管理インターフェースを提供しません。Lambda@Edge（D）はカスタムコードが必要です。

答え: B

解説: EventBridge（以前のCloudWatchイベント）はCodePipelineのステージとパイプライン状態変化のイベントを発行します。EventBridgeルールはFAILED状態変化をフィルタリングし、Slack webhook APIを使用してSlackにメッセージを送るLambda関数をトリガーできます。これはイベント駆動型で効率的でポーリングが必要ありません。ポーリング（A）は非効率的です。CloudWatchアラーム（C）はパイプライン状態を直接監視しません。SNSと手動Slack転送（D）は自動化されていません。

答え: C

解説: ネストされたスタックが失敗すると、親スタックのイベントはネストされたスタックを参照する失敗を示します。イベントのネストされたスタック名をクリックするか直接ナビゲートすることで、失敗した特定のリソースとエラーメッセージを示すそのネストされたスタックのイベントを確認できます。親スタックのイベントの確認（A）は部分的な情報を提供します。すべてのネストされたスタックの確認（B）は非効率的です。CloudTrail（D）はAPI呼び出しを示しますがスタックレベルのリソース失敗は示しません。

答え: B

解説: デプロイステージの前にCodePipelineに専用の移行ステージを追加することで、移行が最初に実行されることを保証します。CodeBuildアクションはデータベースに接続して移行スクリプトを実行できます。移行が失敗するとパイプラインが停止し新しいアプリケーションコードはデプロイされず、バージョンの不一致を防ぎます。起動時の実行（A）は複数のインスタンスが同時に実行される問題を引き起こす可能性があります。手動移行（C）は自動化の利点を排除します。RDSバックアップ（D）はデータ復旧用です。

答え: B

解説: AWS ConfigはCodeBuildプロジェクトの設定を評価し、非準拠プロジェクト（例：承認されていないイメージを使用するプロジェクトやインラインビルドスペックを持つプロジェクト）にフラグを立てることができます。IAMポリシーはCodeBuildプロジェクト設定でどのイメージが許可されるかを制限できます。これにより検出（Config）と予防（IAM）の両方が提供されます。コードレビュー（A）と手動監査（D）は自動化されていません。Inspector（C）は設定コンプライアンスではなく脆弱性をスキャンします。

答え: C

解説: ロードバランサーデプロイメントのCodeDeploy AppSpecライフサイクルイベントには：BeforeBlockTraffic（ロードバランサーがインスタンスへのトラフィックをブロックする前）、BlockTraffic（ロードバランサーがトラフィックをブロック）、AfterBlockTraffic（トラフィックがブロックされた後）が含まれます。ロードバランサーがトラフィックをブロックする前に接続をドレインするには、BeforeBlockTrafficフックを使用します。BeforeInstall（A）はトラフィックが既にブロックされた後に実行されます。AfterInstall（B）はアプリケーションインストール後に実行されます。

答え: A

解説: CodeCommit（またはGitHub）の変更によってトリガーされるCodePipelineはCloudFormationのGitOpsを実装します。リポジトリへのすべてのコミットがパイプラインをトリガーしCloudFormationの変更を適用します。これにより展開されたインフラが常にリポジトリと一致することが保証されます。CDK Pipelines（D）もこれを実装しますがCDKアプリケーション専用です。手動変更（B）はGitOps原則に違反します。StackSets（C）はクロスアカウントデプロイメントを管理しますがトリガーが必要です。

答え: A

解説: CloudWatch Logs（アプリケーションログ）、CloudWatchメトリクス（インフラメトリクス）、X-Ray（分散トレース）はAWSの可観測性トリオを形成します。CloudWatch Container InsightsはECS固有のメトリクスとログを提供します。X-RayはトレースIDを使用してCloudWatchとトレースを相関させます。S3+Athena（B）はリアルタイム相関を提供しません。Elasticsearch+Kibana（C）はインフラの管理が必要です。CloudTrail（D）はアプリケーションの可観測性ではなくAPIの監査用です。

答え: B

解説: 各リージョン用の順次ステージを持つ単一のCodePipelineは必要なフローを実装します：us-east-1にデプロイし、ヘルスチェックを実行し（CodeBuildテストステージ）、ヘルスチェックが通過した場合のみeu-west-1にデプロイします。これにより自動化された順次デプロイとゲートが提供されます。2つの別々のパイプライン（A）は手動の調整が必要です。StackSets（C）はゲートなしに複数のリージョンに同時にデプロイします。手動デプロイメント（D）は自動化を排除します。

答え: B

解説: EC2 Auto Scalingインスタンスリフレッシュは新しい起動テンプレートを使用するインスタンスのローリング更新を可能にします。MinHealthyPercentageを設定してチェックポイントを設定することで、続行する前にインスタンスの割合でテストできます。ウォームプールは交換インスタンスを事前にウォームアップできます。起動設定（A）は非推奨です。手動終了（C）はエラーが発生しやすいです。新しいASGの作成（D）は既存のデプロイメントと統合されません。

答え: B

解説: アップ/ダウンスクリプトを持つ可逆的な移行により、デプロイ時に（アップ）移行を適用し、ロールバック時に（ダウン）移行を元に戻すことができます。デプロイが失敗した場合、パイプラインは自動的にダウン移行を実行できます。これはスナップショットからの復元よりも高速です。データベースダンプ（A）とスナップショット（D）は復元が遅いです。PITR（C）はさらに遅くスナップショット後の期間のデータを失う可能性があります。

答え: C

解説: Amazon InspectorはECRと統合してコンテナイメージの脆弱性（パッケージ内のCVE）とイメージレイヤーに誤って埋め込まれたシークレット（シークレット検出機能を使用）の両方をスキャンします。InspectorによるECR拡張スキャンは手動レビューなしに自動検出を提供します。マルチステージビルド（B）はイメージサイズを削減しますがシークレットを検出しません。手動レビュー（A、D）はスケーラブルではありません。

答え: B

解説: CodeDeployデプロイグループは自動ロールバックのためのCloudWatchアラームと、デプロイイベント（ロールバックを含む）発生時にSNS通知を送るトリガーで設定できます。これが自動ロールバックと通知の完全に統合されたネイティブな解決策です。CloudWatchメールアラーム（A）は通知しますがデプロイを停止/ロールバックしません。Lambda（C）はカスタムの複雑さを追加します。手動モニタリング（D）は自動化されていません。

答え: B

解説: AWS ConfigカスタムルールはすべてのLambda関数を評価し、予約済み同時実行が設定されていない非準拠のものを報告できます。Configは修復アクションをトリガーすることもできます。これにより手動確認なしに大規模での可視性が提供されます。手動設定（A）はスケールしません。Service Quotas（C）は合計アカウントの同時実行を制限しますが関数ごとの強制はしません。IAMポリシー（D）は作成時に設定属性の存在を要求できません。

答え: B

解説: Lambdaバックのカスタムリソースはスタックの作成/更新/削除操作中に任意のコードを実行できます。Lambda関数はサードパーティAPIを呼び出し、外部サービスを設定し、CloudFormationテンプレートにデータを返すことができます。cfn-init（A）はEC2インスタンスの設定用です。WaitCondition（C）はEC2インスタンスからのシグナルを待つためのものです。AWS::CloudFormation::Stack（D）はネストされたスタック用です。

答え: B

解説: ASGがELBヘルスチェックを使用するよう設定されている場合、ロードバランサーが（ALB/NLBターゲットグループのヘルスチェックに基づいて/healthのようなアプリケーションレベルのエンドポイントを確認する）不健全と報告するインスタンスを不健全と見なします。ASGはその後自動的に不健全なインスタンスを終了して置き換えます。EC2ステータスチェック（A）はEC2インフラの健全性のみを確認します。CloudWatchアラーム（C）はスケーリングポリシーをトリガーしますが直接の置換はしません。

答え: B

解説: 環境固有のパス（例：/dev/database/endpoint、/prod/database/endpoint）を持つSSMパラメータストアを使用することで、アプリケーションとパイプラインが実行時に環境固有の設定を取得できます。IAMポリシーで環境ごとのアクセスを制御できます。リポジトリへの設定保存（A）はシークレット漏洩のリスクがあります。ビルドアーティファクトへのハードコーディング（C）は環境ごとに異なるアーティファクトを作成します。異なるCodeBuildプロジェクト（D）は設定管理の問題に対処しません。

答え: A

解説: イミュータブルインフラはAMIパイプライン（新しいコードでゴールデンAMIをビルドしてベークするCodeBuild、その後新しいAMIでAuto Scalingグループをインスタンスリフレッシュ）を使用します。新しいインスタンスは新しいAMIから起動され、古いインスタンスは終了されます。インプレースデプロイメント（B）は既存のインスタンスを変更しイミュータブルの原則に違反します。SSMパッチ適用（C）は既存のインスタンスを変更します。手動更新（D）はエラーが発生しやすいです。

答え: B

解説: Amazon CloudWatchダッシュボードは複数のパイプラインにわたってCodePipeline実行メトリクスとステータスを集計できます。パイプラインからのEventBridgeイベントと組み合わせて、Lambda関数がパイプラインステータスのDynamoDBテーブルを更新し、CloudWatchダッシュボードが表示します。CloudWatchはパイプラインレベルのメトリクスも提供します。DevOps Guru（C）はMLを使用した異常検出でパイプラインダッシュボードではありません。Organizationsコンソール（D）はアカウントを管理しパイプラインは管理しません。

答え: B

解説: CodeBuildビルドがECRにイメージをプッシュした後、docker inspectまたはECR APIを使用してダイジェスト（SHA256ハッシュ）を含む完全なイメージURIを取得できます。このダイジェストURIはCodePipelineのCodeDeployアクションがECSタスク定義を更新するために使用するアーティファクトファイル（imagedefinitions.json）に書き込まれます。ダイジェストを使用することで、latestが指すものではなく正確なイメージがデプロイされることが保証されます。ECRタグの変更不可（C）はタグの上書きを防ぎますがダイジェストベースのデプロイメントを保証しません。

答え: B

解説: CloudFormationデプロイメント後、CodeBuildアクションはAWS CLIコマンドを実行してスタックによって作成されたリソースのAWS Configルールコンプライアンスを確認できます（aws configservice get-compliance-details-by-resource）。リソースがNON_COMPLIANTの場合、CodeBuildステージが失敗してパイプラインが停止します。手動レビュー（A）は自動化されていません。Inspector（C）は脆弱性をスキャンします。GuardDuty（D）は脅威検出用です。

答え: A

解説: AWS CloudFormation Guardはデプロイ前にCloudFormationテンプレートをカスタムルールに対して検証するポリシーアズコードツールです。CloudFormationフックはリソース作成前にGuardまたはLambda関数を呼び出して非準拠リソースをブロックできます。Configルール（B）は事後検出（デプロイ後）です。Security Hub（C）は調査結果を集約します。Trusted Advisor（D）は推奨事項を提供しますがデプロイを防止しません。

答え: D

解説: EC2 Auto Scalingの最大インスタンスライフタイム機能は指定された期間後にインスタンスを自動的に置き換えます。86400秒（24時間）に設定することで、起動テンプレートが更新された場合に新しいAMIを取得しながら24時間以内にすべてのインスタンスが置き換えられます。インスタンスリフレッシュをトリガーするEventBridge（A）はカスタム自動化が必要です。手動リフレッシュ（B）は自動化されていません。スポットインスタンス（C）は置き換えられる可能性がありますが24時間以内は保証されません。

答え: C

解説: git-secrets、truffleHog、またはGitleaksなどのツールはソースコードのハードコードされたシークレットと認証情報をスキャンするために設計されています。これらはCodeBuildビルドスペックにビルドステップとして統合できます。シークレットが見つかった場合、ビルドが失敗します。Amazon Inspector（A）はコンテナイメージとEC2インスタンスをスキャンします。Secrets Manager（B）はシークレットを保存しますがコードをスキャンしません。Macie（D）はソースコードではなくS3オブジェクトの機密データをスキャンします。

答え: B

解説: CodePipelineで各ECSサービスに対して別々の並列デプロイアクション（それぞれ独自のCodeDeployデプロイグループを持つ）を使用することで、デプロイが失敗した場合に個別のサービスロールバックが可能になります。1つのサービスのデプロイが失敗した場合、そのデプロイのみがロールバックされ、他のサービスは続行されます。単一のデプロイグループ（A）またはすべてのサービスの単一デプロイ（D）はすべてのサービスをロールバックします。順次CloudFormation（C）はCodeDeployのロールバック機能を活用しません。

答え: A

解説: AWS ConfigルールはMetadataOptions.HttpTokensがrequired（IMDSv2）に設定されていないEC2インスタンスを検出できます。非準拠インスタンスが見つかると、SSM Automationの修復ドキュメントはIMDSv2を要求するようにインスタンスメタデータオプションを自動的に更新できます。これにより検出と自動修復の両方が提供されます。Inspector（B）は脆弱性用です。手動監査（C）はスケーラブルではありません。CloudTrail（D）はAPI呼び出しをログに記録します。

答え: B

解説: AWS上のTerraformの推奨バックエンドはS3（状態履歴と復旧のためのバージョニング）とDynamoDB（同時状態変更を防ぐための状態ロック）の組み合わせです。これはAWS上での安全なTerraform状態管理の標準的で十分に文書化されたパターンです。ローカルファイルシステム（A）はチームコラボレーションやDRをサポートしません。CodeCommit（C）は状態ファイルのコミットが必要で推奨されません。CodeArtifact（D）はパッケージマネージャーです。

答え: B

解説: conftest付きのOPA（Open Policy Agent）またはKyvernoはCodeBuildステージでKubernetesマニフェストをポリシールール（rootユーザー以外の要求、リソース制限、読み取り専用ファイルシステムなど）に対して検証できます。ポリシーが失敗するとビルドが失敗しマニフェストがデプロイされません。これはシフトレフトセキュリティです。Inspector（C）は実行中のワークロードをスキャンします。GuardDuty（D）はランタイムの脅威を検出します。手動レビュー（A）はスケールしません。

答え: B

解説: ブレークグラスアクセスはAWS STSを介して限られた期間引き受けることができるIAMロールを使用します。アクセスは厳密に制御され（特定のユーザーがロールを引き受けることができる）、CloudTrailで監査され、時間制限されています（STSセッション時間）。ロールの引き受けはSNSアラートをトリガーできます。ルート認証情報の共有（A）は絶対に許容されません。恒久的な管理者ユーザー（C）は常に利用可能で「ブレークグラス」ではありません。SCPs（D）はOrganization管理者アクセスなしにはバイパスできません。

答え: B

解説: AWS CodeBuildテストレポートは複数のビルドにわたってテスト結果を集計するレポートグループを作成できます。CodeBuildはテスト結果ファイル（JUnit XML、Cucumber JSONなど）を解析し、CodeBuildコンソールで合否統計、トレンド、テスト時間を表示します。CloudWatch Logs（A）は生のログ出力を保存します。S3アーティファクト（C）はファイルを保存しますがテストトレンドを視覚化しません。X-Ray（D）は分散トレーシング用です。

答え: A

解説: Amazon RDSブルー/グリーンデプロイメントは本番データベース（ブルー）と同期されたステージング環境（グリーン）を作成する機能です。グリーン環境にスキーマ変更を適用し、テストし、最小のダウンタイムで切り替えを実行できます。RDSマルチAZ（B）は高可用性フェイルオーバー用です。リードレプリカ（C）は読み取り専用です。DMS（D）は異なるデータベースタイプ間の移行用です。

答え: B

解説: IAMポリシーは開発者がCodeDeployを直接呼び出したり、ECSサービスを更新したり、ECR/EKSにプッシュしたりする能力を拒否できます。CodePipelineは必要な権限を持つ専用のサービスロールを使用します。これによりデプロイメントはパイプラインを通じてのみ行えます。チームポリシー（A）は技術的に強制されません。VPN（C）とNACL（D）はネットワークアクセスを制御しますがデプロイメント権限は制御しません。

答え: B

解説: CodeBuildのビルド前ステップでスクリプトはgit diffを実行して最後の成功したビルド以降にどのディレクトリ（サービス）が変更されたかを識別できます。スクリプトはその後どの後続のビルド/デプロイステップが実行されるかを制御する環境変数や出力ファイルを設定できます。これはモノレポCI/CD最適化の一般的なパターンです。常にすべてをビルドすること（A）は時間とリソースを無駄にします。別々のリポジトリ（C）はアーキテクチャを大幅に変更します。Lambda検出（D）は複雑さを追加します。

答え: B

解説: ステージングデプロイ後のCodeBuildステージはLocust、k6、またはJMeterのような負荷テストツールを実行できます。テストスクリプトは負荷プロファイルとアサーション（P99レイテンシ < 200ms）を定義します。アサーションが失敗するとCodeBuildはゼロ以外の終了コードを返し、パイプラインステージを失敗させて本番への昇格を防ぎます。手動テスト（A）は自動化されていません。CloudWatchアラーム（C）は本番を監視しますがデプロイ前のステージングテストはしません。Trusted Advisor（D）はコスト/パフォーマンスの推奨事項を提供します。

答え: B

解説: 自動化された解決策：EventBridgeスケジュールルールがすべてのスタックのCloudFormationドリフト検出を開始するLambda関数をトリガーします。ドリフトが検出されると、LambdaはCodePipelineをトリガーしてCloudFormationスタックを再デプロイします（望ましい状態に戻す）。これは完全に自動化されています。手動確認（A）は継続的ではありません。Configルール（C）はドリフトを検出できますがCloudFormationスタックドリフトのために特別に設計されていません。ターミネーション保護（D）は削除を防ぎますがドリフトは防ぎません。

答え: B

解説: AWS AppConfigは動的設定デリバリーのために特別に設計されています。AppConfigエージェント（またはSDK）は設定変更をポーリングし、45秒ごとにチェックするよう設定でき、変更が60秒以内に有効になることを保証します。AppConfigはデプロイ戦略と検証もサポートします。ECS環境変数（A）はタスク再起動が必要です。SSMポーリング（C）は機能しますがAppConfigの検証とデプロイ戦略機能が欠けています。DynamoDB+Lambda（D）はカスタムコードとスケジューリングの遅れが必要です。

答え: C

解説: 最も包括的なアプローチ：（1）CloudFormationスタックタグはスタックが作成するリソースに自動的に伝播する、（2）CodePipelineはコミットIDとパイプライン名をタグとして使用するCloudFormationパラメータとして渡す、（3）AWS Organizationsタグポリシーはタグ標準を強制する。これはパイプラインソースでのタグ付け、CloudFormation経由の伝播、Organizationsを通じたガバナンスを処理します。手動タグ付け（A）はスケールしません。Lambda作成後タグ付け（D）はレースコンディションがあり一部のリソースを逃します。