AWS データベーススペシャリティ (DBS-C01) 模擬試験 65問

A) RDS MySQL Multi-AZ B) Aurora MySQL (Multi-AZクラスター) C) DynamoDB D) RDS PostgreSQL

答え: B

解説: Aurora MySQLはRDS MySQLと比較して最大5倍の性能を提供し、クラスターボリュームが10GBから128TBまで自動拡張します。Multi-AZクラスターは3つのAZにレプリカを維持して高可用性を保証します。高性能OLTPワークロードに最適です。

A) 24時間一定の大量トランザクション処理 B) トラフィックが不規則で予測不可能で、使用量に応じて課金したい場合 C) オンプレミスのOracleデータベースを移行する D) 分析用データウェアハウス

答え: B

解説: Aurora Serverless v2は0.5 ACU（Aurora Capacity Unit）から最大128 ACUまで秒単位で自動スケーリングします。開発・テスト環境、断続的なトラフィック、深夜にトラフィックがほぼないSaaSアプリケーションに最適です。使用した容量に対してのみ課金されます。

A) 各エンティティを別々のテーブルに分離する B) パーティションキーにエンティティタイプのプレフィックスを追加し、ソートキーで階層構造を表現する C) すべての属性を1つのJSON列に保存する D) 各エンティティごとにGSIを作成する

答え: B

解説: DynamoDBのシングルテーブル設計では、パーティションキー（PK）にUSER#UserIDやORDER#OrderIDのようなエンティティタイプのプレフィックスを追加します。ソートキー（SK）はPROFILE、ORDER#OrderID、ITEM#ItemIDなどで階層構造を表現します。これにより1つのテーブルで様々なアクセスパターンを効率的に処理できます。

A) Cluster Mode Enabledは単一ノードのみサポート B) Cluster Mode Enabledはデータを複数のシャードに分散し、より大きなメモリ容量と書き込みスループットをサポート C) Cluster Mode Disabledの方が読み取りパフォーマンスが優れている D) Cluster Mode EnabledはMulti-AZをサポートしない

答え: B

解説: ElastiCache Redis Cluster Mode Enabledはデータを複数のシャード（各シャードはプライマリノード+レプリカ）に分散します。1つのクラスターが処理できる総メモリと書き込みスループットをシャード数に比例してスケールできます。Cluster Mode Disabledは単一シャード（1つのプライマリ+読み取りレプリカ）で読み取りのみスケール可能です。

A) 毎秒数万件の金融トランザクション処理 B) ソーシャルネットワークのフレンド推薦または不正検知のための関係分析 C) 大量の時系列センサーデータの保存 D) Eコマースの製品カタログの保存

答え: B

解説: Neptuneはグラフデータベースで、エンティティ間の関係を効率的に表現しクエリします。ソーシャルグラフのフレンド-フレンド-フレンドの連鎖分析、金融取引の不正パターン検知、知識グラフ、推薦エンジンに適しています。Gremlin（Property Graph）とSPARQL（RDF）クエリ言語をサポートします。

A) 最高のパフォーマンスが必要な場合 B) AuroraでサポートされていないPostgreSQL特有の拡張機能やプラグインが必要な場合 C) 自動スケーリングが必要な場合 D) グローバル分散が必要な場合

答え: B

解説: RDS PostgreSQLは、Auroraがサポートしていない特定のPostgreSQL拡張機能（例：一部の高度なPostGIS機能、特定のfdw拡張）が必要な場合や、特定のメジャーバージョンの即時サポートが必要な場合に選択します。Auroraの内部アーキテクチャは標準的なPostgreSQLとは異なるため、すべてのPostgreSQL機能をサポートしているわけではありません。

A) 複数のGSIを1つにまとめてコスト削減 B) 1つのGSIを異なるエンティティタイプの複数のクエリパターンに再利用する C) GSIのプロジェクション属性を動的に変更する D) GSIの書き込み容量を自動最適化する

答え: B

解説: GSIオーバーローディングはGSIのPKとSKにエンティティタイプ別に異なる意味の値を格納します。例えば、gsi1pkにユーザーはSTATUS#active、注文はDATE#2026-03、商品はCATEGORY#electronicsを格納すると、1つのGSIでステータス別ユーザー照会、日付別注文照会、カテゴリ別商品照会がすべて可能になります。

A) 超高速インメモリキャッシュ B) 変更不可能な暗号学的に検証可能なトランザクションログの維持 C) グラフ関係データの保存 D) Cassandra API互換

答え: B

解説: QLDBはデータ変更履歴を変更不可能で（immutable）、SHA-256ハッシュで暗号学的に検証可能なジャーナル（journal）に保存します。規制業界（金融、サプライチェーン、HR）で監査証跡が必要な場合に適しています。すべての変更を完全な履歴として追跡し、データの完全性を検証できます。

A) セッション保存、高可用性、永続性が必要な場合 B) シンプルなオブジェクトキャッシュが必要で、マルチスレッドでCPUコアを最大限活用したい場合 C) Pub/Subメッセージングが必要な場合 D) 地理的に分散したキャッシュが必要な場合

答え: B

解説: Memcachedはシンプルなキーバリューキャッシュに最適化されたマルチスレッドアーキテクチャを使用します。CPUコア数に比例した線形スケールが可能です。セッション、永続性、Pub/Sub、レプリケーション、スナップショットが不要でシンプルなキャッシュ性能だけが必要な場合、Memcachedが適しています。Redisはより豊富なデータ構造と高可用性を提供します。

A) 単一リージョン内の読み取りスケーリング B) 災害復旧（RPO秒単位、RTO1分未満）とグローバル読み取りレイテンシーの削減 C) Aurora Serverless v2ワークロードの最適化 D) 大規模なバッチ処理

答え: B

解説: Aurora Global Databaseは1つのプライマリリージョンと最大5つのセカンダリリージョンで構成されます。リージョン間のレプリケーション遅延は1秒未満です。障害発生時にセカンダリリージョンに昇格するとRTO1分未満、RPO秒単位の災害復旧が可能です。また各リージョンのユーザーがローカル読み取りで低レイテンシーを体験できます。

A) ソーシャルメディアの関係データ B) IoTセンサー、アプリケーションメトリクス、運用イベントなどの時系列データ C) 金融トランザクション台帳の管理 D) Eコマースの製品リスト

答え: B

解説: Timestreamは時系列データに特化したサーバーレスデータベースです。時間ベースのクエリ（集計、補間、平滑化）の組み込み関数を提供し、最新データはメモリに、過去データはS3ベースのマグネティックストレージに自動保存します。時系列特化クエリはRDSと比較して大幅に高速です。

A) スタンバイインスタンスは読み取りクエリを処理できる B) スタンバイインスタンスは自動フェイルオーバーのために同期レプリケーションを維持するが直接アクセス不可 C) スタンバイは別のAWSリージョンに配置される D) スタンバイへのフェイルオーバーは手動でトリガーする必要がある

答え: B

解説: RDS Multi-AZのスタンバイインスタンスはプライマリインスタンスと同期レプリケーション（synchronous replication）を維持します。スタンバイは直接読み書きトラフィックを処理できません（読み取りにはRead Replicaを使用）。プライマリ障害時にDNSエンドポイントが自動的にスタンバイに切り替わります（約60〜120秒かかります）。

A) RDS for Oracle（BYOLライセンス込み） B) SCT + DMSでAurora PostgreSQLまたはRDS PostgreSQLに変換 C) RDS for Oracle（ライセンス込み） D) EC2にOracleを自己インストール

答え: B

解説: OracleからAurora PostgreSQLやRDS PostgreSQLへの移行でOracleライセンスコストを完全に排除できます。AWS SCT（Schema Conversion Tool）でOracleスキーマをPostgreSQLに変換し、DMSでデータを移行します。Oracle特有機能（PL/SQL、Oracleオプション）はSCT評価で変換の複雑さを把握します。

A) 別のリージョンにデータベースを複製する B) 事前検証されたステージング環境（Green）からプロダクション（Blue）へダウンタイムを最小化した切り替え C) マイナーバージョンのアップグレードを自動的に実行する D) スナップショットから新しいデータベースを作成する

答え: B

解説: RDS Blue/Green Deploymentsは現在のプロダクション（Blue）の完全なコピー（Green）を作成し同期を維持します。Greenで新バージョン、パラメーター、スキーマ変更などを事前検証し、検証完了後にBlueからGreenへのトラフィック切り替えを数秒で実行します。ロールバックも簡単です。

A) はい、MySQLとAurora MySQLは異なるエンジンなのでSCTが必要 B) いいえ、同種マイグレーション（MySQL → Aurora MySQL）はSCTなしでDMSのみで可能 C) 常にSCTを先に実行しなければならない D) Aurora MySQLはDMSのターゲットとしてサポートされていない

答え: B

解説: SCTは異種マイグレーション（Oracle → PostgreSQL、SQL Server → MySQLなど）でスキーマを変換するために必要です。同種マイグレーション（MySQL → Aurora MySQL、PostgreSQL → Aurora PostgreSQL）はスキーマに互換性があるため、SCTなしでDMSだけで移行できます。

A) インプレースアップグレードを即時実行する B) スナップショットから新しいクラスターを作成してアップグレード → 検証 → トラフィック切り替え C) 読み取りレプリカを最初にメジャーバージョンにアップグレードする D) DMSで新しいクラスターにデータを移行する

答え: B

解説: Auroraのメジャーバージョンアップグレードにはリスクがあるため推奨手順は：1）現在のクラスターのスナップショットを作成 → 2）スナップショットから新しいクラスターを作成してメジャーバージョンにアップグレード → 3）アプリケーション互換性の検証 → 4）DNS（CNAME）切り替えまたはBlue/Green Deploymentsの使用です。

A) DMSでDynamoDB間の移行 B) DynamoDBテーブルをS3にエクスポート後、ターゲットでS3からインポート C) Kinesis Data Streams + Lambdaでリアルタイムレプリケーション D) CloudFormationスタックのコピー

答え: B

解説: DynamoDBのエクスポート機能（Export to S3）でテーブルデータをDynamoDB JSONまたはION形式でS3に書き出した後、ターゲットアカウント/リージョンのS3からDynamoDBのインポート（Import from S3）で新しいテーブルにロードします。DynamoDB Global Tablesを使用すると継続的なマルチリージョンレプリケーションも可能です。

A) SQL ServerライセンスをAWSに移転できる B) SQL Server Agent、SSIS、SSRS、SSASなどの機能サポート可否の確認 C) RDS SQL ServerはMulti-AZをサポートしない D) RDS SQL Serverは最大1TBのストレージのみサポート

答え: B

解説: RDS for SQL ServerはSQL Server Agentをサポートしますが、SSIS、SSRS、SSASはサポートしません。これらのサービスを使用している場合はEC2にインストールするか代替サービスを検討する必要があります。また、RDSでサポートされる特定のSQL Serverバージョンも確認が必要です。

A) レプリケーションスロット（Replication Slot）の作成 B) ROW形式でのバイナリログ有効化: binlog_format=ROW C) 読み取りレプリカの作成 D) パラメーターグループ変更なしに自動的に処理される

答え: B

解説: MySQLでDMS CDCを使用するにはROW形式でバイナリログ（binlog）を有効にする必要があります。binlog_format=ROW、binlog_row_image=FULL、expire_logs_daysの設定が必要です。RDS MySQLではパラメーターグループでこれらを設定します。PostgreSQLはレプリケーションスロットを使用します。

A) 両方のアプローチは同じ移行複雑さ B) リフトアンドシフトは最小限の変更でAWSに移行、リアーキテクトはクラウドネイティブサービスで再設計 C) リアーキテクトが常に安価 D) リフトアンドシフトはオンプレミスと同じパフォーマンスを保証

答え: B

解説: リフトアンドシフトは既存のデータベースを最小限の変更でEC2やRDSに移行します。速く低リスクですが、クラウドのメリットを完全には活用できません。リアーキテクトはDynamoDBやAuroraなどのクラウドネイティブサービスで再設計し、より多くのクラウドメリットを活用しますが、複雑さとコストが高くなります。

A) Parameter Groupはネットワーク設定、Option Groupはセキュリティ設定 B) Parameter Groupはデータベースエンジンの設定、Option Groupは追加機能の有効化（例：Oracle TDE、MSSQL SQL Server Audit） C) 2つのグループは同じ目的に使用される D) Option GroupはPostgreSQLにのみ使用される

答え: B

解説: RDS Parameter Groupはmax_connections、innodb_buffer_pool_sizeなどのデータベースエンジンパラメーターを設定します。Option GroupはOracleのTDE（Transparent Data Encryption）、MSSQLのSQL Server Audit、MySQLのmemcachedプラグインなどの追加機能を有効にします。

A) CPUの不足によるボトルネック B) 行レベルロック競合による待機 — クエリが他のトランザクションの行ロック解除を待っている C) ネットワーク遅延 D) ストレージI/Oボトルネック

答え: B

解説: db/lock/rowウェイトイベントは行レベルロック（row-level lock）競合を示します。トランザクションAが特定の行をロックしている状態でトランザクションBが同じ行を更新・削除しようと待機しています。解決策はトランザクションサイズの縮小、インデックスの最適化（ロック範囲の縮小）、デッドロックの分析です。

A) プライマリインスタンスのコンピューティングサイズを自動的に増やす B) CloudWatchメトリクス（CPU使用率、接続数）に応じて読み取りレプリカを自動的に追加・削除する C) ストレージを自動的に拡張する D) 複数のリージョンにわたってAuroraクラスターを自動的に作成する

答え: B

解説: Aurora Auto ScalingはCloudWatchメトリクス（平均CPU使用率または平均接続数）に応じてAurora読み取りレプリカを動的に追加・削除します。トラフィック急増時は読み取りレプリカを自動追加し、トラフィック減少時は不要なレプリカを削除してコストを最適化します。

A) On-Demandは読み書き容量を手動で指定する必要がある B) Provisionedモードは予測可能なトラフィックパターンでコスト効率が良く、On-Demandは予測不可能なトラフィックに適している C) On-Demandはフリーティアを含まない D) Provisionedモードはスケーリングができない

答え: B

解説: Provisionedモードは予測可能なワークロードでRCU/WCUを指定してAuto Scalingを有効にすることでコスト効率よく運用できます。On-Demandモードはトラフィックに応じて自動的にスケールしますが、リクエストあたりのコストが高くなります。新しいテーブル、予測不可能なトラフィック、開発・テストにOn-Demandが適しています。

A) 自動バックアップは暗号化されない B) 自動バックアップは保持期間（1〜35日）後に自動削除されるが、手動スナップショットは明示的に削除するまで保持される C) 手動スナップショットはPITR（Point-in-Time Recovery）をサポートする D) 自動バックアップは別のリージョンにコピーできない

答え: B

解説: RDS自動バックアップは設定した保持期間（最大35日）後に自動的に削除されます。手動スナップショットは明示的に削除しない限り永続保持されます。自動バックアップはPITR（Point-in-Time Recovery）のためのトランザクションログも一緒に保持します。

A) 別のリージョンにデータをレプリケートする B) スナップショット復元なしにデータベースを過去の特定時点に巻き戻す（5分〜72時間以内） C) メジャーバージョンの自動アップグレード D) 読み取りトラフィックの自動分散

答え: B

解説: Aurora Backtrackはデータベースを過去の特定時点に迅速に巻き戻す機能です。スナップショットから復元するより大幅に速く（数分以内に完了）、誤ったDELETE/UPDATE後の迅速な復旧に最適です。最大72時間まで巻き戻しが可能で、Aurora MySQLでサポートされています。

A) 同一リージョン内のMulti-AZレプリケーション B) 複数のAWSリージョンにわたる完全マネージドのマルチマスターレプリケーション — 各リージョンで書き込み可能 C) 別のリージョンに読み取りレプリカを作成する D) 別のリージョンのDynamoDBテーブルに読み取り専用でアクセスする

答え: B

解説: DynamoDBグローバルテーブルは複数のAWSリージョンにわたる完全マネージドのマルチマスターレプリケーションを提供します。各リージョンで読み書きが可能で、リージョン間のレプリケーションは通常1秒未満です。1つのリージョンが停止しても他のリージョンで継続して動作します。

A) ConsumedReadCapacityUnitsとConsumedWriteCapacityUnits B) SystemErrorsとUserErrors C) SuccessfulRequestLatency D) ReturnedItemCount

答え: A

解説: ProvisionedThroughputExceededExceptionはプロビジョニングされた量を超えた読み取りまたは書き込みキャパシティが発生した際に起きます。ConsumedReadCapacityUnitsとConsumedWriteCapacityUnitsを確認して、どのキャパシティ（読み取りまたは書き込み）が超過しているかを把握します。ThrottledRequestsメトリクスも一緒に確認します。

A) CloudTrailでスロークエリを追跡する B) RDSパラメーターグループでslow_query_log=1、long_query_timeを設定し、CloudWatch LogsまたはRDSコンソールで分析する C) VPC Flow Logsでクエリパターンを分析する D) Enhanced Monitoringでスロークエリを検出する

答え: B

解説: RDS MySQLのスロークエリログはパラメーターグループでslow_query_log=1を有効にしてlong_query_time（閾値秒数）を設定します。ログはRDSコンソールから直接確認するか、CloudWatch Logsに公開してCloudWatch Insightsで分析できます。log_queries_not_using_indexes=1でインデックスを使用しないクエリも追跡できます。

A) プライマリインスタンスのCPUが高い → インスタンスサイズをアップグレード B) 読み取りレプリカがプライマリインスタンスの変更に追いつけていない → レプリカインスタンスのサイズアップグレードまたは書き込み操作の最適化 C) ストレージボリュームがいっぱい → ストレージを拡張する D) ネットワーク遅延 → VPC設定を確認する

答え: B

解説: AuroraReplicaLagは読み取りレプリカがプライマリインスタンスの変更を適用するのにかかる遅延時間です。遅延が高いと読み取りレプリカから古いデータを読む可能性があります。解決策：読み取りレプリカのインスタンスサイズのアップグレード、書き込み集約的な操作の最適化、または書き込みクエリをプライマリインスタンスのみにルーティングすることです。

A) Enhanced Monitoringは無料 B) Enhanced MonitoringはOSレベルのメトリクス（プロセス、メモリ使用量）を1〜60秒間隔で提供する C) CloudWatchの標準モニタリングがより細粒度のメトリクスを提供する D) Enhanced Monitoringはデータベース接続のみを監視する

答え: B

解説: CloudWatchの標準モニタリングはハイパーバイザーから収集したインスタンスレベルのメトリクスを1分または5分間隔で提供します。Enhanced MonitoringはRDSインスタンスにインストールされたエージェントがOSレベルのプロセスリスト、メモリ使用量、CPUスケジュールなどを1〜60秒間隔で収集します。

A) データベースクエリのキャッシュ B) コンプライアンスとセキュリティ監査のためにすべてのデータベースアクティビティをKinesis Data Streamsにリアルタイムストリーミング C) データベースメトリクスをCloudWatchに送信する D) データベースバックアップの自動化

答え: B

解説: Database Activity Streamsはすべてのデータベースアクティビティ（SQL文、接続、認証）をKMSで暗号化されたKinesis Data Streamsにリアルタイムストリーミングします。これによりSIEM（Security Information and Event Management）ツールと統合してリアルタイムセキュリティ監視と監査証跡を実現します。DBAもストリームの内容にアクセスできないため、データ改ざんを防ぎます。

A) 読み取りレプリカの数が多すぎる B) ストレージI/Oボトルネック、過剰な書き込みワークロード、またはネットワーク遅延 C) 接続プーリング設定の誤り D) パラメーターグループの変更が必要

答え: B

解説: CommitLatencyはトランザクションコミット完了にかかる時間です。突然増加する場合はAuroraストレージレイヤーのI/Oボトルネック、過剰な書き込みトランザクション、ログフラッシュ遅延を疑います。WriteLatency、DiskQueueDepth、FreeableMemoryメトリクスと合わせて分析して根本原因を特定します。

A) テーブル全体のRCU/WCUを増やす B) パーティションキーの設計変更（カーディナリティの高いキーを使用するかランダムサフィックスを追加） C) GSIを追加してパーティションを分散する D) On-Demandモードに切り替える

答え: B

解説: ホットパーティションはパーティションキーのカーディナリティが低いか特定のキーにトラフィックが集中する際に発生します。解決策：1）カーディナリティの高いパーティションキーを選択（UserID、UUIDなど）、2）パーティションキーにランダムサフィックスを追加（Write Sharding）、3）時間ベースのキーに適切な分散を適用します。On-Demandへの切り替えはボトルネックを隠すだけで根本解決ではありません。

A) データベースを再起動する B) RDS Storage Autoscalingを有効にするか、手動でストレージサイズを拡張する C) 読み取りレプリカを追加する D) Multi-AZに切り替える

答え: B

解説: RDS Storage Autoscalingを有効にすると指定した閾値以下にFreeStorageSpaceが下がった際に自動的にストレージが拡張されます。すでにストレージが不足している場合は手動でストレージ割り当てサイズを増やせます（縮小は不可）。また、バイナリログの保持期間の短縮や古いデータのアーカイブも検討します。

A) より高速な認証処理 B) データベースのパスワードなしにIAM認証情報で短期認証トークンを使用した接続が可能 C) Multi-AZフェイルオーバー時の自動再認証 D) データ暗号化の自動有効化

答え: B

解説: RDS IAM認証を有効にするとデータベースのパスワードの代わりにAWS IAM認証情報で15分間有効な認証トークンを生成して接続します。アプリケーションにパスワードを保存する必要なくIAMポリシーでデータベースアクセスを制御できます。EC2インスタンスロールやLambda実行ロールとの統合に適しています。

A) ローテーション中でも既存の認証情報が有効でダウンタイムなしのローテーションが可能 B) セキュリティがより強化される C) 認証情報の保存コストが削減される D) 自動ローテーションの頻度を高められる

答え: A

解説: 交互ユーザー戦略は2つのユーザーを交互に使用します。ローテーション時に非アクティブユーザーのパスワードのみを変更してアクティブユーザーは維持します。これにより、ローテーション中もアプリケーションが現在のパスワードで接続し続けられるため、ダウンタイムが発生しません。単一ユーザーローテーションは瞬間的に接続が切れる可能性があります。

A) RDSにパブリックIPを割り当ててインターネット経由でアクセスする B) Direct ConnectまたはSite-to-Site VPN経由のプライベートネットワーク接続 C) インターネットゲートウェイ経由でアクセスする D) RDSスナップショットをオンプレミスにエクスポートする

答え: B

解説: オンプレミスからVPCプライベートサブネットのRDSにセキュアにアクセスするにはAWS Direct Connect（専用線）やAWS Site-to-Site VPNを使用します。インターネットを経由せずプライベートネットワーク経由で通信するためセキュリティが強化されます。セキュリティグループでオンプレミスIPアドレス範囲のアクセスを明示的に許可します。

A) 暗号化はいつでも有効・無効にできる B) 既存の暗号化されていないRDSインスタンスを直接暗号化に変換できない — スナップショット作成 → 暗号化されたスナップショットとしてコピー → 復元が必要 C) 暗号化はMulti-AZでのみサポートされる D) 暗号化を有効にするとパフォーマンスが50%低下する

答え: B

解説: すでに作成されたRDSインスタンスの暗号化は直接有効にできません。必ず暗号化されていないインスタンスのスナップショットを作成し、そのスナップショットを暗号化されたスナップショットとしてコピーした後、暗号化されたスナップショットから新しいインスタンスを復元する必要があります。そのため新しいデータベース作成時から暗号化を有効にすることが重要です。

A) DynamoDBに列レベルセキュリティを適用する B) IAMポリシーのdynamodb:LeadingKeys条件でパーティションキー値をユーザーIDに制限する C) Lake FormationでDynamoDBの行レベルセキュリティを適用する D) VPCエンドポイントでネットワークレベルのアクセス制御

答え: B

解説: IAMポリシーのdynamodb:LeadingKeys条件キーを使用すると、ユーザーがアクセスできるパーティションキー値を制限できます。現在のIAMユーザーIDを表すaws:useridポリシー変数に基づいてパーティションキーを制限すると、各ユーザーは自分のUserIDに一致する項目のみ読み書きできるようになります。

A) DynamoDB（シングルテーブル）+ Lambda B) Aurora Global Database（マルチリージョン）+ Database Activity Streams + Secrets Manager C) RDS MySQL Multi-AZ + Read Replicas D) ElastiCache Redis + DynamoDB

答え: B

解説: Aurora Global Databaseはリージョン障害時にRTO1分未満、RPO秒単位を提供します。Database Activity Streamsはすべてのトランザクション活動をリアルタイム監査証跡として記録し、金融規制コンプライアンスを支援します。Secrets Managerで認証情報を自動ローテーションしてセキュリティを強化します。

A) OracleのSEQUENCEのPostgreSQL変換 B) PL/SQLストアドプロシージャのPL/pgSQLへの変換 C) テーブル名の変更 D) データ型変換（DATE、NUMBER） E) インデックスの削除

答え: B、D

解説: OracleからPostgreSQLへの移行の主要な複雑度要素：1）PL/SQL → PL/pgSQL変換：Oracle特有の関数、パッケージ、カーソルなどの変換が必要です。2）データ型：OracleのNUMBER、DATE、VARCHAR2がPostgreSQLではNUMERIC、TIMESTAMP、VARCHARに変換され、一部の動作に違いがあります。SCT（Schema Conversion Tool）で自動変換の可否を評価します。

A) Redis Cluster Mode Disabled + レプリカなし B) Redis Cluster Mode Enabled + シャードあたりのレプリカ2個 + Multi-AZ有効化 C) Memcachedクラスターに置き換える D) Redisスナップショットを定期的に作成する

答え: B

解説: Cluster Mode Enabledで各シャードにレプリカを2個設定してMulti-AZを有効にすると、1つのノードが障害になった際に自動的にレプリカがプライマリノードに昇格します。レプリカ2個は最大2つのノードの同時障害を許容します。セッションデータはメモリにレプリケートされているため、障害時も維持されます。

A) テナントごとに別々のDynamoDBテーブルを作成する B) パーティションキーにテナントIDを含めて単一テーブルでデータを分離する C) テナントごとに別々のAWSアカウントを作成する D) DynamoDB Streamsでテナント別データをレプリケートする

答え: B

解説: ほとんどの場合、単一テーブルのパーティションキーにTENANT#tenantId#ENTITY#entityIdのようにテナントIDを含めます。IAMポリシーのdynamodb:LeadingKeys条件で各テナントが自分のパーティションキーのみにアクセスできるよう制限します。テナント数が非常に多いか分離要件が厳格な場合はテーブル分離を検討します。

A) RDS Proxyでクエリルーティングを設定する B) レプリカの個別エンドポイントまたはカスタムエンドポイント（Custom Endpoint）を使用する C) CloudFrontでクエリをルーティングする D) Route 53加重ルーティングで特定のレプリカにトラフィックを集中させる

答え: B

解説: Auroraカスタムエンドポイントを使用すると特定のレプリカセットに接続をルーティングできます。大型インスタンスのレプリカをまとめて分析クエリ用のカスタムエンドポイントを作成し、一般的な読み取りにはクラスター読み取りエンドポイントを使用します。各レプリカの個別インスタンスエンドポイントも使用できます。

A) RDSインスタンスサイズをアップグレードする（メモリ増加でmax_connectionsが自動増加） B) Amazon RDS Proxyをデプロイして接続プーリングを実装する C) 読み取りレプリカを追加して接続を分散する D) max_connectionsパラメーター値を直接増やす

答え: B

解説: Amazon RDS ProxyはアプリケーションとRDSの間で接続プーリングを行います。数千のアプリケーション接続を少数の実際のデータベース接続に多重化します。アプリケーションコードを変更せずにエンドポイントをProxyエンドポイントに変更するだけです。Lambda関数のデータベース接続の爆発問題の解決に特に有用です。

A) 遅いクエリを自動的に最適化する B) 実行されたすべてのSQL文の実行統計（実行回数、平均時間、合計時間）を追跡する C) データベース接続数を自動管理する D) 自動的にインデックス作成を推奨する

答え: B

解説: pg_stat_statementsはPostgreSQLの拡張機能で、実行されたすべてのSQL文の統計（呼び出し回数、合計/平均/最大/最小実行時間、処理行数など）を追跡します。Performance Insightsと合わせて最も頻繁に実行されるクエリや最も遅いクエリを把握するために使用します。RDS PostgreSQLのパラメーターグループで有効にします。

A) 各マイクロサービスごとに別々のRDSインスタンスを作成する B) 各RDSデータベースの前にRDS Proxyをデプロイして接続プーリングを実装する C) より大きなRDSインスタンスにアップグレードする D) すべてのRDSをDynamoDBに置き換える

答え: B

解説: コンテナベースのマイクロサービスはオートスケーリング時に数百〜数千のデータベース接続を瞬間的に作成してmax_connectionsを超過します。RDS Proxyはこれらの接続をプーリングして実際のデータベースには管理可能な数の接続のみ維持します。IAM認証もサポートしセキュリティも強化されます。

A) DocumentDBはすべてのMongoDBバージョンと完全に互換性がある B) DocumentDBはMongoDBワイヤープロトコルと互換性があるが、すべてのMongoDB機能をサポートしていないため機能サポートの確認が必要 C) DocumentDBをMongoDB Atlasに移行する必要がある D) アップグレード時にデータ損失が発生する

答え: B

解説: Amazon DocumentDBはMongoDBワイヤープロトコルと互換性がありますが、すべてのMongoDB機能を完全に実装しているわけではありません。アップグレード前に使用しているMongoDBドライバーのバージョン、使用するコマンドと集計パイプラインのDocumentDBサポート状況、特定のMongoDB固有機能（Change Streams、Transactionsなど）のサポート状態を確認する必要があります。

A) Secrets ManagerがRDSに直接アクセスできない B) Lambda関数がRDSインスタンスと同じVPCに属していないためネットワークアクセスができない C) KMSキーの権限エラー D) IAMロールの権限が不足している

答え: B

解説: Secrets Managerの自動ローテーションLambda関数は実際のデータベースに接続してパスワードを変更する必要があります。LambdaがRDSと異なるVPCにあるか、同じVPCでもセキュリティグループがLambdaのアクセスを許可していないと接続が失敗します。LambdaをRDSと同じVPCにデプロイし、セキュリティグループを正しく設定する必要があります。

A) ElastiCacheのTTL（Time-To-Live）のみを使用する B) アプリケーションでデータ変更時に該当するキャッシュキーを明示的に削除する（Cache-Asideパターン） C) DynamoDB Streamsでキャッシュを自動更新する D) Auroraトリガーでlambdaを呼び出してキャッシュを無効化する

答え: B

解説: Cache-Aside（Lazy Loading）パターンが最も一般的なキャッシュ戦略です。読み取り時はキャッシュを最初に確認し、キャッシュミス時はデータベースから読んでキャッシュに保存します。書き込み時はデータベースを更新して該当するキャッシュキーを削除します。TTLは補完的な安全網として使用します。

A) RDSへのパブリックアクセスを有効にしてIAMポリシーで制限する B) VPC PeeringまたはTransit Gatewayでアカウント間のネットワーク接続後、IAM認証を使用する C) RDSスナップショットをターゲットアカウントと共有する D) クロスアカウントIAMロールでRDSに直接アクセスする

答え: B

解説: 最もセキュアな方法は、VPC PeeringまたはAWS Transit Gatewayで2つのアカウントのVPCをプライベートネットワークで接続した後、Lambda実行ロールにRDS IAM認証権限を付与してRDS IAM認証で接続します。RDSをパブリックに公開しないためネットワークレベルでのセキュリティが維持されます。

A) Aurora Serverless v2の代わりにProvisionedに切り替える B) MaxCapacity値を引き上げ、必要に応じてProvisioned読み取りレプリカを追加する C) クラスターを削除して新しく作成する D) アプリケーション接続を強制終了する

答え: B

解説: MaxCapacity制限に達すると新しいリクエストが処理されません。即時対処としてMaxCapacity値を増やします（最大128 ACU）。長期的には読み取り負荷はProvisioned読み取りレプリカを追加して分散し、書き込み容量が限界の場合はクエリ最適化やシャーディングを検討します。

A) アプリケーションレイヤーですべての変更をログ記録する B) RDS/Aurora Database Activity Streams + Kinesis Data Firehose → S3アーカイブ C) すべてのデータベーステーブルに監査トリガーを追加する D) CloudTrailでRDS API呼び出しを記録する

答え: B

解説: Database Activity StreamsはすべてのデータベースアクティビティをKMS暗号化されたKinesisストリームで送信します。Kinesis FirehoseでS3に長期アーカイブしてAthenaで分析します。アプリケーションコードの変更が不要で、DBAもアクセスできない改ざん防止の監査証跡を提供します。

A) 指定した時間後に項目が即時削除される B) TTL属性に指定されたUNIXタイムスタンプ後に項目が自動的に削除される（48時間以内、コストなし） C) 期限切れの項目は非表示になるがストレージには残る D) TTL削除には書き込みキャパシティユニットが消費される

答え: B

解説: DynamoDB TTLはTTL属性にUnixタイムスタンプを設定すると、そのタイムスタンプ後48時間以内に自動的に項目を削除します（正確な時間は保証されません）。TTL削除は追加コストが不要で書き込みキャパシティを消費しません。セッションデータ、一時データ、有効期限トークンの管理に有用です。

A) 常にGremlinを使用する B) Property Graph（ソーシャルネットワーク、推薦）にはGremlin、RDF/オントロジー（知識グラフ、セマンティックウェブ）にはSPARQL C) SPARQLが常に速い D) 一方の言語のみを選択後は変更できない

答え: B

解説: Neptuneは2つのグラフモデルをサポートします。Property Graph（Gremlin）はノードとエッジにプロパティを付けるモデルで、ソーシャルグラフ、不正検知、推薦エンジンに適しています。RDF（SPARQL）はResource Description Frameworkで、知識グラフ、セマンティックウェブ、オントロジーモデリングに適しています。

A) DMSでSQL Server間の移行を実行する B) S3と統合されたRDS SQL Serverのネイティブバックアップ/復元機能を使用する（Option GroupでSQLSERVER_BACKUP_RESTOREオプションを有効化） C) スナップショットをダウンロードしてオンプレミスに復元する D) bcpユーティリティでデータをエクスポートする

答え: B

解説: RDS for SQL Serverのネイティブバックアップ/復元はOption GroupでSQLSERVER_BACKUP_RESTOREオプションを有効にしてS3バケットを指定します。rdsadmin.dbo.rds_backup_databaseストアドプロシージャでS3に.bakファイルをバックアップし、rdsadmin.dbo.rds_restore_databaseで復元します。

A) max_connectionsを増やす B) Query Plan Management（QPM）またはpg_hint_plan拡張機能でクエリプランを固定する C) 読み取りレプリカを追加する D) インスタンスサイズをアップグレードする

答え: B

解説: クエリプランの不安定性は統計の変化やプランナーの動作変化によって引き起こされます。Aurora PostgreSQLのapg_plan_mgmt（Query Plan Management）拡張機能で特定のSQLの実行計画を固定できます。pg_hint_planでSQLヒントを提供するか、enable_seqscan、enable_indexscanパラメーターでプランナーを誘導することもできます。

A) 単一項目の読み書き B) 複数のテーブルにまたがる複数の項目のアトミック（原子的）な読み書きが必要な場合（例：口座振替、在庫引き落とし） C) 大容量データの一括処理 D) TTL設定が必要な場合

答え: B

解説: DynamoDBトランザクションは最大100項目（または4MB）を原子的に読み書きできます。複数のテーブルにまたがる一貫した更新（口座AからBへの振替、在庫引き落とし+注文作成）に適しています。ただし、トランザクションは通常のAPIより2倍のWCUを消費するため必要な場合のみ使用します。

A) すべてのマイクロサービスが単一の共有データベースを引き続き使用する B) Sagaパターンで分散トランザクションをイベント/メッセージベースで管理する C) 二相コミット（2PC）で分散トランザクションを実装する D) リアルタイムのデータ同期なしに各サービスを独立して運用する

答え: B

解説: Sagaパターンは分散トランザクションを各サービスがローカルトランザクションを実行してイベントを発行するステップのシーケンスで管理します。失敗時は補償トランザクション（Compensating Transaction）を実行して以前の状態に戻します。Choreography（イベントベース）またはOrchestration（中央オーケストレーター）方式で実装します。

A) 競合を手動で解決する必要がある B) 「最後の書き込み優先（Last Writer Wins）」方式でタイムスタンプが最新の書き込みが優先される C) 最初に到着した書き込みが優先される D) リージョンの優先順位によって決定される

答え: B

解説: DynamoDBグローバルテーブルはLast Writer Wins（最後の書き込み優先）の競合解決方式を使用します。同一の項目に対して複数のリージョンから同時に書き込みが発生した場合、最も最新のタイムスタンプの書き込みが最終値として採用されます。競合を避けるには各リージョンが異なるパーティションキー範囲に書き込むようアプリケーションを設計するのが良いです。

A) RDSイベント通知を使用する B) DMS CDCタスク + Kinesis Data Streamsターゲットを設定して変更をストリーミングする C) CloudWatch Logsで変更を記録する D) RDSスナップショットを定期的に分析する

答え: B

解説: AWS DMSのCDC機能を使用するとRDS MySQLのbinlogベースの変更をKinesis Data Streamsにリアルタイムストリーミングできます。KinesisをDMSタスクのターゲットに設定すると各INSERT/UPDATE/DELETEイベントがKinesisストリームに送信されます。LambdaやKinesis Analyticsがこれらを処理できます。

A) 複雑な複数テーブル結合が必要なOLTPシステム B) 既存のCassandra互換ワークロードを運用オーバーヘッドなしにAWSで実行する C) グラフデータベースクエリ D) SQLベースの分析

答え: B

解説: Amazon Keyspacesは完全マネージドのApache Cassandra互換サービスです。既存のCassandra CQL（Cassandra Query Language）コードとドライバーをそのまま使用できます。Cassandraクラスターの運用（ノード管理、パッチ、スケーリング）のオーバーヘッドなしにサーバーレスで運用したい場合に選択します。

A) すべてのクエリを同期的に実行する B) PgBouncerのような外部接続プーラーまたはRDS Proxyを使用する C) リクエストごとに新しい接続を作成する D) 接続タイムアウトを最大に設定する

答え: B

解説: PgBouncerはPostgreSQL専用の接続プーラーで、アプリケーションの多くの接続リクエストを実際のデータベースへの少ない接続に多重化します。トランザクションプーリングモードでは最高の効率を提供します。RDS Proxyも同じ機能をAWSマネージドサービスとして提供します。

A) VPCプライベートサブネットにRDSをデプロイ + セキュリティグループで最小権限のネットワークアクセス B) KMSカスタマー管理キー（CMK）で保存時の暗号化 + 転送中のSSL/TLS強制 C) RDSをパブリックに公開してIPで制限する D) デフォルトの暗号化キーを使用する E) すべてのユーザーに同じデータベースアクセス権限を付与する

答え: A、B

解説: HIPAAコンプライアンスとPHI保護のための多層セキュリティ：1）VPCプライベートサブネット + セキュリティグループでネットワークレベルのアクセスを最小化します。2）KMS CMKで保存時の暗号化、SSL/TLSで転送中の暗号化を実装します。さらにIAM認証、Secrets Manager認証情報管理、Database Activity Streams監査、最小権限の原則も適用します。