birdpixyさんの助け合いフォーラム投稿一覧
DynamoDBの学習テキストに下記の記述がありました。
TTLによる削除の費用は発生せず、不要なデータを効率的に削除できるので、ストレージコストの最適化にもなります。
他人に質問する前に、学習テキストやAWS公式サイトを読んだり、AI Assistantに質問した方が速く解決できると思いますよ。
読み取りリクエストが「予測しにくい」とはいっても、設問では 「緩やかな増減」 と書かれています。
DynamoDB Auto Scalingは、プロビジョンドモードで読み取り/書き込みキャパシティ、またはその両方を自動調整できます。
つまり、書き込みは固定的にプロビジョニングし、読み取りだけAuto Scalingで追従させるという設計が可能です。
・緩やかな増減の場合：
Auto Scaling のスケーリング遅延（アラーム発火→反映まで数分）でも十分追従できる → プロビジョンド + Auto Scaling が有効
・突発的な増減がある場合：
Auto Scaling が間に合わずスロットリングが起きる → オンデマンドが有効
ポイントは設問の
データはオンプレミスからファイルベースのアプリケーションを使用して、低遅延でS3バケットへアクセスできる必要がある。
という要件にあります。
DataSyncの場合：
アプリケーションのアクセス先はオンプレミスのストレージであり、DataSyncはオンプレミスのストレージとS3バケットの間でデータを同期します。
オンプレミスアプリケーション
↓
オンプレストレージ
↓
（同期）
↓
S3バケット
DataSyncはデータ移行・同期サービスであり、アプリケーションからS3バケットへアクセスするための仕組みは提供しません。
Storage Gatewayの場合：
アプリケーションはStorage Gatewayが提供するファイル共有（NFS/SMB）を経由して、S3バケットにアクセスします。
オンプレミスアプリケーション
↓
（ファイルゲートウェイ）
↓
S3バケット
ファイルゲートウェイはローカルキャッシュを利用して低遅延アクセスを実現できるため、設問の要件と一致します。
SNSの暗号化はSNSが実行しますが、KMSの認可は「リクエストの主体（Lambda実行ロール）」も含めて評価されるため、Lambda側にもKMS権限が必要です。
SNSのサーバーサイド暗号化（SSE）では、メッセージがトピックに到達した時点で暗号化されます。
この暗号化処理の流れは以下のようになっています。
1.Lambda関数がSNSにパブリッシュする
2.SNSがメッセージを受け取る
3.SNSがKMSに対してデータキー生成を要求
4.データキーでメッセージを暗号化して保存する
3でKMSを呼び出すのはSNSですが、その呼び出しが許可されるかどうかは、SNSプリンシパルおよびパブリッシュを行ったプリンシパル（＝Lambda実行ロール）の両方の権限に基づいて判定されます。そのため、Lambda実行ロールにKMSカスタマーマネージドキーの利用を許可する権限が必要です。
https://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/emr-plan-file-systems.html
AWS公式にもS3AとHDFSを使用すると書いてありました。
Amazon EMR および Hadoop は通常、クラスターを処理するときに以下のうち少なくとも 2 つのファイルシステムを使用します。HDFS と S3A は、Amazon EMR で使用される 2 つの主なファイルシステムです。
EMR-7.10.0以降、EMRからS3への接続はEMRFSからS3Aがデフォルトになったようですので、教科書の情報が古いのだと思います。
https://docs.aws.amazon.com/ja_jp/emr/latest/ReleaseGuide/emr-s3a-migrate.html
問題文冒頭の「S3バケットに対して」が「特定のIAMユーザーからのみアクセスを許可したい場合」にかかっているのか、「定義する」にかかっているのかがわかりにくく感じました。
うーん、「S3バケットに対して」が「特定のIAMユーザーからのみアクセスを許可したい場合」にかかっていても「定義する」にかかっていてもどちらでも意味は通じるので、特に違和感はありませんでした。
ちなみに実際の試験は、合格体験記でもよく言われているように機械翻訳したような不自然な日本語なので、もっと分かりにくいですよ。
以下のドキュメントによるとDynamoDBはソースとして使用できるようなのですが、AWS SAA-CO3の範囲では、当サイトの回答解説のように考えるのが良いのでしょうか。
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/Welcome.html
下記の記述のことでしょうか？
DynamoDB などの NoSQL プラットフォーム、Amazon Simple Storage Service (Amazon S3) などの低コストの
ストレージプラットフォームにより提供されるマネージド データウェアハウスに移行できます。
「DynamoDBなどのNoSQLプラットフォーム（中略）により提供されるマネージドデータウェアハウスに移行できます」なので、ソースとして使用できるとは書いてないようです。
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Introduction.Sources.html
こちらのDMSのソース一覧にも記載がありません。
DynamoDBのクロスリージョンバックアップはAWS Backupの機能を使用するので、DynamoDB自体に備わっている機能ではないということではないでしょうか。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/backuprestore_HowItWorksAWS.html
DynamoDBに備わっているオンデマンドバックアップやポイントインタイムリカバリ（PITR）はどちらも同一リージョン内限定です。
マルチAZ DBクラスターの場合、スタンバイインスタンスがリードレプリカを兼ねているので、プライマリインスタンスに対して追加のリードレプリカを作成できます。
ただ、マルチAZ DBクラスターのリードレプリカ作成可能数までは書いていませんでした。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/multi-az-db-clusters-create-instance-read-replica.html
例えば悪意のある不正なドメインからのリクエストも受け付けてしまうなど…
ワイルドカードを使う対象が自ドメイン（アクセス先）なので、悪意のある不正なドメイン（アクセス元）からリクエストを受け付けることはないですが、自ドメインで公開を想定していないサブドメインへのアクセスが可能になるリスクはあります。
例えば「web1.example.com」「web2.example.com」を公開していたとして、「*.example.com」のカスタムレコードを作成した場合、「test.example.com」のようなテスト用のサブドメインなどにもアクセス可能になってしまうということです。
私個人の経験ですが、AWSにおける暗黙の了解みたいなもので本番用＝1年以上の長期運用という読み取りを要求されることはありますね。
一般的にも本番用だけど運用期間が数か月の方が例外だと思うので、そのようなシチュエーションのときは何らか補足があると思いますよ。
問題の参考URLに、Shield Advancedの保護対象が記載されてるAWS公式ページがありましたよ。
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/ddos-advanced-summary-protected-resources.html
ワイルドカードの有無と関係なく、API Gatewayで独自ドメイン（カスタムドメイン）名を作成できます。
https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/how-to-custom-domains.html#wildcard-custom-domain-names
逆にRoute 53は独自ドメイン名のDNSレコードを登録して名前解決をするサービスであり、作成はできないと思うのですが…。
そうですね、移行後のEC2やLambdaの費用と、オンプレのアプリやツールが稼働しているサーバーのランニングコストを天秤にかけたり、実はDirect Connectの契約費用で苦しんでいて、今すぐにでも解約したいという事情があるのかもしれないとか考えると、昼も眠れなくなってしまいますね。
設問の「インターネットからHTTP（80番ポート）でアクセスできるようにしたい」は「インターネット上のクライアント（ユーザー）からEC2上のWebサーバーにHTTPアクセスをしたい」と読めます。
つまり、以下のような一連の通信フローを成立させる必要があります：
[クライアント] → HTTPリクエスト → [EC2インスタンス]
[クライアント] ← HTTPレスポンス ← [EC2インスタンス]
上記の通信を許可するためには、インバウンド通信のHTTPリクエストを許可することで、アウトバウンド通信のHTTPレスポンスも許可されるセキュリティグループを使用するのが正解ということです。
実際にパーティションプレイスメントグループを作成しましたところ
手順1 パーティション数を指定してグループを作成する
手順2 EC2インスタンス作成時に所属するグループおよびパーティションを選択する
でしたので、②に近いと思います。