SAP-C02-057 · 理解確認
理解確認：Route 53によるService Continuity
14問 · 1問ずつ確認
プライマリ / セカンダリサイトは構築済みである。Amazon Route 53をビジネス継続性へ組み込むとき、Amazon Route 53の中心責任として最も適切なのはどれか?
B. 正常性評価に基づいて新しいDNS クエリを復旧先へ誘導する
C. プライマリリージョンのアプリケーションプロセスを修復する
D. 既存TCP 接続をセカンダリへ移送する
答えと解説
答え：B
Amazon Route 53は正常性に基づくDNS 答え選択を担当します。復旧サイト自体の構築や既存接続移送は別責任です。
API、データベース経路、外部依存関係の3つのヘルスチェックがあり、「3つのうち2つ以上が正常ならサービスを正常」と判定したい。最も適切な候補はどれか?
B. 3つすべてを同じDNS レコード値へ変更する
C. エイリアスレコードのTTLだけを短くする
D. セカンダリヘルスチェックを省略する
答えと解説
答え：A
計算済みヘルスチェックは複数子ヘルスチェックを集約し、必要な正常数で親正常性を判定できます。
Amazon Route 53へサービス正常性を渡す設計として正しいものを3つ選択してください。
B. 複数の正常性シグナルを一定数の正常条件で集約するなら計算済みヘルスチェックを評価する
C. プライベートアプリケーションのメトリクスを使うなら同一アカウントのCloudWatch アラームデータストリームをヘルスチェックへ利用できる
D. パブリックエンドポイントの到達性はエンドポイントヘルスチェックで評価できる
E. クロスアカウント CloudWatch アラームはヘルスチェックと同じように直接利用できる
F. 正常性シグナルの種類に関係なくDNS レコード値が自動的に監視対象になる
答えと解説
答え：B / C / D
障害範囲に応じてエンドポイント、計算済み、CloudWatch データストリームを使い分けます。クロスアカウント CloudWatch アラームは利用できません。
プライマリとセカンダリの両方にヘルスチェックを設定したフェイルオーバーレコードで、両方が異常になった。Amazon Route 53の基本動作はどれか?
B. NXDOMAINを返す
C. プライマリを返す
D. 両レコードを必ず同時に返す
答えと解説
答え：C
フェイルオーバールーティングでは両方異常の場合でもプライマリが返されます。両サイト異常はDNSだけでは解決できません。
プライベートアプリケーションのメトリクスからCloudWatch アラームを作りAmazon Route 53 ヘルスチェックへ接続したい。アラームは5個中3個のN個中M個で、メトリクス計算も利用している。最も適切な評価はどれか?
B. 計算済みヘルスチェックへ変更すれば任意のCloudWatch アラーム形式を直接利用できる
C. プライベートホストゾーンを使えばアラーム形式の制約はなくなる
D. Amazon Route 53連携に対応する標準解像度メトリクス / 基本統計のアラームへ正常性シグナルを組み直す
答えと解説
答え：D
Amazon Route 53 ヘルスチェックのCloudWatch アラーム連携には制約があり、N個中M個、メトリクス計算、高解像度メトリクス等は対象にできません。
DNS レコードは203.0.113.10を返すが、関連付けたAmazon Route 53 ヘルスチェックは198.51.100.20を監視している。Amazon Route 53はレコードの正常性判断に何を使うか?
B. ヘルスチェックで指定した198.51.100.20の正常性ステータスを使う
C. 2つのIPが一致しないのでレコード作成自体が拒否される
D. DNS クエリごとに両IPへ同期ヘルスチェックする
答えと解説
答え：B
非エイリアスレコードへ関連付けたヘルスチェックは、そのヘルスチェックで指定したエンドポイントの状態をレコード選択へ利用します。
ALBをエイリアス対象にしたAmazon Route 53 正常性 評価について正しいものを3つ選択してください。
B. ALB配下の各EC2インスタンスへAmazon Route 53 ヘルスチェックを必ず個別作成する
C. 対象を持つ対象グループに正常対象が存在するかがALBの正常性へ影響する
D. 評価対象正常性をはいにするとセカンダリサイトのキャパシティも自動プロビジョニングされる
E. 登録済みターゲットが0件の対象グループは異常として評価される
F. フェイルオーバールーティングではALBへのエイリアスレコードを利用できない
答えと解説
答え：A / C / E
Amazon Route 53はALB / 対象グループの正常性を利用できます。ELB配下インスタンスへ個別Amazon Route 53 ヘルスチェックを付ける設計ではありません。
エイリアスレコードへアプリケーションレベルの明示的ヘルスチェックを関連付け、同時に評価対象正常性もはいにした。レコードを正常として扱う条件として最も正しいものはどれか?
B. どちらか一方が正常なら必ず正常である
C. 明示的ヘルスチェックだけが評価されエイリアス対象正常性は無視される
D. 評価対象正常性だけが評価され明示的ヘルスチェックは無視される
答えと解説
答え：A
ヘルスチェックを関連付けたエイリアスで評価対象正常性も有効にすると、両条件を満たす必要があります。
ALBを指すAmazon Route 53 エイリアスレコードのDNS キャッシュ時間を短くするため、「エイリアスレコードのTTLを10秒へ変更する」案が出た。最も正しい評価はどれか?
B. 評価対象正常性を無効にすればエイリアス TTLを自由に設定できる
C. AWSリソース向けエイリアスはレコード自体にTTLを設定せず、対象側TTLを利用する
D. エイリアスレコードにはDNS キャッシュが存在しないためTTLは考慮不要である
答えと解説
答え：C
AWSリソースエイリアスではエイリアスレコード自体へTTLを設定できません。エイリアス先が同一ホスト型ゾーンの別レコードなら対象レコードのTTLを利用します。
Amazon Route 53がセカンダリを返す状態になったが、一部クライアントの復旧がビジネス RTOを超えた。最も適切な評価はどれか?
B. エイリアスを使用しているためDNS キャッシュと接続動作は無視できる
C. セカンダリが正常ならクライアント再試行はRTOへ影響しない
D. DNS キャッシュ、クライアント再試行、セカンダリ準備状態までRTOに含める
答えと解説
答え：D
DNS 答え変更は復旧チェーンの一部です。キャッシュ、再接続、復旧サイトの処理可能性まで含めます。
プライマリサイトが復旧した直後、データベース整合性確認はまだ完了していない。フェイルオーバールーティングで安全にプライマリへ戻すため最も適切な設計はどれか?
B. データ / 依存関係 / トランザクションの準備状態を正常条件にする
C. プライマリのヘルスチェックを削除して常にプライマリを返す
D. セカンダリのDNS レコードを削除してフェイルバックを強制する
答えと解説
答え：B
プライマリが正常になると再び優先されるため、正常性シグナルをフェイルバックゲートとして利用します。
DNS フェイルオーバー後も障害前からプライマリへ確立済みだった長時間接続が失敗した。最も適切な説明はどれか?
B. 評価対象正常性がはいなら既存接続も必ず維持される
C. DNS フェイルオーバーは新しい名前解決先を変更するもので既存接続を移送しない
D. 計算済みヘルスチェックを使えば既存接続もセカンダリへ移せる
答えと解説
答え：C
既存接続のタイムアウト / 再試行 / 再接続はアプリケーションやクライアント側の動作です。
プライベートアプリケーションを含むアクティブ-パッシブアーキテクチャでAmazon Route 53 フェイルオーバーを設計する。ビジネス RTOを満たすため適切な設計を4つ選択してください。
B. ヘルスチェックが異常になった時刻だけをビジネス RTOの終了点とする
C. 復旧サイトのアプリケーション / データ / 依存関係がトラフィックを処理可能か確認する
D. エイリアス対象を使う場合は評価対象正常性や明示的ヘルスチェックの組み合わせを設計する
E. DNS切替後は既存接続も自動移送される前提で再試行設計を省略する
F. DNS キャッシュとクライアント再試行 / 再接続を復旧時間へ含める
答えと解説
答え：A / C / D / F
正常性シグナル、復旧サイト準備状態、DNS切替とクライアント接続の挙動を一続きでRTOへ含めます。
Amazon Route 53はセカンダリサイトを正常として選択できるが、セカンダリのデータベースレプリケーションは停止しアプリケーションキャパシティも不足している。最も適切な評価はどれか?
B. Amazon Route 53がデータベースレプリケーションとコンピューティングキャパシティを自動補完する
C. エイリアスレコードへ変更すればセカンダリのデータ不整合も解消する
D. プライマリレコードのTTLを削除すればセカンダリのキャパシティ不足も解消する
答えと解説
答え：A
Amazon Route 53は復旧サイトを作りません。ビジネストランザクションを処理できる状態まで別途設計します。