AWS DBS サンプル問題解説(備忘録)


以下のサンプル問題を解いてから閲覧することをお勧めします。

https://d1.awsstatic.com/ja_JP/training-and-certification/docs-database-specialty/AWS-Certified-Database-Specialty_Sample-Questions.pdf

AWSから出ているAWS DBSサンプル問題を解説している動画のまとめと、
本動画内で解説していない問題と各選択肢は自分なりの解説になりますので、
まちがってたらすみません。
※あくまで備忘録用です。

https://pages.awscloud.com/AWS_Certification_DB_jp_confirmation.html




#### 問題(1)
あるメディア企業が、マルチ AZ 配置の Amazon RDS for PostgreSQL を使用した基幹アプリケーションを本番運用しています。現在のデータベースサイズは 25 TB です。IT ディレクターは、最小限の作業量と業務中断時間で、このデータベースを Amazon Aurora PostgreSQL に移行したいと考えています。
これらの要件を満たすには、どの移行戦略が最適ですか。

A) [AWS Schema Conversion Tool (AWS SCT)](https://aws.amazon.com/jp/dms/schema-conversion-tool/)を使用して、RDS for PostgreSQL のデータベーススキーマを Aurora PostgreSQL データベースクラスターにコピーする。AWS DMS タスクを作成し、データをコピーする。

:::note alert
**→不正解。オンプレミスからの移行の際に使用されることが多い手法。
今回はクラウド内での移行、かつ、最小限の作業量と業務中断時間を考慮すると”×”になります。
異なるデータベース間で移行を行う際、まずSCTでテーブル定義などのメタデータやストアドプロシージャなどのコードを移行し、その後にDMSでデータ移行を行うというステップが定石らしいです。**
:::

https://frontse.hatenablog.jp/entry/2022/02/14/003230

https://pages.awscloud.com/rs/112-TZM-766/images/AWS-18_AWS_Summit_Online_2020_DAT01.pdf

B) pg_dump を使用するスクリプトを作成し、RDS for PostgreSQL インスタンスを常時バックアップする。pg_restore を使用して、バックアップデータを Aurora PostgreSQL データベースクラスターに復元する。

:::note alert
**→不正解。オンプレミスからの移行の際に使用されることが多い手法。
今回はクラウド内での移行、かつ、最小限の作業量と業務中断時間を考慮すると”×”になります。
。
下記の記事でAWS EBS スナップショットとの比較あり**
:::

https://qiita.com/masudakz/items/df4de728072f8434da4b

C) 本番用 RDS for PostgreSQL インスタンスのリードレプリカを作成する。レプリケーションのラグが 0 であることを確認し、リードレプリカをスタンドアロンの Aurora PostgreSQL データベースクラスターとして昇格させる。

:::note alert
**→不正解。この回答では、昇格の際にRDS for PostgreSQL インスタンスのリードレプリカから Aurora PostgreSQL データベースクラスターへデータベースエンジンを変更しています。
データベースクラスターとして昇格させる際に、データベースエンジンの変更はできないため”×”です。**
:::


D) 本番用 RDS for PostgreSQL インスタンスの Aurora レプリカを作成する。マスターへの書き込みを停止し、レプリケーションのラグが 0 であることを確認して、Aurora レプリカをスタンドアロンの Aurora PostgreSQL データベースクラスターとして昇格させる。

:::note info
**→正解。今回はRDS for PostgreSQLからAurora PostgreSQLへデータベースエンジンを移行したいので、RDS for PostgreSQLインスタンスのAurora レプリカを作成することにより、Aurora PostgreSQL データベースクラスターへ昇格させることが可能です。
注意点として、リード・Auroraレプリカは非同期処理のため、読み書きの量にもよるが同期のラグが発生することがあります。ラグが0ではない状態で昇格させてしまうと、同期されていないデータが消失する可能性があるため注意が必要ですが、この回答ではマスターの書き込みを停止することにより、ラグを発生させないようにしています。**
:::

AWSの回答）
>(1) D — Amazon RDS for PostgreSQL データベースインスタンスから Amazon Aurora PostgreSQL データベースクラスターに移行するには、移行元 PostgreSQL データベースインスタンスの Aurora レプリカを作成します。
PostgreSQL データベースインスタンスと Aurora PostgreSQL レプリカの間のラグが0 である場合、Aurora レプリカをスタンドアロンの Aurora PostgreSQL データベースクラスターとして昇格させることができます。


#### 問題(2)
ある医療企業が、オンプレミスの PostgreSQL データベースを、アプリケーションおよび Web サーバーと一緒に AWS に移行しようとしています。移行先データベースエンジンとして、Amazon RDS for PostgreSQL の使用を検討しています。また、VPC 内のアプリケーションサーバーおよび踏み台ホストにのみ、データベースへのアクセスを許可する必要があります。
これらのセキュリティ要件を満たすには、どうすればよいですか。

A) プライベートサブネットから成るデータベースサブネットグループ内で RDS for PostgreSQL データベースを起動する。アプリケーションサーバーおよび踏み台ホストからの接続だけを許可するよう、データベースインスタンス内の pg_hba.conf ファイルを修正する。

:::note alert
**→不正解。PostgreSQLでクライアント接続を行う際、接続したいIPアドレスをpg_hba.confファイルに書き込むことにより接続を許可することができます。
こちらの手法はRDS for PostgreSQL データベースでは不可能（厳密には、RDSがマネージドサービスでありOSに接続できないため、pg_hba.confファイルを編集することができない）なため、セキュリティグループを使わなければならないので”×”です。**
:::

https://qiita.com/yamamo-i/items/3699b651249ddb3ade27

B) パブリックサブネットから成るデータベースサブネットグループ内で RDS for PostgreSQL データベースを起動する。新しいセキュリティグループを作成し、アプリケーションサーバーおよび踏み台ホストが属するセキュリティグループからの接続だけを許可する受信ルールを適用する。この新しいセキュリティグループをデータベースインスタンスにアタッチする。

:::note alert
**→不正解。データベースをパブリックサブネット上で起動するのはセキュリティ的にNGのため”×”です。**
:::

C) プライベートサブネットから成るデータベースサブネットグループ内で RDS for PostgreSQL データベースを起動する。新しいセキュリティグループを作成し、アプリケーションサーバーおよび踏み台ホストが属するセキュリティグループからの接続だけを許可する受信ルールを適用する。この新しいセキュリティグループをデータベースインスタンスにアタッチする。

:::note info
**→正解。セキュリティグループはホワイトリスト方式なため、プライベートサブネット内でデータベースを起動し、アプリケーションサーバーおよび踏み台ホストが属するセキュリティグループからの接続だけを許可する受信ルールを適用することで、他からの通信は拒否でき、セキュリティの強化を図れるため”〇”です。**
:::

D) プライベートサブネットから成るデータベースサブネットグループ内で RDS for PostgreSQL データベースを起動する。NACL を作成し、VPC およびプライベートサブネットにアタッチする。アプリケーションサーバーおよび踏み台ホストとの接続だけを許可するよう、受信ルールおよび送信ルールを修正する。

:::note alert
**→不正解。特定の通信のみに限定したい場合はNCALを使用するのではなく、セキュリティグループで設定するのが一般的なため”×”です。**
:::

https://dev.classmethod.jp/articles/why-i-prefer-sg-to-nacl/

AWSの回答）

>(2) C — データベースインスタンスに対するセキュリティグループ内に、当該 Amazon EC2 インスタンスに対して作成したセキュリティグループからの接続だけを許可する カスタムルールを作成します。
これにより、このセキュリティグループに関連付けされているインスタンスだけがデータベースインスタンスにアクセスできます。VPC 環境内に踏み台ホストを配備した場合、プライベートサブネット内で動作しているデータベースインスタンスにセキュアに接続できます。

#### 問題(3) 
データベース専門家が、あるアプリケーションのユーザーからの苦情をトラブルシューティングしています。苦情の内容は、クラスターモードが無効化されている Amazon ElastiCache for Redis クラスターにデータを保存する際、パフォーマンスの問題が発生する、というものです。データベース専門家は、パフォーマンスの問題は、クラスターのバックアップ時間帯に発生することを突き止めました。このクラスターは、3 個のノードから成るレプリケーショングループ内で動作しています。各ノードのメモリ使用率が 100% に達しています。企業ポリシーにおいて、データベース専門家がバックアップ時間帯を変更することは禁じられています。
パフォーマンスの問題に対処するには、どうすればよいですか (2 つ選択してください)。

A) プライマリと同じアベイラビリティーゾーン内のクラスターにノードを追加する。

:::note alert
**→不正解。ノードの追加（スケールアウト）によりメモリ使用率の低下も見込めるが、今回はバックアップ時間帯にメモリ使用率が100%に達していることがわかっているので”×”です。**
:::


B) リードレプリカのスナップショットを作成するよう、バックアップジョブを構成する。

:::note info
**→正解。文中でバックアップ作成時（＝スナップショット作成時）にパフォーマンスの低下を突き止めたとの記述があるので、プライマリDBインスタンスのシステムリソースを使うスナップショットよりも、リードレプリカからスナップショットの作成に変更することにより、プライマリDBインスタンスのメモリ使用率の低下を見込めるため”〇”です。**
:::



C) 各クラスターノードのローカルインスタンスストレージサイズを増やす。

:::note alert
**→不正解。各クラスターノードのローカルインスタンスストレージサイズの変更（スケールアップ）により、メモリ使用率の低下も見込めるが、今回はバックアップ時間帯にメモリ使用率が100%に達していること＝バックアップに関するところが原因だとわかっているので”×”です。**
:::

D) [reserved-memory-percent](https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/backups.html) パラメーターの値を増やす。


:::note info
正解。バックアップ時に使用されるメモリは最大メモリ（maxmemory）の内、予約メモリ（reserved-memory-percent）としてあらかじめ確保することができ、この予約メモリの数値を引き上げることにより（AWSでは25%程度の確保を推奨）、バックアップ作成にさけるメモリが増え、パフォーマンスの問題が解消をされることを見込めるので”〇”です。
:::

>予約メモリとは、バックアップ（ElastiCacheでいうところのスナップショット）を取得する際に非同期でバックアップ用のプロセスを立ち上げるのですが、その時に使われるメモリです。パラメータグループを使用して値を調整できます（reserved-memory-percentというパラメータです）。0にすることも可能ですが、バックアップが正常に行われなかったりバックアップ中にレイテンシが発生してしまう可能性があることに注意してください。



https://dev.classmethod.jp/articles/elasticache-redis-memory-overflow/


E) バックアップデータ作成前にキャッシュをフラッシュするよう、バックアッププロセスを構成する。

:::note alert
**→不正解。今回はバックアップ作成時にメモリ使用率が100%になっていることがパフォーマンスの問題となっているので、キャッシュの削除ではメモリの解放は見込めないため”×”です。**
:::

AWSの回答）
>(3) B、D — バックアップ時にはシステムリソースが必要になるので、いずれかのリードレプリカからバックアップデータを作成することが推奨されます。すべてのノードのメモリ使用率が 100% である場合、ディスクに対する過度なページングが発生するおそれがあります。reserved-memory-percent パラメーターの値を 25% に設定し、バックグラウンドプロセス用のメモリスペースを十分に確保することが推奨されます。

#### 問題(4) 
ある企業のセキュリティ部門が、既存の Amazon RDS for MySQL データベースインスタンスにデータを格納する際、必ず暗号化するというルールを定めています。
この要件を満たすには、どうすればよいですか。

A) 暗号化を有効化するよう、データベースを修正する。予定されている次回のメンテナンス期間を待つことなく、この修正内容をただちに適用する。

:::note alert
**→不正解。新規のデータベースを作成する際は暗号化の設定が可能だが、既存のデータベースの暗号化設定を修正することをはできないため”×”です。**
:::

B) データベースを、暗号化を有効化した Amazon S3 バケットにエクスポートする。新しいデータベースを作成し、エクスポートファイルをインポートする。

:::note alert
**→不正解。データベース自体をS3にエクスポートすることはできないため”×”です。
データベースのスナップショットはS3へエクスポートでき、
テーブルデータはS3へエクスポート・S3からデータベースへインポートすることができます。
注意点として、S3にエクスポートされたデータベースのスナップショットはAthenaなどでの分析を目的となるため、データベースを新規作成するためのインポートはできません。**
:::

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ExportSnapshot.html

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PostgreSQL.S3Import.html#USER_PostgreSQL.S3Import.FileFormats

C) データベースのスナップショットを作成する。このスナップショットの暗号化されたコピーを作成する。暗号化されたスナップショットから新しいデータベースを作成する。

:::note info
**→正解。既存のデータベースを暗号化したい場合は、
既存のデータベースからスナップショットを作成し、作成されたスナップショットのコピーを作成・暗号化を設定することで、暗号化されたスナップショットを作成できます。この暗号化されたスナップショットを使用しようすることにより、既存のデータベースを暗号化された状態で新規に作成することができます。よって、”〇”になります。**
:::

>Amazon RDS DB インスタンスは、DB インスタンスの作成時にのみ暗号化できます。作成後には暗号化できません。
ただし、暗号化されていないスナップショットのコピーは暗号化できるので、暗号化されていない DB インスタンスに効果的に暗号化を追加できます。つまり、DB インスタンスのスナップショットを作成し、そのスナップショットの暗号化済みコピーを作成します。この暗号化されたスナップショットから DB インスタンスを復元することで、元の DB インスタンスの暗号化されたコピーを作成できます。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Overview.Encryption.html

D) データベースのスナップショットを作成する。このスナップショットを、暗号化を有効化した新しいデータベースに復元する。

:::note alert
**→不正解。スナップショットを作成するところまでは正解ですが、スナップショットの復元を行った場合、新規にデータベースが作成される仕様のため、新しいデータベースに復元することはできないので”×”です。**
:::

>DB スナップショットから既存の DB インスタンスに復元することはできません。復元すると新しい DB インスタンスが作成されます。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html

AWSの回答）
>(4) C — 暗号化されていない既存のデータベースインスタンスに対して格納データの暗号化を有効にするに
は、データベースインスタンスのスナップショットを作成し、そのスナップショットの暗号化されたコピー
を作成します。次に、暗号化されたスナップショットからデータベースインスタンスを復元します。これで
元のデータベースインスタンスの暗号化されたコピーが作成されます。

#### 問題(5) 
ある企業が、10 TB の高可用性 SQL Server リレーショナルデータベースを Amazon EC2 インスタンス上で本番運用しています。最近、ユーザーからパフォーマンスや接続に関する問題が報告されています。データベース専門家が、これらの問題をトラブルシューティングするための監視/アラート戦略を策定するように依頼されました。この戦略では、メトリクスを分析し、通知を発行する必要があります。
これらの要件を満たすには、どうすればよいですか。

A) 潜在的な問題の兆候を監視および検出するよう、AWS CloudTrail ログを構成する。特定の API が呼び出されたときにトリガされる AWS Lambda 関数を作成し、通知を Amazon SNS トピックに送信する。

:::note alert
**→不正解。AWS CloudTrailでは、マネジメントコンソールやCLIからのAPIの操作記録を検出します。したがって、EC2を作成、開始、停止などが検出されるのであって、起動したインスタンスのパフォーマンスを検出してくれるサービスではないため”×”です。**
:::

https://aws.amazon.com/jp/cloudtrail/features/


B) Amazon Inspector エージェントをデータベースインスタンスにインストールする。サーバーとデータベースのアクティビティを Amazon CloudWatch Logs にストリーミングするよう、エージェントを構成する。通知を Amazon SNS トピックに送信するよう、メトリクスフィルタとアラームを構成する。

:::note alert
**→不正解。Amazon Inspectorでは、EC2インスタンスの脆弱性などをのセキュリティ評価をしてくれるサービスのため、パフォーマンスや接続に関しては評価しないので”×”です。**
:::

https://aws.amazon.com/jp/inspector/features/?nc=sn&loc=2

C) データベースを Amazon RDS for SQL Server に移行し、Performance Insights を使用して潜在的な問題の兆候を監視および検出する。Performance Insights API からメトリクスを取得するAWS Lambda 関数を作成してスケジューリングし、通知を Amazon SNS トピックに送信する。

:::note alert
**→不正解。こちらの選択肢でも分析は可能ですが、通知を行う部分でLambda関数を実装し、Amazon SNSへ通知を送信する作業が必要なため、少し手間がかかります。Dの選択肢の方がより簡単に実現できるので”×”です。**
:::


D) 潜在的な問題の兆候を監視および検出するよう、Amazon CloudWatch Application Insights for .NET and SQL Server を構成する。通知を Amazon SNS トピックに送信するよう、CloudWatch Eventsを構成する。

:::note info
**→正解。SQL Serverや.NETベースのアプリケーション内部のメトリクスを分析して通知を発行したい場合は、Amazon CloudWatch Application Insights for .NET and SQL Serverを構成することが最も簡単に要件を達成できるため”〇”です。**
:::

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/appinsights-what-is.html


#### 問題(6) 
ある企業の e コマースアプリケーションにおいて、注文トランザクションを Amazon RDS for MySQL データベースに格納しています。このデータベースのストレージスペースがなくなったため、現在、アプリケーションで注文処理を実行できなくなっています。
この問題を最短時間で解決するには、どうすればよいですか。

A) ModifyDBInstance アクションを使用して、データベースインスタンスのストレージスペースを拡張する。

::: note info
**→正解。「現在、アプリケーションで注文処理を実行できなくなっています。この問題を最短時間で解決するには、どうすればよいですか。」ということなので、最も早く簡単に解決できる方法が望まれています。
B,Dでも解決が可能だが、Aが最も早く簡単に解決できるので”〇”です。**

**RDSのストレージはEBSと同じく作成後もつぎ足すことができるため、ストレージが足りないのであれば、単純にストレージを増やしてあげることで解決します。
ストレージの追加にはダウンタイムは発生しないため、CloudWatchで空き容量を監視し、ストレージの容量が足りなくなる前に予防的につぎ足すということが一般的です。
注意点として、ストレージ容量を足した後に減らすといったことはできないので、手動で増やす際は注意が必要です。**
:::

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting

B) ストレージスペースがより多いデータベースインスタンスを新規に作成し、最新のバックアップデータをロードする。

::: note alert
**→不正解。この手順でも実現可能ですが、Aよりも手順が多く、且つ、データのインポート時にダウンタイムが発生してしまう（ソースデータベースのサイズにもよる）ため、最短時間での解決は見込めないので”×”です。**
:::

https://repost.aws/ja/knowledge-center/rds-import-data

C) データベースインスタンスのステータスを STORAGE_FULL から AVAILABLE に変更する。

:::note alert
**→不正解。データベースのステータス自体を直接変更することはできません。仮に変更できたとしても、ステータスが変わっただけではストレージの空き容量が増える訳ではないので”×”です。**
:::

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/accessing-monitoring.html

D) ストレージスペースがより多いリードレプリカを構成する。

:::note alert
**→不正解。こちらの手順でも実現可能ですが、リードレプリカを作成する手間やストレージタイプの選定などが必要になります。Aの手段の方が最短かつ簡単なため今回は”×”です。**
:::


>デフォルトでは、ソース DB インスタンスと同じストレージタイプのリードレプリカが作成されます。ただし、次の表に示すオプションに基づいて、ソース DB インスタンスと別のストレージタイプを持つリードレプリカを作成することもできます。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Overview.replica-storage

#### 問題(7) 
ある企業がセキュリティ監査を受けた結果、複数のデータベース管理者が、この企業の Amazon Aurora 環境に対する管理者用データベースユーザーアカウントを共有していることがわかりました。トレーサビリティ、ガバナンス、およびコンプライアンスを確保するため、各データベース管理チームメンバーは今後、別々のアカウントを使用する必要があります。また、同じデータベースユーザー認証情報を長期間使用しないようにする必要があります。これらの要件を満たすには、どうすればよいですか。

A) AWS CLI を使用して、各チームメンバー用の AWS IAM ユーザー名およびパスワードを取得する。IAM ユーザーごとに Aurora ユーザーを作成し、IAM ユーザーと同じパスワードを設定する。

:::note alert
**→不正解。今回は「同じデータベースユーザー認証情報を長期間使用しないようにする必要があります。」とのことなので、Aの手段だとIAMユーザー用のパスワードを取得し、Auroraユーザーにも同じパスワードを手動で設定しているため、一定期間ごとにパスワードの変更が必要になります。よって、この要件を満たすことが難しいため”×”です。**
:::


B) Aurora クラスター上で IAM データベース認証を有効化する。チームメンバーごとにデータベースユーザーを作成する。パスワードは設定しない。データベースユーザーアカウントを使用して接続権限を付与する IAM ポリシーを、各管理者の IAM ユーザーアカウントにアタッチする。

C) チームメンバーごとにデータベースユーザーを作成する。新しいデータベースユーザー認証情報をチームメンバー間で共有する。初回ログイン時にパスワードを IAM ユーザーと同じパスワードに変更するよう、ユーザーに指示する。

:::note alert
**→不正解。今回は「各データベース管理チームメンバーは今後、別々のアカウントを使用する必要があります。」、かつ「同じデータベースユーザー認証情報を長期間使用しないようにする必要があります。」とのことなので、Cの手段だと、チームメンバーごとに新規に作成したデータベースユーザーを共有している時点で、要件にあっていません。尚且つIAMユーザーと同じパスワードを手動で設定するようユーザーに指示しているため、一定期間ごとにパスワードの変更が必要になります。よって、この要件を満たすことが難しいので”×”です。**
:::


D) IAM ロールを作成し、共有アカウントを使用して接続権限を付与する IAM ポリシーをアタッチする。管理者の IAM ユーザーアカウントがこのロールを代行できるよう、信頼ポリシーを構成する。

#### 問題(8) 
あるグローバル企業が、世界中のユーザーに対応するため、複数の AWS リージョンでアプリケーションを実行したいと考えています。このアプリケーションに対して、大量のデータを低レイテンシーで読み書きできるデータベースが必要です。データ量は時間の経過とともに変動する見込みです。また、全社レベルの動的なレポートを生成できるようにするため、データをすべてのリージョン間で共有する必要があります。
これらの要件を満たすには、どうすればよいですか。

A) Amazon Aurora Serverless を使用し、各リージョン内でエンドポイントを構成する。

:::note alert
**→不正解。Amazon Aurora ServerlessにはServerless v1とServerless v2が存在し、Serverless v1のエンドポイントはシングルAZでのみの構成に対応しており、Serverless v2のエンドポイントは複数AZでのみ構成することができます。別リージョンへの構成はServerless v2、かつAurora グローバルデータベースと組み合わせて使用する必要があるため”×”です。Serverless v2 グローバルデータベースは、災害対策用をも目的として他の AWS リージョン にクラスターの読み取り専用のコピーを追加で作成できます。**
:::

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html


B) Amazon RDS for MySQL を使用し、Auto Scaling グループ内のリードレプリカを各リージョンに展開する。

:::note alert
**→不正解。Amazon RDS for MySQLのリードレプリカは、同じリージョン内の各アベイラビリティゾーンの分散して配置する仕様です。なので、別のリージョンへ構成することはできません。各リージョンへリードレプリカを配置したい場合は、Amazon RDS for MySQL クロスリージョンリードレプリカを使用することになります。さらに、Auto Scalingグループはリージョンをまたぐことはできません。よって、この回答は”×”になります。**
:::

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.CrossRegionReadReplicas.html

C) Amazon DocumentDB (MongoDB 互換) を使用し、Auto Scaling グループ内のリードレプリカを各リージョン内で構成する。

:::note alert
**→不正解。Amazon DocumentDBのリードレプリカは、同じリージョン内の各アベイラビリティゾーンの分散して配置する仕様です。なので、別のリージョンへ構成することはできません。各リージョンへ読み取り専用のクラスターを配置したい場合は、Amazon DocumentDBグローバルクラスターを使用することになります。さらに、Auto Scalingグループはリージョンをまたぐことはできません。よって、この回答は”×”になります。**

:::

https://docs.aws.amazon.com/ja_jp/documentdb/latest/developerguide/global-clusters.get-started.html

D) Amazon DynamoDB グローバルテーブルを使用し、テーブルに対する DynamoDB 自動スケーリング機能を構成する。

:::note info
**→正解。Amazon DynamoDBは**
:::


>(8) D — Amazon DynamoDB グローバルテーブルを使用した場合、指定した複数の AWS リージョン内に複数のマスターデータベースを配置できます。DynamoDB では、これらのリージョン内に同一のテーブルを作成し、また、あるテーブル内のデータが変更されたときにその変更内容を他のすべてのテーブルにすぐに反映させるために必要なタスクがすべて実行されます。また、DynamoDB の自動スケーリング機能により、プロビジョニングされているスループットが、費用対効果の高い方法で、実際のトラフィックパターンに合わせて調整されます。

#### 問題(9) 
ある企業の顧客関係管理アプリケーションで、マルチ AZ 配置の Amazon RDS for PostgreSQL データベースを使用しています。データベースサイズは約 100 GB です。データベース専門家が、費用対効果の高いディザスタリカバリ計画を策定するよう求められています。このディザスタリカバリ計画の内容は、データベースを 2 時間以内に別のリージョン内に復元するというものです。また、復元後のデータベースにおいて、トランザクションデータが失われてもよい時間を 8 時間以内に抑える必要があります。
最も費用対効果の高い方法でこれらの可用性要件を満たすには、どうすればよいですか。

A) RDS のリードレプリカを第 2 リージョン内に作成する。ディザスタリカバリ時、このリードレプリカをスタンドアロンインスタンスに昇格させる。

B) RDS のリードレプリカを第 2 リージョン内に作成する。その際、インスタンスサイズを元のデータベースよりも小さくする。ディザスタリカバリ時、このリードレプリカをスケーリングし、また、スタンドアロンインスタンスに昇格させる。

C) データベースインスタンスのスナップショットを 1 時間ごとに作成する AWS Lambda 関数を作成し、スケジューリングする。そのスナップショットを第 2 リージョンにコピーする Lambda 関数を別途作成し、スケジューリングする。ディザスタリカバリ時、最新のスナップショットからマルチAZ 配置の新しい RDS データベースインスタンスを作成する。

D) マルチ AZ 配置の新しい RDS データベースインスタンスを第 2 リージョンに作成する。継続的にレプリケートするよう、AWS DMS タスクを構成する。

#### 問題(10) 
ある大企業の運用チームが、複数アカウントにまたがる開発チームのために、リソースのプロビジョニングを集中管理したいと考えています。新しい AWS アカウントが作成された場合、開発者は、本番用Amazon RDS for MySQL インスタンスと同じ構成、データスキーマ、およびソースデータを使用するデータベース環境に対する、フルアクセス権限を必要とします。
この要件を満たすには、どうすればよいですか。

A) 開発チームがスナップショットを作成できるようにするため、ソースデータベースインスタンスを新しいアカウントと共有できるようにする。スナップショットから新しいデータベースインスタンスを起動するための、AWS CloudFormation テンプレートを作成する。

B) 新しいアカウント内で承認済みデータベースインスタンス構成を起動するための AWS CLI スクリプトを作成する。ソースデータベースインスタンス内のデータを新しいデータベースインスタンスにコピーするための、AWS DMS タスクを作成する。

C) ソースデータベースインスタンスのスナップショットを手動で作成し、そのスナップショットを新しいアカウントとプライベートで共有する。AWS CloudFormation テンプレートの RDS リソース内でスナップショット ARN を指定し、StackSets を使用して新しいアカウントに展開する。

D) ソースデータベースインスタンスのリードレプリカを作成する。そのリードレプリカを新しい AWS アカウントと共有する。