AWS Certified DevOps Engineer – Professional 1-10

AWS CodeDeployによるLambdaデプロイでは、AppSpecファイルのフックを使ってライフサイクルの各段階で検証処理を実行できます。
BeforeAllowTrafficフックは新バージョンへトラフィックを切り替える直前に実行されるため、データベース変更の反映完了を待つ検証処理を組み込むのに最適です。
これによりトラフィック切替前に依存関係の準備を保証でき、断続的な障害を防げます。
AfterAllowTrafficは切替後に実行されるため障害の回避にはつながりません。
validateServiceはEC2・オンプレミス向けのフックであり、Lambdaデプロイでは使用できません。
Cはデプロイ前を対象としており、トラフィック制御とは結び付きません。
Lambdaで使えるフックはBeforeAllowTrafficとAfterAllowTrafficのみである点を押さえておきましょう。
AWS CodeDeploy AppSpec の hooks セクション

EC2・オンプレミス向けCodeDeployのライフサイクルフックの実行順序を問う設問です。
ブルー/グリーンデプロイでは、置換インスタンスが起動してトラフィックを受け取る前に、アプリケーションのインストール処理が行われます。
BeforeInstallフックは新しいアプリケーションバージョンがインストールされる前に実行されるため、ライセンスファイルのダウンロードとインストールを行う位置として最適です。
AfterBlockTrafficとBeforeBlockTrafficは、既存インスタンスからトラフィックを切り離す前後に実行されるフックであり、今回の目的には合いません。
DownloadBundleはCodeDeployエージェントが管理する予約済みイベントで、ユーザースクリプトを指定できません。
フックの実行順序を正確に押さえることが試験対策の要点です。
AWS CodeDeploy AppSpec の hooks セクション

最小の運用負荷で、VPCに接続されたLambda関数のみを許可する要件です。
サービスコントロールポリシー（SCP）でlambda:VpcIdsに対しNull条件を設定し、VPC未接続の場合にLambdaの作成を拒否すれば、全メンバーアカウントへ自動かつ予防的に強制でき、手動修復が不要になります。
AWS Configのカスタムルールは検出型であり、非準拠リソースの作成自体は防げず、後追いの修復が必要になります。
Control TowerのプロアクティブコントロールはCloudFormation Hooksの構築が必要で運用負荷が高くなります。
許可値を指定する方式もありますが、Null判定による一律拒否のほうが単純で確実です。
予防的ガバナンスにはSCPが有効である点を押さえましょう。
サービスコントロールポリシー（SCP）

バージョン管理・レビュー・ロールバック・承認統制を備えつつ、最小の運用負荷でControl Towerのガードレールを自動化する要件です。
各ガードレールをAWS::ControlTower::EnableControlリソースとしてCloudFormationテンプレート化し、CodeConnections互換のGitリポジトリで管理すれば、バージョン管理・変更レビュー・ロールバックを標準のGitワークフローで実現できます。
OU単位でEnableControlの対象を指定すれば、そのOU配下の全アカウントへ一貫して適用できます。
さらにEventBridgeでリポジトリへのマージを検知してCodePipelineを起動すれば、承認済みの変更だけが自動デプロイされます。
パイプラインと承認フローを欠く案や、手動起動かつアカウント単位の設定を行う案は負荷が高くなります。
S3を情報源とする案はGitのようなバージョン管理・承認の仕組みがありません。
GitOps型の構成が最も効率的です。
AWS Control Tower のコントロール（ガードレール）について

アプリケーションログとAWSアカウントのAPIアクティビティの両方をクエリしたいという要件です。
CloudWatchエージェントはログをCloudWatch Logsへ送信でき、CloudTrailもAPIログをCloudWatch Logsへ配信できるため、両方をCloudWatch Logs Insightsで横断的にクエリできます。
CloudWatchエージェントはS3へ直接ログを送れないため、エージェントから直接S3へ送る構成は成立しません。
Kinesis経由でRedshiftへロードする構成はデータを一旦経由させる必要があり、運用負荷が高くなります。
ログの集約先をCloudWatch Logsに統一し、Logs Insightsで分析するのが最小構成の定番パターンです。
CloudWatch Logs Insights によるログデータの分析

メンテナンス中もできるだけ中断を抑えて、Auroraクラスターの可用性を維持したいという要件です。
マルチAZを有効化し、スタンバイ（リーダー）インスタンスを別のアベイラビリティーゾーンへ配置すれば、メンテナンス時のフェイルオーバーによって中断を最小化できます。
書き込みはクラスターエンドポイント（プライマリ）へ、読み取りはリーダーエンドポイントへ振り分けます。
単一インスタンス構成のままではメンテナンス中に停止が発生します。
カスタムANYエンドポイントで読み書きを混在させる構成は、書き込みがプライマリに限定されるAuroraの特性に照らして適切ではありません。
可用性向上には、レプリカ追加による冗長化が要点です。
Amazon Aurora の高可用性

KMSキーが90日間ローテーションされていない場合に通知したいという要件です。
AWS Configのカスタムルールでキーの最終ローテーションからの経過日数を評価し、90日を超えたらAmazon SNSトピックへ発行すれば、継続的なコンプライアンス監視と通知を実現できます。
KMS自体には、経過日数に基づいてSNSへ通知する機能はありません。
Trusted Advisorはキーのローテーション期限を評価する項目を提供しません。
Security Hubは集約的なセキュリティ検出には有用ですが、任意の90日ローテーション判定を直接行うものではありません。
独自要件の継続的評価にはAWS Configのカスタムルールが適する点を押さえましょう。
AWS Config ルールによるリソースの評価

WindowsにはSMB、LinuxにはNFSを提供し、全インスタンスが読み書きする、耐久性のある共有ストレージが求められています。
Amazon FSx for NetApp ONTAPのマルチAZ構成は、SMBとNFSの両プロトコルに対応し、サブミリ秒の低レイテンシーと高可用性を提供します。
Linux向けにはマルチAZのマウントターゲットを持つAmazon EFSを併用し、NFSでの同時アクセスと耐久性を確保します。
各アプリケーションの起動テンプレートのユーザーデータを更新すれば、Auto Scalingで起動する新規インスタンスが自動的にファイルシステムをマウントします。
gp3のEBSは複数インスタンスからの共有ファイルアクセスには適しません。
インスタンスリフレッシュや個別のマウント更新は、本要件の自動化には必須ではありません。
用途に応じた共有ファイルストレージの選定基準を押さえましょう。
Amazon FSx for NetApp ONTAP とは

組織全体でS3の機密情報を検出し、検出結果を一元集約したうえで該当オブジェクトを隔離する、最小運用負荷の要件です。
組織レベルでAmazon Macieを有効化すると、全アカウント・全リージョンのS3を自動スキャンし、機械学習でPIIなどの機密データを検出できます。
Macieの検出結果をAWS Security Hubへ集約すれば、セキュリティ責任者が単一のダッシュボードで確認できます。
さらにEventBridgeルールでMacieの検出をトリガーにLambdaを起動し、対象オブジェクトを隔離用S3バケットへコピーして元を削除すれば、修復まで自動化できます。
独自の検出ロジックを組む案は複雑になり、SCPではデータの検査や移動はできず不適切です。
MacieとSecurity Hub、EventBridge連携の定番構成を押さえましょう。
Amazon Macie とは

プライベートサブネットのEC2をALBの背後で運用しつつ、IPv6クライアントのリクエストを受け付けたいという要件です。
VPCとALB用サブネットにIPv6 CIDRブロックを追加し、ALBのIPアドレスタイプをdualstackに指定すれば、ALBはIPv4とIPv6の両方でリクエストを受け付け、ターゲットグループ経由でEC2へ転送できます。
ALBはIPv6終端をサポートし、バックエンドへはIPv4で転送するため、EC2自体にIPv6を割り当てる必要はありません。
ALBにElastic IPを割り当てることはできません。
NLBへの置き換えは要件上不要で、ALBのdualstack対応で十分です。
ロードバランサーのdualstack設定によるIPv6対応が要点です。
Application Load Balancer について