AWS Certified Developer – Associate 1-10

sam sync –watch はAWS SAM Accelerateを有効化し、ローカルの変更を検知して差分のあるリソースのみを高速に反映します。
–watchフラグによりソースコードの変更が自動的に監視され、Lambda関数など変更されたリソースだけがクラウドへ同期されるため、全成果物の再ビルドと完全な再デプロイを回避できます。
sam deploy –force-upload（A）は全成果物を強制的にアップロードするため逆効果です。
sam deploy –no-execute-changeset（B）はチェンジセットを作成するだけで実行しません。
sam package（C）は成果物をパッケージ化するのみでデプロイも差分同期も行いません。
開発中の反復的な更新を高速化する用途にはsam syncが最適です。
AWS SAM CLI sam sync コマンドリファレンス

S3イベント通知はオブジェクト作成の直後にLambda関数を呼び出すため、最も低いレイテンシーを実現します。
アプリケーションは1日約10回、1回あたり約1分しか実行されないため、アイドル時にも課金が発生するEC2よりも、実行時間分だけ課金されるLambdaが大幅に低コストです。
CloudWatchアラーム（A）はメトリクスのしきい値監視向けであり、オブジェクトアップロードの即時トリガーには適しません。
スケジュールイベント（C）は決まった間隔でしか起動しないため、データ到着から実行までに遅延が生じます。
EC2ポーリング（D）は常時稼働のコストとポーリング間隔による遅延の両面で不利です。
Amazon S3でAWS Lambdaを使用する

Lambda関数がダウンストリームのデータベース（DocumentDB）を呼び出す構成で、どこに時間が費やされているかを最小の手間で突き止めるには分散トレースが最適です。
AWS X-Rayはリクエストのエンドツーエンドのトレースとタイミングの内訳を提供し、遅延がLambdaの初期化・ダウンストリーム呼び出し・データベースクエリのどこに起因するかを可視化します。
DocumentDB操作の周囲にカスタムサブセグメントを追加すれば、クエリ実行や接続取得ごとの正確な所要時間を計測でき、遅いクエリを迅速に特定できます。
Bはエラーと汎用メトリクス中心で、増加した20秒超の原因経路を正確に切り分けられません。
Cは根本原因を確認する前の性能改善策であり、まず特定するという要件に合いません。
Dは詳細なログ実装とクエリが必要で、開発工数とログコストの両面でオーバーヘッドが大きくなります。
AWS LambdaでのAWS X-Rayの使用

これはAWS STSのAssumeRoleを用いたクロスアカウントアクセスの典型パターンです。
アカウントAはロール側の信頼ポリシーでアカウントBを許可していますが、それだけでは不十分で、呼び出し側であるアカウントBのEC2ロールにも sts:AssumeRole を実行する権限が必要です（A）。
さらにアプリケーションは実際に一時認証情報を取得するため、コード内でAssumeRole APIを呼び出す必要があります（D）。
Bは、アカウントA所有のテーブルにアカウントB側で直接権限を付与しても効果がないため誤りです。
Cは、EC2ロールの認証情報を得るだけではアカウントAの権限は得られず、クロスアカウントロールの引き受けが必須です。
EのGetSessionTokenはIAMユーザーのMFAセッション用であり、クロスアカウントのロール引き受けには使いません。
AWS STS AssumeRole APIリファレンス

拠点IDをパーティションキー、タイムスタンプをソートキーとする複合キーのDynamoDBテーブルは、時系列の使用量データを低レイテンシーかつ高スループットで書き込み・取得でき、需要増に対してシームレスにスケールします。
DynamoDBはサーバーレスで書き込み時のダウンタイムがなく、高頻度な書き込みと拠点単位の範囲クエリの両立に適しています。
RDS（A）は書き込みスケールに上限があり運用負荷とコストが増します。
ElastiCache for Redis（C）はインメモリのため耐久保存に向かず長期の履歴保持にはコスト高です。
S3＋Athena（D）は安価ですがクエリごとにスキャンが走り、現在使用量への低レイテンシーなオンデマンドアクセスには不向きです。
DynamoDBでのクエリの操作

HTTP/HTTPSリスナーを使う場合、レイヤー7で動作するApplication Load Balancerが元のクライアントIPをX-Forwarded-Forヘッダーに付加して転送するため、アプリケーションはこのヘッダーからクライアントIPを取得できます。
ALBはHTTP/HTTPSトラフィックを終端し、X-Forwarded-For、X-Forwarded-Proto、X-Forwarded-Portといったヘッダーを標準で挿入します。
NLBのプロキシプロトコル（B）はレイヤー4のTCP接続向けの仕組みで、HTTP/HTTPSヘッダーによるクライアントIP取得の要件には合致しません。
CのインスタンスID登録はターゲット登録方式の話でクライアントIP取得とは無関係です。
NLBはX-Forwarded-Forヘッダーを付与しない（D）ため誤りです。
Application Load Balancerのx-forwarded-forヘッダー

API Gatewayのエッジ最適化エンドポイントはAmazon CloudFrontのグローバルなエッジネットワークを自動的に利用し、世界中に分散した利用者のレイテンシーを最小化します。
ACMにインポートしたTLS証明書をカスタムドメイン名に関連付ければ、任意のドメインで安全な接続を提供できます。
既定のエンドポイントを無効化することで、カスタムドメイン経由のアクセスのみを強制できます。
A・DのようにCloudFrontを別途構築しLambda@EdgeやCloudFront Functionsで処理する方式は、エッジ最適化API Gatewayが標準で備える機能を重複させるだけで不要です。
BのプライベートエンドポイントはVPC内部からの利用向けで、グローバルかつ低レイテンシーという要件を満たしません。
Amazon API Gatewayのカスタムドメイン名

S3イベント通知でLambda関数を呼び出す構成にすれば、新しいファイルがバケットに追加された時点で即座にDynamoDBへレコードを挿入でき、サーバーの管理も不要です。
S3のオブジェクト作成イベントがトリガーとなるため、追加とほぼ同時に処理が走ります。
EventBridge（A）でも実現は可能ですが、選択肢の説明は具体的な処理手段が曖昧で、S3イベント→Lambdaが最も直接的かつ標準的な方法です。
Lambdaによるポーリング（C）は継続的なポーリングコストと遅延が生じます。
cronジョブ（D）はスケジュール実行のため「追加されるとすぐに」という即時性の要件を満たしません。
チュートリアル：Amazon S3トリガーを使用してLambda関数を呼び出す

要件は、転送中の暗号化と、オンデマンドでローテーション可能なKMSキーによる保管時暗号化の2点です。
保管時暗号化は、AWS KMSカスタマー管理キーでオブジェクトを暗号化することで満たせます（C）。カスタマー管理キーはオンデマンドでのローテーションが可能です。
転送中の暗号化は、バケットポリシーでaws:SecureTransport条件を使いHTTPS接続のみを許可することで強制できます（D）。これはAWSが推奨する標準的な方法です。
Aのアクセス許可境界はIAMポリシーの制御用でバケットポリシーの転送暗号化強制には使えません。
BはS3バケットポリシーでクライアント側暗号化を強制することはできず誤りです。
Eのブロックパブリックアクセスは公開防止のための機能で暗号化の強制とは無関係です。
AWS KMSキーによるサーバー側暗号化の使用

AWS Secrets Managerは認証情報をAWS KMSで保管時に暗号化し、RDS・DocumentDB・Auroraに対応したローテーション用テンプレート（SecretsManagerRotationTemplate）でスケジュールに基づく自動ローテーションを実現します。
これにより、暗号化とローテーションという要件を最も安全かつマネージドに満たせます。
AのIAMデータベース認証はすべてのエンジンで利用できるとは限らず、要件の認証情報ローテーションとは目的が異なります。
BのParameter Store（SecureString）は保管時暗号化はできますが、シークレットの自動ローテーション機能を標準では備えていません。
CのS3保存は暗号化キーのローテーションであって認証情報自体のローテーションではなく、アクセス管理も煩雑になります。
AWS Secrets Managerシークレットのローテーション