birdpixyさんの助け合いフォーラム投稿一覧
以下のドキュメントによると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インスタンス作成時に所属するグループおよびパーティションを選択する
でしたので、②に近いと思います。
データベースのパスワードを暗号化してLambda関数に格納する方法は、AWS公式でも提示されているので、試験にも出る可能性があると思います。
https://aws.amazon.com/jp/lambda/faqs/
Q: 機密情報を環境変数に格納できますか?
データベースのパスワードなどの機密情報については、AWS Key Management Service を使用してクライアント側で暗号化し、
この暗号化した値を環境変数に暗号文として格納することをお勧めします。
これらの値の復号化では、AWS Lambda 関数コードにロジックを含める必要があります
継続してだと処理中のデータを引き継ぐイメージをする人が多いのではないでしょうか
解説に、SQSキューで処理中のデータを引き継ぐと書かれてあります。
スポットインスタンスは利用中にインスタンスが中断する可能性がありますが、Amazon SQSキューでリクエストを中継しているので、
万が一処理中にインスタンスが中断してもSQSキューに保持されているメッセージは失われず、別のインスタンスで処理を再開できます。
・問題の要件では「コスト最適化」や「効率の良い実装」「効率の良い運用」などは求められていない。
要件として明記されていないとしても、AWSが出題する試験である以上、AWS Well-Architectedフレームワークに準拠したソリューションが求められているはずです。
・一方で、リクエストの処理時間は記載されておらずLambdaの処理時間(15分)で処理しきれるかは不明
上記のことから、LambdaではなくFargateの方が適切かと考えたのですがこの考えの誤っているところはどこでしょうか。
誤答解説にもある通りFargateだとコンテナ化する手間が発生します。
処理時間の記載はありませんが、リクエストが大量に発生する可能性があるWebアプリケーションの処理時間が15分を超えるとはあまり考えられにくいです。
メタ的なことを言ってしまえば、処理時間が15分以上だからLambdaが誤りである問題の場合は要件に処理時間が15分以上と書いてありますし、Fargateが正解である問題の場合は大抵要件にコンテナと書いてあります。
ありとあらゆる想定をすることは実務ではリスク管理の点で有効ですが、処理時間が書いてないからLambdaが誤りという免許の学科試験のような引っ掛け問題の可能性を考えていると試験時間が足りなくなる恐れがあります…
パーティションプレイスメントグループは、同じリージョン内の複数のアベイラビリティーゾーンにパーティションを持つことができます。パーティションプレイスメントグループは、アベイラビリティーゾーンごとに最大 7 つのパーティションを持つことができます。
パーティションプレイスメントグループは単一のAZ内に制約されることは書いてありません。
実際、パーティションプレイスメントグループを作成して、同一グループに次のインスタンスを起動してみたところ
・サーバーA ap-northeast-1a partition1
・サーバーB ap-northeast-1c partition2
同一のパーティションプレイスメントグループ内でも、複数のAZに跨ってインスタンスを起動できました。
そこで、ふと思い立って、
・サーバーC ap-northeast-1a partition2
でインスタンスを起動してみたところ、何と正常に起動できてしまったのですね。
よくよく上記サイトの文章を読んでみたら、「プレイスメントグループ内のパーティションどうしが同じラックを共有することはありません」とは書いてあっても、パーティションは1つのラックに紐づいているとは書いてないわけです。
つまり、パーティション自体も複数のラックにまたがる可能性があり、そのラックは別のAZでもOK（ただしグループ内のパーティション同士はラックを共有しない）ということですね。（その点では該当の問題の解説に誤りがありますね）
プレイスメントグループは奥が深いですね。
お陰様でプレイスメントグループの知見を深めることができました。
「Budgets SCP」でGoogle検索したらトップに出てきましたよ。
https://docs.aws.amazon.com/ja_jp/cost-management/latest/userguide/budgets-controls.html
AWS Budgets を使用して、予算が特定のコストまたは使用量のしきい値を超えたときに、ユーザーに代わってアクションを実行できます。これを行うには、しきい値を設定した後、自動的に実行するか、手動承認後に実行するように予算アクションを設定します。
使用可能なアクションには、IAM ポリシーまたはサービスコントロールポリシー (SCP) の適用が含まれます。また、アカウント内の特定の Amazon EC2 または Amazon RDS インスタンスのターゲット設定も含まれます。予算期間中に新しいリソースをプロビジョニングする必要がないように、SCPs を使用できます。`
ご提示のサイトの「タスク定義の中で指定できるパラメータ」にある
・タスクで使用される IAMロール
が「他のAWSサービスへアクセスするための権限」に該当するのではないでしょうか？
AWSマネージメントコンソールでAWSアカウントの設定を見ても、パスワードの変更のみでパスワードポリシーの設定が見つからなかったのですが、どちらにありましたか？
AWSドキュメントのAWSアカウント（ルートユーザー）のページにもパスワードポリシーを設定できるような記載はなかったです。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_root-user.html
既存の環境からテンプレートを作成できるツールがあるみたいです。
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/generate-IaC.html
この記事ですね。
https://aws.amazon.com/jp/blogs/news/migration-from-amazon-qldb/
AWS試験の内容はAWSアップデートと同時に更新されるわけではないらしく、過去に私が受けたときはS3 Glacierのアップデートから半年以上経過していたにも関わらず旧S3 Glacierについての問題があったので、もしかしたらQLDBもしばらく出題範囲に入っているかもしれないですね。
一方、AI Assistantで確認したところでは、S3への接続にPrivateLinkは使用できないので
ゲートウェイ型のVPCエンドポイントの利用が必須であるとの情報が返ってきました。
AI Assistantの情報に疑問があるようでしたら、AWS公式を確認するのが一番だと思います。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/privatelink-interface-endpoints.html