Q1 — 単一選択アプリケーション層は複数の障害ドメインへ配置され、データベースはAmazon RDSのマルチAZ構成である。アプリケーションインスタンス1台だけが異常になったが、データベースのライターは正常である。最も適切なフェイルオーバー動作はどれか。
A. アプリケーション障害を検知したら、データベースも必ず同時にスタンバイへフェイルオーバーする
B. 異常なアプリケーション対象を新規リクエストから外し、正常なアプリケーション対象は現在の正常なデータベースライターを引き続き利用する
C. データベースが正常でも、アプリケーション障害が1件発生した時点で全サービスを停止する
D. アプリケーション層とデータベース層は常に同じ障害として扱い、片方だけを切り替える設計は避ける
答えと解説
答え：B
アプリケーション層とデータベース層は独立して障害を判断します。DBライターが正常なら、アプリケーション障害だけを処理するためにDBまで強制フェイルオーバーする必要はありません。
Q2 — 単一選択Amazon RDSのマルチAZ DBインスタンスを利用している。プライマリ障害でスタンバイへ自動フェイルオーバーしたとき、アプリケーションのDB接続先設定をどのように扱うべきか。最も適切な説明はどれか。
A. スタンバイ昇格後は新しいDBエンドポイント名が発行されるため、アプリケーション設定を新しい名前へ変更する
B. アプリケーションでは同じDBエンドポイント名を使用し、RDSがそのDNSレコードを新しいプライマリへ向ける
C. DBエンドポイント名は使用せず、昇格前からスタンバイの物理IPアドレスをアプリケーションへ設定する
D. RDSはDNSの向き先を変更しないため、フェイルオーバーのたびに新プライマリのIPアドレスへ手動変更する
答えと解説
答え：B
マルチAZ DBインスタンスのフェイルオーバーでは、アプリケーションが使用するDBエンドポイント名を別名へ変更するのではありません。RDSが同じエンドポイントのDNSレコードを新しいプライマリへ向けます。
Q3 — 単一選択Amazon RDSのマルチAZ DBクラスターで、書き込み接続をフェイルオーバー後も新しいライターへ追従させたい。最も適切な接続先はどれか。
A. 現在のライターDBインスタンスのインスタンスエンドポイントをアプリケーションへ固定する
B. 任意のリーダーDBインスタンスのインスタンスエンドポイントへ書き込みを送る
C. クラスターのライターエンドポイントを使用し、接続プール側でも古いDNS情報を長時間保持しない
D. フェイルオーバーのたびにRDSコンソールで新しいライターのIPアドレスを確認して設定する
答えと解説
答え：C
ライターエンドポイントは現在のライターへ接続し、フェイルオーバー後は新しいライターへ接続先を変更します。
Q4 — 単一選択Amazon RDSマルチAZ DBインスタンスを利用している。多数のアプリケーション接続があり、フェイルオーバー時のDNS変更や再接続の影響を小さくしたい。また、DBライターが一時的に利用できない間も着信要求を受け付けられる構成を求めている。最も直接的な候補はどれか。
A. Amazon RDS Proxyを介してデータベースへ接続する
B. 読み取りレプリカを追加し、書き込み要求もすべて読み取りレプリカへ送る
C. DBインスタンスの物理IPアドレスをアプリケーション設定へ固定する
D. 新しいライターが決まるたびにアプリケーションの接続設定を手動で更新する
答えと解説
答え：A
RDS Proxyはフェイルオーバー中も接続を受け付け、新しいプライマリへ接続を振り向けます。また、DBライターが利用できない間は着信要求をキューへ入れることができます。
Q5 — 単一選択Amazon RDSのマルチAZ DBクラスターでライターDBインスタンスに障害が発生した。管理者による手動操作を待たず、自動フェイルオーバーが開始される仕組みとして最も適切な説明はどれか。
A. アプリケーションのDBクライアントがライター障害を判断し、リーダーDBインスタンスを直接ライターへ昇格する
B. Amazon RDSがライターDBインスタンスの障害を検出し、別のアベイラビリティーゾーンのリーダーDBインスタンスへ自動フェイルオーバーする
C. Route 53ヘルスチェックがDBライターを監視し、異常時にRDSのリーダーを必ず自動昇格する
D. CloudWatchアラームから管理者へ通知し、管理者がフェイルオーバーAPIを実行して初めてライターが切り替わる
答えと解説
答え：B
マルチAZ DBクラスターのライターに障害が発生すると、Amazon RDSが障害を検出し、別のアベイラビリティーゾーンのリーダーDBインスタンスへ自動的にフェイルオーバーします。正常性検知は、自動フェイルオーバーを開始するための入口です。
Q6 — 単一選択Aurora Global Databaseでプライマリリージョンが変わるスイッチオーバーやフェイルオーバー後も、アプリケーションの書き込み接続先名を変えずに新しいプライマリへ追従させたい。最も適切な設計はどれか。
A. 各リージョンのDBインスタンスエンドポイントをアプリケーションへ個別に埋め込み、障害時に手動で変更する
B. グローバルライターエンドポイントを使用し、アプリケーションやネットワーク層のDNSキャッシュを短くする
C. セカンダリリージョンのリーダーエンドポイントへ常に書き込みを送り、プライマリ変更を不要にする
D. グローバルライターエンドポイントを使えばDNSの向き先は変わらないため、DNSキャッシュ期間は考慮しない
答えと解説
答え：B
グローバルライターエンドポイントは、プライマリリージョンが変わっても同じ接続先名を利用できます。ただしDNS変更への追従は必要なので、長いDNSキャッシュは避けます。
Q7 — 単一選択Amazon RDSの可用性設計で、マルチAZ DBインスタンスとマルチAZ DBクラスターのフェイルオーバー時間を比較している。現在のAWS公式の目安として最も適切なものはどれか。
A. マルチAZ DBインスタンスは通常60～120秒、マルチAZ DBクラスターは通常35秒未満で、実時間はデータベース活動や復旧条件で変動する
B. マルチAZ DBインスタンスは通常35秒未満、マルチAZ DBクラスターは通常60～120秒である
C. どちらも通常35秒未満だが、マルチAZ DBインスタンスだけはトランザクション量の影響を受けない
D. どちらも通常60～120秒であり、マルチAZ DBクラスターの読み取り可能スタンバイはフェイルオーバー時間に影響しない
答えと解説
答え：A
AWS公式では、マルチAZ DBインスタンスのフェイルオーバーは通常60～120秒、マルチAZ DBクラスターは通常35秒未満です。実際の時間はデータベース活動、未処理トランザクション、復旧条件などによって変動します。
Q8 — 単一選択Amazon RDS Proxyを使用している。データベースのライター障害が、アプリケーションがトランザクションを実行している最中に発生した。最も適切な想定はどれか。
A. RDS Proxyが実行途中のトランザクションを新しいライターへ必ず移送し、同じ処理を成功として完了させる
B. RDS Proxyを使用しているため、フェイルオーバー中に実行途中のSQL文がキャンセルされることはない
C. 接続への影響を抑えられても、実行途中のトランザクションやSQL文はキャンセルされる場合があるため、アプリケーション側で失敗を処理する
D. フェイルオーバーが始まるとRDS Proxy自体が再作成されるため、プロキシエンドポイントを新しい値へ変更する
答えと解説
答え：C
RDS Proxyは接続フェイルオーバーの影響を小さくできますが、実行途中の処理まで成功保証するものではありません。