Q1 — 単一選択大型キャンペーン中も購入離脱を増やさず、必要な注文量を処理し、注文機能を利用可能に保つというビジネス要件がある。KPIを定義する方法として最も適切なのはどれですか。
A. レイテンシーだけをKPIにし、処理量と可用性は別途判断しない
B. CPU使用率とメモリ使用率だけをKPIにしてビジネス要件の達成を判断する
C. 購入処理の速さ、必要な処理量、可用性を成功条件として分け、それぞれをKPIへ対応付ける
D. 利用するAWSサービスを先に決定し、そのサービスが提供するメトリクスをすべてKPIにする
答えと解説
答え：C
1つのビジネス要件に複数の成功条件が含まれる場合、要件を成功条件へ分解し、それぞれを直接確認できるKPIへ対応付けます。
Q2 — 単一選択ある注文サービスでは、内部で注文APIの応答時間と注文成功率を継続監視している。一方、顧客とは月間可用性99.95%を提供することで合意している。最も適切な整理はどれですか。
A. 応答時間と注文成功率は内部KPI、合意した月間可用性99.95%はSLAとして扱う
B. 応答時間、注文成功率、月間可用性はすべて顧客SLAとして同じ基準で扱う
C. 顧客と合意した月間可用性だけをKPIとし、内部の応答時間と成功率は監視しない
D. KPIとSLAは同じ意味なので、内部監視と顧客合意を区別する必要はない
答えと解説
答え：A
内部KPIは目標達成や改善状況を判断するための指標です。顧客と合意したサービス水準はSLAとして扱い、目的と判定基準を分けます。
Q3 — 単一選択顧客契約で「購入APIの応答時間を合意水準以内に保つ」ことを明示する予定である。この性能条件をSLAとしてどのように扱うべきですか。
A. SLAは可用性だけを対象とするため、応答時間は内部KPIとしてのみ管理する
B. 応答時間は性能メトリクスなので、顧客との合意内容に関係なくSLAから除外する
C. 顧客へ提供する性能水準として合意するなら、応答時間の条件もSLAの対象にできる
D. 応答時間をSLAに含める場合は、可用性のKPIを内部監視から外す
答えと解説
答え：C
SLAは可用性だけに限定されません。顧客へ提供する性能水準として明示的に合意するなら、応答時間などの性能条件もSLAの対象になり得ます。
Q4 — 単一選択既存ワークロードについて複数の改善案を比較している。後から各改善案がどのビジネス成果へ寄与するのか確認できるようにしたい。最も適切な方法はどれですか。
A. 採用候補のAWSサービス名だけを記録し、ビジネス要件との対応は残さない
B. CPUやメモリなどの内部メトリクスだけを一覧化し、上位要件とは分離する
C. SLAだけを独立して管理し、KPIや目標値との関係は記録しない
D. ビジネス要件からKPI、目標値、必要なSLAまでの対応関係を保持する
答えと解説
答え：D
要件からKPI、目標値、必要なSLAまでを対応付けておけば、改善案がどのビジネス成果へ効くのかを後から追跡できます。
Q5 — 単一選択あるサービスについて、可用性99.95%をSLA案として提示している。しかし、どのサービスを対象にするか、どの評価期間で99.95%を判定するかはまだ決まっていない。次に行うべきことはどれですか。
A. 99.95%という数値が決まっているため、そのままSLAとして確定する
B. 対象サービスと評価期間を明確にし、99.95%をどの範囲で評価するか定義する
C. 可用性の代わりにレイテンシーを採用し、同じ99.95%を目標値として利用する
D. AWSサービス側のSLAをそのまま利用し、ワークロード側では評価条件を定義しない
答えと解説
答え：B
SLAは数値だけでは十分ではありません。対象サービスと評価期間を含め、どの範囲をどの条件で評価するのかを明確にします。
Q6 — 単一選択あるワークロードでは、レイテンシー、スループット、可用性を内部KPIとして監視している。現在、レイテンシーは内部KPIの目標値を超過しているが、顧客と合意したSLAの違反条件にはまだ達していない。どのように判断すべきですか。
A. 内部KPIが未達になった時点で、顧客SLAにも違反したと判定する
B. 顧客SLAに違反していないため、内部KPIの未達は無視する
C. 内部KPIとSLAのうち、より厳しい基準だけを共通の判定条件として使う
D. 内部KPI未達として改善を検討し、SLA違反は合意したSLA基準で別に判定する
答えと解説
答え：D
内部KPIは早期改善のための基準として、顧客SLAは合意したサービス水準の違反判定として、それぞれ別の基準で評価します。