Q1 — 単一選択Auto Scaling グループが次の状態です。
最小 = 2 / 希望 = 4 / 最大 = 8
1台が異常と判断され、置き換えが開始されました。その直後、スケジュールされたアクションによって希望するキャパシティが4から6へ変更されました。最も適切な説明はどれですか。
A. 置き換え開始時の希望するキャパシティ4が固定されるため、置き換え完了まで6への変更は反映されない
B. 置き換えと希望するキャパシティ変更は並行して進むことがあり、グループは変更後の希望するキャパシティ6を満たす方向で制御される
C. 異常インスタンスの置き換えが始まると、希望するキャパシティは自動的に1増えて5となり、スケジュールされたアクションは無視される
D. スケジュールされたアクションが実行されると、異常インスタンスは正常として扱われ、置き換え処理は自動的に解除される
答えと解説
答え：B
置き換え処理とスケーリングやスケジュールされたアクションは並行して動作する場合があります。希望するキャパシティが6へ変更されたなら、置き換え開始時の4へ固定するのではなく、その時点の希望するキャパシティを基準に制御されます。
Q2 — 単一選択次の設定で高負荷が継続しています。
最小 = 2 / 希望 = 6 / 最大 = 6
ターゲット追跡スケーリングポリシーが追加キャパシティを必要と判断しています。最も重要な問題はどれですか。
A. 最大キャパシティが現在の希望するキャパシティと同じため、それ以上へ希望するキャパシティを増やせない
B. ターゲット追跡では最大キャパシティを一時的に超えて追加できるため、上限値の見直しは不要である
C. 最大キャパシティは異常インスタンス置き換え時の上限だけに使われ、動的スケーリングには影響しない
D. ヘルスチェック猶予期間を延長すれば、負荷に応じて最大キャパシティも自動的に引き上げられる
答えと解説
答え：A
スケーリングポリシーによる希望するキャパシティ変更も、設定された最大キャパシティの制限を受けます。
Q3 — 複数選択：3つ選択Auto Scaling グループの制御について正しいものを3つ選んでください。
A. スケーリングポリシーは、条件に応じて希望するキャパシティを変更できる
B. 異常インスタンスを置き換えるたびに、希望するキャパシティは必ず1増える
C. 低負荷時にも可用性要件上必要なキャパシティを残せるよう、最小キャパシティを設定する
D. 最大キャパシティは、ヘルスチェック失敗を検出するしきい値として使用される
E. Auto Scaling グループは、予期しない終了後にも現在の希望するキャパシティを維持しようとする
F. 希望するキャパシティは、最小・最大キャパシティとは無関係に変更できる
答えと解説
答え：A / C / E
希望するキャパシティは最小〜最大の範囲で変更されます。最小キャパシティは単なるコスト上の下限ではなく、低負荷時にも維持したい可用性上の最低キャパシティを考慮して設定します。
Q4 — 単一選択次のうち、スケジュールされたスケーリングを最も直接的に選ぶシナリオはどれですか。
A. CPU使用率を50%付近に保つよう、実際の負荷に応じてキャパシティを継続的に調整したい
B. CloudWatchアラームの超過量に応じて、追加または削減するキャパシティ量を段階的に変えたい
C. 毎週月曜日09:00に開始する定例処理に合わせて、事前にキャパシティを増やしたい
D. 過去の需要パターンを使用して、将来必要になるキャパシティを事前に予測したい
答えと解説
答え：C
時刻が事前に確定しているため、スケジュールされたスケーリングが直接的です。Aはターゲット追跡、Bはステップスケーリング、Dは予測スケーリングに対応します。
Q5 — 単一選択ワーカー群へターゲット追跡スケーリングを設定する。台数を増やしたときに1台あたりの負荷が下がり、台数を減らすと負荷が上がるような指標を目標値へ維持したい。選ぶべきメトリクスの性質として最も適切なのはどれか。
A. キャパシティを増減しても値がほとんど変化しないメトリクス
B. キャパシティを増やすと、1台あたりの負荷などが期待する方向へ変化するメトリクス
C. インスタンスの正常・異常だけを表し、需要量を表さないメトリクス
D. Auto Scaling グループとは無関係な全社売上総額などのメトリクス
答えと解説
答え：B
ターゲット追跡では、キャパシティ変更との関係を持ち、目標値へ制御できるメトリクスを選びます。
Q6 — 複数選択：3つ選択新しいインスタンスがInServiceになったあと、アプリケーションが利用可能になるまで3分かかります。Auto Scalingの初期化中の制御について正しいものを3つ選んでください。
A. ヘルスチェック猶予期間は、初期化中の追加ヘルスチェック失敗によって新規インスタンスが早期終了されることを抑えるために利用できる
B. デフォルトのインスタンスウォームアップは、新しいキャパシティをスケーリングや置き換え制御上いつ準備完了として扱うかに関係する
C. ヘルスチェック猶予期間中でも、Amazon EC2 Auto ScalingがインスタンスをEC2のrunning状態ではないと検出した場合は、異常として置き換え対象になる
D. ヘルスチェック猶予期間を初期化時間に合わせれば、デフォルトのインスタンスウォームアップを設定する必要はない
E. デフォルトのインスタンスウォームアップを設定すれば、Elastic Load Balancingのヘルスチェック失敗による早期終了も同じ設定で抑止できる
答えと解説
答え：A / B / C
ヘルスチェック猶予期間とデフォルトのインスタンスウォームアップは役割が異なります。また猶予期間はすべての異常を無視する期間ではなく、EC2のrunning状態を失ったことをAuto Scalingが検出した場合は、猶予期間中でも即時置き換え対象になります。
Q7 — 単一選択希望するキャパシティが10のAuto Scaling グループで、インスタンスメンテナンスポリシーを最小正常率90%、最大正常率120%に設定しています。置き換え中、正常かつ利用準備完了のInServiceが9、さらに新しく起動したPendingが2あります。最も適切な説明はどれですか。
A. 置き換えを続行できる。最小正常率は正常かつ利用準備完了の9で満たし、最大正常率では正常なInService 9とPending 2の合計11が上限12以内となる
B. 置き換えを続行できない。Pendingは最大正常率の計算に含まれないため、正常なInServiceだけで上限側の12を満たすまで待つ必要がある
C. 置き換えを続行できない。最大正常率120%は希望するキャパシティを12へ変更する設定なので、希望する10の状態では置き換えを進められない
D. 置き換えを続行できる。Pendingも最小正常率の利用準備完了キャパシティへ含まれるため、9と2の合計11で下限9を満たしている
答えと解説
答え：A
最小正常率90%では、希望する10に対して正常・InService・利用準備完了の9が必要です。一方、最大正常率120%の上限判定には正常なInServiceとPendingが含まれるため、この状態は11で上限12以内です。Pendingは最小正常率の利用準備完了には数えません。
Q8 — 単一選択インスタンスを置き換える際、可用性を優先して新しいインスタンスを準備してから既存インスタンスを終了したい場合、最も直接関係する設定はどれですか。
A. ターゲット追跡の目標値を調整し、通常の負荷変化として希望するキャパシティを増加させる
B. インスタンスメンテナンスポリシーで、置き換え中に維持・許容するキャパシティ範囲を調整する
C. 最小キャパシティだけを引き上げ、置き換え時の正常キャパシティ上限は変更しない
D. ヘルスチェック猶予期間を延長し、既存インスタンスを終了する前後関係を制御する
答えと解説
答え：B
インスタンスメンテナンスポリシーの最小正常率・最大正常率を使い、置き換え時の可用性と一時的追加キャパシティのバランスを制御します。
Q9 — 単一選択新規インスタンスはInServiceになったあともアプリケーション初期化に時間がかかります。Elastic Load Balancingのヘルスチェックに準備完了前から失敗して繰り返し終了され、動的スケーリングでも初期化途中の新規インスタンスを早く評価しすぎています。最も適切な組み合わせはどれですか。
A. 異常判定側はヘルスチェック猶予期間、スケーリング側はデフォルトのインスタンスウォームアップを確認する
B. 異常判定側はインスタンスメンテナンスポリシー、スケーリング側は最大キャパシティを確認する
C. 異常判定側は予測スケーリング、スケーリング側はヘルスチェック猶予期間を確認する
D. 異常判定側は最小正常率、スケーリング側は最大正常率だけを調整する
答えと解説
答え：A
Elastic Load Balancingのヘルスチェックによる準備完了前の早すぎる終了にはヘルスチェック猶予期間、新規キャパシティをスケーリング制御へ反映する時期にはデフォルトのインスタンスウォームアップを確認します。