Q1 — 単一選択既存ECサイトの注文処理について信頼性をレビューしている。リソース一覧では、Amazon EC2、Amazon RDS、認証サービス、決済サービスなどが正常稼働している。しかし、どの依存先の障害が注文受付全体へ影響するかは整理されていない。次に行うべき評価として最も適切なのはどれですか。
A. 各AWSリソースの稼働率だけを個別に確認し、その平均値を注文機能の信頼性とする
B. 注文処理の開始から完了までを追跡し、各処理段階の必須依存関係と障害時の業務影響を整理する
C. 使用しているAWSサービス数を数え、サービス数が多いほど信頼性が高いと判断する
D. 料金の高いリソースだけを抽出し、それらに障害履歴がなければレビューを終了する
答えと解説
答え：B
リソースが個別に正常でも、業務経路上の必須依存関係が停止したときに注文処理全体がどう影響を受けるかは分かりません。処理経路を追跡し、依存関係と障害影響を対応付けて評価します。
Q2 — 複数選択：3つ選択注文サービスの信頼性をレビューしている。アプリケーションはAZ-A / AZ-Bに分散されている。調査すると、可用性目標99.95%に対し実績99.80%、認証サービスはAZ-A内の経路へ依存し、過去2回の認証障害時に注文受付が停止していた。既存アーキテクチャの信頼性が不十分である根拠として適切なものを3つ選択してください。
A. 注文機能の可用性実績が目標を下回っている
B. アプリケーションが2つのAZにあるため、依存関係の配置は確認する必要がない
C. 注文に必須の認証依存関係が1つの障害ドメインへ偏っている
D. 過去の認証障害が実際に注文機能停止へつながっている
E. 障害履歴が2件しかないため、アーキテクチャ評価には使用できない
F. 複数AZという名称だけで要求を満たしていると判断できる
答えと解説
答え：A / C / D
可用性実績、依存関係と障害ドメイン、実際の障害影響を組み合わせることで、アーキテクチャ上の信頼性不足を証拠付きで特定できます。
Q3 — 単一選択障害・復旧テストで2つの処理経路を確認した。経路Aでは1台の処理ノードを停止してもトラフィックが正常な経路へ自動的に切り替わり、利用者の注文処理は継続した。経路Bでは依存コンポーネントを停止すると注文処理が停止し、運用担当者が障害を検知して手動で切り替えるまで復旧しなかった。既存アーキテクチャの評価として最も適切なのはどれですか。
A. 両方とも最終的には復旧できるため、レジリエンス上の違いはない
B. 経路Aは障害を吸収できているが、経路Bには手動介入へ依存する信頼性上の弱点がある
C. 経路Aでもコンポーネント障害が発生したため、利用者影響に関係なく信頼性不足とする
D. 経路Bは担当者が復旧できるため、障害時の停止はアーキテクチャ評価から除外する
答えと解説
答え：B
信頼性評価では、障害の発生そのものだけでなく、その後に業務機能を継続・回復できるかを確認します。自動的に正常経路へ継続できる経路と、手動介入まで業務が停止する経路では、現在のレジリエンスが異なります。
Q4 — 単一選択直近3回の障害では、認証エラー、注文APIタイムアウト、決済開始失敗という異なる症状が発生した。確認すると、3件とも同じ共通依存サービスの劣化が起点となり、その影響が複数の業務機能へ伝播していた。最も適切な評価はどれですか。
A. 表面上の症状が異なるため、3件を無関係な障害として扱う
B. 障害件数だけを記録し、共通する依存関係は評価しない
C. 共通依存先から複数業務へ影響が広がる信頼性上の弱点として記録する
D. 運用担当者の対応時間だけを比較し、業務への影響は評価しない
答えと解説
答え：C
異なる症状でも共通依存関係の障害から複数の業務機能へ影響が伝播しているなら、アーキテクチャ上の共通した信頼性不足として評価します。