I85PREP
⌘ K
NHN Cloud Associate study materials
NHN Cloud Associate study resources

NHN Cloud Associate practice questions

One question at a time. Build your NHN Cloud Associate understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Compute

NHN Cloud のインスタンス作成時にキーペアを指定する主な目的はどれですか。

  1. インスタンスの課金を停止するため
  2. ロードバランサのヘルスチェックを有効にするため
  3. SSH 公開鍵認証でインスタンスに接続するため Correct answer.
  4. ブロックストレージを自動拡張するため

Explanation

キーペアは公開鍵と秘密鍵の組で、インスタンス作成時に公開鍵が登録され、SSH 接続時の本人確認に使われます。課金制御やストレージ拡張、ヘルスチェックとは無関係です。

Question 2Compute

NHN Cloud のインスタンスタイプで「flavor」が主に表すものはどれですか。

  1. データベースのバックアップ周期
  2. リージョン間のネットワーク遅延
  3. オブジェクトストレージの保存容量
  4. 仮想マシンの vCPU 数とメモリ量の組み合わせ Correct answer.

Explanation

flavor はインスタンスの性能仕様を表し、一般的に vCPU 数とメモリ量の組み合わせで定義されます。ネットワーク遅延やストレージ容量、バックアップ周期は flavor の要素ではありません。

Question 3Compute

インスタンスに接続するためのセキュリティグループのルールとして適切な設定はどれですか。

  1. 受信ルールのみ設定すれば送信は自動で全許可されるので考慮不要である
  2. SSH を許可する場合、接続元を特定の IP 範囲に限定して 22 番ポートを開放する Correct answer.
  3. セキュリティグループは削除すると通信が速くなるため常に空にする
  4. すべてのポートを 0.0.0.0/0 に開放して利便性を優先する

Explanation

セキュリティグループは許可ベースの仮想ファイアウォールであり、必要なポートだけを必要な送信元に限定して開放するのが基本です。全開放は攻撃面を広げ、空にすると通信自体が成立しません。

Question 4Compute

NHN Cloud でインスタンスを停止したときの一般的な挙動として正しいものはどれですか。

  1. 停止するとフローティング IP が自動的に解放され二度と再割り当てできない
  2. 停止中もコンピュート課金は稼働時と同額発生する
  3. 停止するとインスタンスとブロックストレージの両方が自動削除される
  4. 停止中はコンピュート課金が発生しないが、接続されたブロックストレージの課金は継続する Correct answer.

Explanation

インスタンスを停止するとコンピュートリソースの課金は止まりますが、ブロックストレージは保持されるため容量に対する課金が続きます。停止は削除ではないため、リソースが自動削除されることはありません。

Question 5Compute

インスタンスの初期ログインユーザー名として一般的に使われるものはどれですか。

  1. nhncloud 固定
  2. root またはイメージに応じた既定ユーザー Correct answer.
  3. guest 固定
  4. administrator 固定

Explanation

Linux 系イメージでは root やイメージごとに定義された既定ユーザーでログインするのが一般的です。固定の特別なユーザー名が全イメージ共通で使われるわけではありません。

Question 6Compute

インスタンスに追加のデータディスクをアタッチした直後に必要な作業はどれですか。

  1. セキュリティグループを削除する
  2. ゲスト OS 側でパーティション作成とファイルシステムの作成を行う Correct answer.
  3. インスタンスを削除して再作成する
  4. 何もせず即座にデータが書き込める

Explanation

追加ボリュームはブロックデバイスとして接続されるだけで、利用には OS 側でパーティション作成やファイルシステム作成、マウントが必要です。接続しただけでは自動的にファイルシステムが用意されるわけではありません。

Question 7Compute

インスタンスの自動スケール構成で、負荷に応じて台数を増減させるために用いるサービスはどれですか。

  1. DNS Plus
  2. Object Storage
  3. Auto Scale Correct answer.
  4. Cloud Trail

Explanation

Auto Scale はインスタンスグループの台数を負荷やスケジュールに応じて自動で増減させるサービスです。Object Storage は保存、Cloud Trail は監査ログ、DNS Plus は名前解決を担います。

Question 8Compute

インスタンスのイメージから新しいインスタンスを作るために事前に作成しておくべきものはどれですか。

  1. ロードバランサのリスナー
  2. フローティング IP の追加申請
  3. 該当インスタンスのカスタムイメージ Correct answer.
  4. NAT ゲートウェイ

Explanation

稼働中のインスタンスの状態を複製するには、そのインスタンスからカスタムイメージを作成し、それを基に新規インスタンスを起動します。IP やロードバランサ、NAT はイメージ作成の前提条件ではありません。

Question 9Compute

プライベートサブネット内のインスタンスが外部へソフトウェア更新を行うために必要な構成はどれですか。

  1. セキュリティグループの全ポートを開放する
  2. NAT ゲートウェイをパブリックサブネットに配置し、プライベート側のルートを向ける Correct answer.
  3. インスタンスをパブリックサブネットへ移動せずに DNS を停止する
  4. すべてのインスタンスにフローティング IP を付与する

Explanation

プライベートサブネットから外部へ出るには、パブリックサブネット上の NAT ゲートウェイを経由するルートを設定します。フローティング IP を全台に付ける方法は公開範囲が広がり過ぎ、セキュリティ上も非効率です。

Question 10Compute

インスタンスの負荷分散構成で、ヘルスチェックに失敗したインスタンスの扱いとして正しいものはどれですか。

  1. ロードバランサはそのインスタンスへのトラフィック送信を停止する Correct answer.
  2. ロードバランサはそのインスタンスを自動で削除する
  3. ロードバランサはヘルスチェックを無効化して送信を続ける
  4. ロードバランサは全インスタンスへの送信を停止する

Explanation

ヘルスチェックに失敗したメンバーは一時的に分散対象から外され、正常なメンバーにのみトラフィックが送られます。インスタンス自体の削除や全体停止は行われません。

Question 11Compute

インスタンスのスケールアップとスケールアウトの違いの説明として正しいものはどれですか。

  1. スケールアップは台数を増やし、スケールアウトは性能を下げる
  2. スケールアップはインスタンスの性能を上げ、スケールアウトは台数を増やす Correct answer.
  3. 両者は同じ意味で、台数の増加のみを指す
  4. スケールアウトはストレージ容量の拡張のみを指す

Explanation

スケールアップは vCPU やメモリを増やして単体の処理能力を高める操作で、スケールアウトはインスタンス台数を増やして処理を分散する操作です。両者は目的が異なり、同一の意味ではありません。

Question 12Compute

インスタンスに付与するフローティング IP の説明として正しいものはどれですか。

  1. インスタンスに関連付けたり解除したりできる外部公開用の IP アドレス Correct answer.
  2. ロードバランサ専用の仮想 IP アドレス
  3. サブネットの CIDR を定義するためのアドレス
  4. インスタンス作成時に固定され変更できない内部 IP アドレス

Explanation

フローティング IP は外部から到達可能な IP で、インスタンスへの関連付けや解除が可能です。内部 IP やサブネットの CIDR、ロードバランサの仮想 IP とは役割が異なります。

Question 13Compute

NHN Cloud のイメージに含まれないものはどれですか。

  1. OS のルートファイルシステム
  2. ユーザーが後から作成したデータディスクの内容 Correct answer.
  3. インスタンス起動に必要な基本設定
  4. イメージ作成元の OS 種別情報

Explanation

イメージは OS のルートボリュームと起動に必要な基本設定を含みますが、別途アタッチしたデータディスクの内容は通常含まれません。データはデータディスク側に残るため、別途バックアップが必要です。

Question 14Compute

セキュリティグループのルール評価に関する説明として正しいものはどれですか。

  1. 複数のセキュリティグループを適用すると最後に適用した一つだけが有効になる
  2. 拒否ルールを書かなくてもすべての通信が許可される
  3. 許可ルールに一致しない通信は既定で拒否される Correct answer.
  4. ルールは送信元 IP を無視してポート番号だけで評価される

Explanation

セキュリティグループは許可した通信のみを通す許可ベースの制御で、一致しない通信は拒否されます。評価ではプロトコル、ポート、送信元・送信先が考慮され、複数グループのルールは合算されます。

Question 15Compute

インスタンスのモニタリングで CPU 使用率の急上昇を検知して通知を受け取りたい場合に適した構成はどれですか。

  1. インスタンスのキーペアを再生成する
  2. 監視サービスでメトリクスに対するしきい値と通知先を設定する Correct answer.
  3. ブロックストレージの容量を減らす
  4. セキュリティグループのルールを全削除する

Explanation

CPU 使用率などのメトリクスに対してしきい値を設定し、超過時に通知を送る監視設定が適切です。キーペアやストレージ、セキュリティグループの操作は負荷検知や通知とは関係ありません。

Question 16Compute

同じイメージから複数のインスタンスを同時に起動した場合の説明として正しいものはどれですか。

  1. 起動できるインスタンスは常に 1 台に制限される
  2. ルートボリュームは読み取り専用となり書き込みできない
  3. すべてのインスタンスが同一のルートボリュームを共有する
  4. 各インスタンスは独立したルートボリュームを持ち、一方の変更は他方に影響しない Correct answer.

Explanation

イメージから起動した各インスタンスは、イメージを複製した独立のルートボリュームを持ちます。そのため一つのインスタンスでの変更が他のインスタンスへ波及することはありません。

Question 17Compute

インスタンスの復旧を目的としたスナップショットの説明として正しいものはどれですか。

  1. インスタンスのネットワーク設定のみを保存する
  2. ある時点のブロックストレージの状態を保存し、後から復元に利用できる Correct answer.
  3. OS のログのみを圧縮して保存する
  4. 課金情報を保存して請求額を確定させる

Explanation

スナップショットはブロックストレージのある時点の状態を保存し、障害時やロールバック時に復元するために使います。ネットワーク設定やログ、課金情報の保存を目的とするものではありません。

Question 18Compute

インスタンスの起動に失敗し、キーペアの設定を見直したい場合の対応として適切なものはどれですか。

  1. インスタンスを停止し、コンソール機能やイメージ再作成などの手段でアクセス手段を回復する Correct answer.
  2. フローティング IP を削除する
  3. 起動中のままセキュリティグループを全開放して待つ
  4. データディスクをデタッチして課金を止める

Explanation

キーペアやログイン情報に問題がある場合は、インスタンスを停止してコンソール接続やイメージからの再作成などでアクセス手段を回復します。セキュリティグループの全開放や IP 削除は原因の解決になりません。

Question 19Compute

ロードバランサ配下のインスタンスをメンテナンスで一時的に切り離したい場合の適切な方法はどれですか。

  1. 全インスタンスのセキュリティグループを変更する
  2. 該当メンバーを分散対象から除外し、作業後に戻す Correct answer.
  3. インスタンスを削除して作り直す
  4. ロードバランサ自体を削除する

Explanation

メンテナンス対象のメンバーだけを分散対象から外せば、他のメンバーで処理を継続したまま作業できます。ロードバランサ全体の削除やインスタンスの再作成は影響範囲が大き過ぎます。

Question 20Compute

インスタンスタイプの変更を検討する際の判断として最も適切なものはどれですか。

  1. ネットワーク遅延が増えた場合に flavor を小さくする
  2. ディスク容量が不足した場合に flavor を変更する
  3. CPU 使用率が恒常的に高くメモリ不足が続く場合に、より大きい flavor への変更を検討する Correct answer.
  4. 一時的なアクセス増加のたびに常に最大の flavor を選ぶ

Explanation

恒常的な CPU やメモリの不足は、より大きい flavor への変更で解消できる可能性があります。ディスク容量はボリューム拡張で対応し、一時的な増加はスケールアウトで吸収するのが適切です。

Question 21Compute

プライベートサブネットのインスタンスへ管理者が SSH 接続する構成として適切なものはどれですか。

  1. プライベートサブネットの CIDR をインターネットに公開する
  2. 全インスタンスにフローティング IP を付与して直接公開する
  3. セキュリティグループで 22 番ポートを全送信元に開放する
  4. パブリックサブネットの踏み台インスタンスを経由して接続する Correct answer.

Explanation

プライベートサブネットのインスタンスは直接外部から到達できないため、パブリックサブネット上の踏み台を経由して接続する構成が一般的です。CIDR の公開や全開放はセキュリティを損ないます。

Question 22Compute

Auto Scale グループで最小 2 台、最大 6 台、目標 CPU 使用率 60% と設定した場合の挙動として正しいものはどれですか。

  1. 負荷に関係なく常に 6 台を維持する
  2. CPU 使用率が 60% を超えるとインスタンスの flavor が自動で拡張される
  3. 負荷が下がっても台数は 2 台を下回らず、上がっても 6 台を超えない Correct answer.
  4. 負荷が下がると 0 台まで減り、すべてのインスタンスが停止する

Explanation

Auto Scale グループでは最小台数と最大台数が境界として機能し、スケーリングはその範囲内で行われます。目標値に基づく増減は台数の調整であり、flavor の変更は行われません。

Question 23Compute

インスタンスのルートボリュームを誤って初期化した場合の復旧手順として最も適切なものはどれですか。

  1. キーペアを再生成して再ログインする
  2. セキュリティグループのルールを再設定する
  3. 事前に取得したスナップショットからボリュームを復元し、インスタンスに接続し直す Correct answer.
  4. フローティング IP を付け替える

Explanation

初期化で失われたデータは、事前に取得したスナップショットからボリュームを復元することで回復できます。ネットワーク設定や認証情報の変更はデータの復旧には寄与しません。

Question 24Compute

複数のインスタンスで構成する Web 層の設計で、セッション情報を各インスタンスのローカルに保持した場合に生じる問題はどれですか。

  1. セキュリティグループのルールが自動で削除される
  2. 利用者が別のインスタンスに振り分けられるとセッションが失われる Correct answer.
  3. インスタンスの flavor が自動的に変更される
  4. ロードバランサのヘルスチェックが必ず失敗する

Explanation

セッションをローカルに持つと、ロードバランサが別のインスタンスへ振り分けた際にセッション情報を参照できず、ログアウトや再ログインが発生します。共有ストアやスティッキーセッションなどの対策が必要です。

Question 25Compute

インスタンスの監視で、平均 CPU 使用率が 5 分間 80% を超えた場合のみアラートを出したいときの設定として適切なものはどれですか。

  1. しきい値を設定せず全メトリクスで通知する
  2. 評価期間を 1 秒とし、しきい値を 1% 超として設定する
  3. 評価期間を 5 分とし、しきい値を 80% 超、条件を平均値として設定する Correct answer.
  4. 平均値ではなく最大値のみを無条件に通知する

Explanation

短時間のスパイクを除外して継続的な高負荷を検知するには、評価期間と集計方法を指定したうえでしきい値を設定します。極端に短い期間や無条件通知では誤検知が増えます。

Question 26Compute

NHN Cloud の Instance サービスで、インスタンスの作成時に指定する「キーペア」の説明として正しいものはどれですか。

  1. インスタンス間の通信を暗号化する TLS 証明書の組であり、ロードバランサにのみ登録される
  2. インスタンスの暗号化ボリュームを復号するための共通鍵であり、全インスタンスで同一のものを使用する
  3. インスタンスの管理者パスワードを自動生成するための乱数シードであり、作成後に再発行できる
  4. インスタンスへの SSH 接続に用いる公開鍵と秘密鍵の組であり、公開鍵はインスタンス内に登録される Correct answer.

Explanation

キーペアは SSH 公開鍵認証に使う鍵の組で、公開鍵がインスタンスに注入され、利用者は手元の秘密鍵でログインします。秘密鍵はダウンロード時のみ取得でき、後から同じ内容を再発行することはできません。

Question 27Compute

NHN Cloud の Instance で、インスタンスのタイプを変更する操作の説明として正しいものはどれですか。

  1. インスタンスを稼働したままタイプを変更でき、再起動は不要である
  2. インスタンスを停止した状態でインスタンスタイプの変更を要求し、反映後に起動する Correct answer.
  3. タイプ変更のたびに新しいインスタンスを作成し、旧インスタンスは自動削除される
  4. タイプ変更はイメージの再登録によってのみ行われ、インスタンス側の操作は不要である

Explanation

インスタンスタイプの変更は停止状態のインスタンスに対して行い、変更完了後に再度起動する流れになります。稼働中のままでは CPU やメモリの割り当てを切り替えられません。

Question 28Compute

NHN Cloud の Instance で、インスタンスに接続するための「 Floating IP 」の割り当てについて正しい説明はどれですか。

  1. Floating IP はインスタンスに直接割り当てられ、インスタンスを停止すると自動的に解放される
  2. Floating IP はプロジェクト単位で確保され、インスタンスとは独立して課金され、割り当て先を付け替えられる Correct answer.
  3. Floating IP はロードバランサにのみ割り当て可能で、インスタンスには付与できない
  4. Floating IP はサブネットごとに 1 つだけ確保でき、複数インスタンスで同時に共有して使用する

Explanation

Floating IP はプロジェクトに確保するリソースで、インスタンスとは独立して管理・課金され、必要に応じて別のインスタンスへ付け替えられます。インスタンスを削除しても Floating IP 自体は残るため、明示的に解放する必要があります。

Question 29Compute

NHN Cloud の Instance で、インスタンスのブートボリュームに用いるイメージの選択に関する説明として正しいものはどれですか。

  1. イメージの選択はボリュームタイプに影響せず、どのイメージでも同じディスク構成になる
  2. イメージはインスタンス起動後に管理コンソールから自由に差し替えられ、再起動のみで反映される
  3. イメージは作成後に変更できず、別イメージへ切り替えるにはインスタンスの再作成が必要である Correct answer.
  4. イメージはインスタンスのネットワーク設定を決定するものであり、OS の内容とは関係しない

Explanation

ブートボリュームの元になるイメージはインスタンス作成時に決まり、後から別イメージへ差し替えることはできません。OS を変えたい場合は新しいインスタンスを作成する必要があります。

Question 30Compute

NHN Cloud の Instance で、インスタンスに追加したデータボリュームを OS から利用できるようにするための作業として適切なものはどれですか。

  1. インスタンスを再作成してイメージにボリュームを焼き込み、起動時に自動マウントさせる
  2. インスタンス内でパーティション作成とファイルシステムの作成を行い、任意のパスにマウントする Correct answer.
  3. 管理コンソールでボリュームを「使用」状態に変更するだけで、OS 側の操作は不要である
  4. セキュリティグループにボリューム用のポートを追加し、該当ポートを開放する

Explanation

追加したデータボリュームは、インスタンスからは未フォーマットのブロックデバイスとして見えるため、パーティション作成・ファイルシステム作成・マウントを行って初めて利用できます。マウント設定を永続化するには fstab などへの登録も必要です。

Question 31Compute

NHN Cloud の Instance で、同じイメージから同一構成のインスタンスを複数台用意したい場合に最も適切な方法はどれですか。

  1. 1 台目のインスタンスから 이미지를 생성하고、その 이미지로 필요한 수량의 인스턴스를 생성한다 Correct answer.
  2. 1 台目のインスタンスのスナップショットを取得し、それをネットワーク共有として他インスタンスにマウントする
  3. 1 台目のインスタンスの Floating IP を複製して、複数インスタンスに同じ IP を割り当てる
  4. 1 台目のインスタンスにログインして手作業で設定し、その内容を 2 台目以降に手順書で再現する

Explanation

インスタンスからイメージを作成し、そのイメージを元に必要な台数を起動すれば、同一構成のインスタンスを再現性高く用意できます。手作業での再現は差分が生じやすく、運用負荷も高くなります。

Question 32Compute

NHN Cloud の Instance で、インスタンスの自動復旧を目的として定期적으로 스냅샷을 획득하려 한다. 가장 적절한 설명은?

  1. 스냅샷은 부트 볼륨을 포함한 볼륨 단위로 생성되며, 장애 시 해당 스냅샷으로 볼륨을 복구해 인스턴스를 재구성할 수 있다 Correct answer.
  2. 스냅샷은 인스턴스의 메모리 상태까지 저장하므로, 복구 시 실행 중이던 프로세스가 그대로 이어진다
  3. 스냅샷을 생성하면 원본 볼륨이 즉시 삭제되고 스냅샷만 남아 비용이 절감된다
  4. 스냅샷은 인스턴스 단위로만 생성 가능하며, 개별 볼륨에는 적용할 수 없다

Explanation

스냅샷은 볼륨 단위로 생성되어 해당 시점의 디스크 내용을 보존하며, 장애 발생 시 스냅샷으로 볼륨을 복구한 뒤 인스턴스에 연결해 복원합니다. 메모리 상태나 실행 중 프로세스까지 보존하는 것은 아닙니다.

Question 33Compute

NHN Cloud の Instance で、인스턴스의 보안 그룹 규칙 평가에 대한 설명으로 옳은 것은?

  1. 보안 그룹 규칙은 인스턴스가 아닌 서브넷에 적용되며, 서브넷 단위로 트래픽을 제어한다
  2. 여러 보안 그룹이 적용된 경우 각 그룹의 허용 규칙을 모두 합쳐 평가하며, 어느 하나라도 허용하면 통과한다 Correct answer.
  3. 보안 그룹은 인바운드 규칙만 평가하며, 아웃바운드 트래픽은 항상 허용된다
  4. 여러 보안 그룹이 적용된 경우 모든 규칙을 순서대로 평가하여 마지막에 매칭된 규칙이 최종 적용된다

Explanation

인스턴스에 여러 보안 그룹이 연결되면 각 그룹의 허용 규칙이 합쳐져 평가되고, 어떤 그룹에서든 허용되면 트래픽이 통과합니다. 규칙은 순서대로 마지막 매칭을 따르는 방식이 아닙니다.

Question 34Compute

NHN Cloud の Instance で、인스턴스의 상태를 주기적으로 확인하고 비정상일 때 알림을 받기 위한 구성으로 가장 적절한 것은?

  1. 인스턴스에 크론 작업을 등록해 1 분마다 로그 파일을 압축하는 스크립트를 실행한다
  2. 로드 밸런서의 리스너 규칙을 변경해 헬스 체크 주기를 0 초로 설정한다
  3. 인스턴스의 보안 그룹에 모니터링 포트를 추가해 외부에서 직접 접속을 시도한다
  4. 모니터링 서비스에서 인스턴스의 지표를 수집하고, 임계치 기반 알림 정책과 알림 대상을 설정한다 Correct answer.

Explanation

모니터링 서비스에서 인스턴스 지표를 수집하고 임계치와 알림 대상을 설정하면 상태 이상 시 통지를 받을 수 있습니다. 로그 압축이나 포트 개방은 상태 감지와 알림 전달의 수단이 되지 못합니다.

Question 35Compute

NHN Cloud の Instance で、오토 스케일링 그룹을 구성할 때 인스턴스 수를 늘리거나 줄이는 판단의 기준으로 사용할 수 있는 항목은?

  1. 인스턴스의 CPU 사용률 같은 모니터링 지표 Correct answer.
  2. 인스턴스에 할당된 Floating IP 의 개수
  3. 인스턴스의 키페어 이름
  4. 인스턴스에 로그인한 사용자 수

Explanation

오토 스케일링은 CPU 사용률 등 모니터링 지표를 조건으로 삼아 인스턴스 수를 조정합니다. 로그인 사용자 수나 키페어 이름, Floating IP 개수는 조정 조건으로 쓰이지 않습니다.

Question 36Compute

NHN Cloud の Instance で、인스턴스의 루트 볼륨을 실수로 삭제한 경우 복구 방법으로 가장 적절한 것은?

  1. 미리 확보한 볼륨 스냅샷이나 이미지로 볼륨을 복구한 뒤, 해당 볼륨을 인스턴스에 연결해 부팅한다 Correct answer.
  2. Floating IP 를 재할당하면 삭제된 루트 볼륨이 자동으로 복원된다
  3. 삭제된 루트 볼륨은 자동으로 재생성되므로 인스턴스를 재부팅하기만 하면 된다
  4. 인스턴스의 보안 그룹 규칙을 초기화하면 루트 볼륨이 함께 복원된다

Explanation

루트 볼륨을 잃은 경우 사전에 확보한 스냅샷이나 이미지로 볼륨을 복구하고, 이를 부팅 볼륨으로 연결해 인스턴스를 다시 기동합니다. 사전 백업이 없으면 복구가 불가능하므로 정기 스냅샷이 중요합니다.

Question 37Compute

NHN Cloud の Instance で、웹 서버를 여러 인스턴스로 구성할 때 세션 정보를 각 인스턴스의 로컬 디스크에만 저장했을 때 발생할 수 있는 문제로 가장 적절한 것은?

  1. 세션 정보를 로컬에 저장하면 보안 그룹 규칙이 자동으로 변경된다
  2. 사용자의 요청이 세션을 가진 인스턴스가 아닌 다른 인스턴스로 전달되면 로그인이 풀리는 현상이 생긴다 Correct answer.
  3. 세션 정보가 로컬에 있으면 인스턴스의 CPU 사용률이 급격히 낮아진다
  4. 로드 밸런서가 세션 정보를 자동으로 복제하므로 문제가 발생하지 않는다

Explanation

세션을 인스턴스 로컬에만 두면 로드 밸런서가 요청을 다른 인스턴스로 분산할 때 세션이 유지되지 않아 재로그인이 발생할 수 있습니다. 세션을 공유 저장소에 두거나 스티키 세션을 사용해 해결합니다.

Question 38Compute

NHN Cloud の Instance で、인스턴스의 모니터링 알림을 '5 분 평균 CPU 사용률이 80% 를 초과할 때만' 발생시키고자 한다. 가장 적절한 설정은?

  1. 알림 조건을 비활성화하고 로그만 수집하도록 설정한다
  2. 1 분 단위의 순간 CPU 사용률이 80% 를 넘는 즉시 알림이 발생하도록 설정한다
  3. 5 분 동안의 평균 CPU 사용률이 80% 를 초과하는 조건과 알림 대상을 함께 설정한다 Correct answer.
  4. CPU 사용률과 무관하게 인스턴스의 상태가 ACTIVE 이면 알림이 발생하도록 설정한다

Explanation

평균값 기준의 알림을 원한다면 5 분 구간의 평균 CPU 사용률이 80% 를 초과하는 조건을 설정하고 알림 대상을 지정해야 합니다. 순간값 기준으로 설정하면 일시적인 스파이크에도 알림이 발생합니다.

Question 39Compute

NHN Cloud の Instance で、프라이빗 서브넷의 인스턴스가 외부 저장소에서 패키지를 내려받기 위해 필요한 구성으로 가장 적절한 것은?

  1. 프라이빗 서브넷의 보안 그룹에서 모든 아웃바운드 규칙을 삭제한다
  2. 프라이빗 서브넷의 라우팅 테이블에서 모든 트래픽을 차단한다
  3. 프라이빗 서브넷에 NAT 게이트웨이를 연결해 아웃바운드 인터넷 통신 경로를 제공한다 Correct answer.
  4. 프라이빗 서브넷의 인스턴스에 Floating IP 를 직접 부여한다

Explanation

프라이빗 서브넷의 인스턴스는 공인 IP 가 없어 외부로 직접 나갈 수 없으므로, NAT 게이트웨이를 통해 아웃바운드 통신 경로를 제공해야 합니다. 보안 그룹의 아웃바운드 규칙도 함께 허용되어야 합니다.

Question 40Compute

NHN Cloud の Instance で、로드 밸런서 뒤에 있는 인스턴스를 점검을 위해 잠시 서비스에서 제외하려 한다. 가장 적절한 방법은?

  1. 인스턴스의 키페어를 삭제해 접속을 막는다
  2. 로드 밸런서의 리스너 포트를 변경해 전체 서비스를 중단한다
  3. 로드 밸런서의 멤버 목록에서 해당 인스턴스를 비활성화하거나 헬스 체크에서 제외되도록 조치한다 Correct answer.
  4. 인스턴스를 삭제한 뒤 점검 후 동일한 이름으로 다시 생성한다

Explanation

점검 대상 인스턴스만 로드 밸런서 멤버에서 비활성화하면 나머지 인스턴스로 트래픽이 분산되어 서비스 영향 없이 작업할 수 있습니다. 인스턴스 삭제나 리스너 변경은 전체 서비스에 영향을 줍니다.

Question 41Container

NHN Cloud Kubernetes Service에서 워커 노드의 오토스케일링을 담당하는 구성 요소로 가장 적절한 것은?

  1. kube-scheduler
  2. CoreDNS
  3. Ingress Controller
  4. Cluster Autoscaler Correct answer.

Explanation

Cluster Autoscaler는 파드가 스케줄되지 못해 Pending 상태로 남을 때 노드 그룹의 노드 수를 늘리거나, 유휴 노드를 줄여 클러스터 용량을 조정하는 역할을 한다. kube-scheduler는 기존 노드 안에서 파드의 배치만 결정할 뿐 노드 자체를 생성하지 않는다. 따라서 노드 수준 확장은 Cluster Autoscaler가 담당한다.

Question 42Container

NHN Cloud Kubernetes Service 클러스터에서 kubectl을 사용하기 위해 일반적으로 필요한 설정 파일은?

  1. kubeconfig 파일 Correct answer.
  2. Vagrantfile
  3. nginx.conf 파일
  4. docker-compose.yml 파일

Explanation

kubectl은 kubeconfig 파일에 저장된 클러스터 API 서버 주소, 사용자 인증 정보, 컨텍스트를 읽어 클러스터에 접속한다. NHN Cloud 콘솔에서 클러스터를 생성한 뒤 이 파일을 내려받아 로컬 환경에 배치하면 kubectl 명령을 사용할 수 있다. 나머지 파일들은 컨테이너 오케스트레이션 접속 자격 증명과 관련이 없다.

Question 43Container

파드 내부의 애플리케이션이 환경 변수로 데이터베이스 비밀번호를 받아야 할 때, 민감 정보를 안전하게 주입하는 방식으로 가장 적절한 것은?

  1. ConfigMap에 평문으로 저장한다
  2. Secret을 환경 변수로 참조하도록 설정한다 Correct answer.
  3. 이미지 빌드 시 Dockerfile에 하드코딩한다
  4. Deployment 이름에 비밀번호를 포함한다

Explanation

Secret은 비밀번호나 토큰처럼 민감한 값을 별도 오브젝트로 관리하고 envFrom이나 valueFrom으로 파드에 주입할 수 있는 리소스다. ConfigMap은 민감 정보 전용이 아니며 평문 저장을 전제로 하므로 자격 증명에는 부적절하다. 이미지나 매니페스트에 값을 직접 노출하면 유출 위험이 커진다.

Question 44Container

NHN Cloud Kubernetes Service에서 서비스 타입을 LoadBalancer로 생성했을 때 일반적으로 일어나는 동작은?

  1. 파드가 자동으로 StatefulSet으로 전환된다
  2. 클라우드 로드 밸런서가 프로비저닝되어 외부 IP로 트래픽을 받는다 Correct answer.
  3. 노드마다 hostPort가 자동 개방된다
  4. 서비스가 자동으로 DaemonSet을 생성한다

Explanation

LoadBalancer 타입 서비스는 클라우드 컨트롤러 매니저를 통해 클라우드 인프라의 로드 밸런서를 생성하고 외부에서 접근 가능한 주소를 할당받는다. NHN Cloud 환경에서는 이 과정이 플랫폼의 로드 밸런서 리소스와 연동된다. 나머지 동작은 서비스 타입 변경만으로 자동 수행되지 않는다.

Question 45Container

컨테이너 이미지를 저장하고 클러스터가 배포 시 이미지를 받아오는 데 사용하는 NHN Cloud의 레지스트리 서비스는?

  1. Cloud DB
  2. Network ACL
  3. Object Storage
  4. Container Registry Correct answer.

Explanation

Container Registry는 도커 이미지를 비공개로 저장하고 태그 단위로 관리하며, 클러스터의 imagePullSecret을 통해 인증 후 이미지를 내려받는 데 사용된다. Object Storage는 일반 파일 저장, Cloud DB는 데이터베이스, Network ACL은 접근 제어를 담당한다. 이미지 저장과 배포는 레지스트리 서비스의 역할이다.

Question 46Container

Deployment가 관리하는 파드의 개수를 3개로 유지하려면 매니페스트에 어떤 필드를 설정해야 하는가?

  1. spec.replicas: 3 Correct answer.
  2. spec.selector: 3
  3. spec.revisionHistoryLimit: 3
  4. spec.strategy: 3

Explanation

Deployment의 spec.replicas 필드는 유지해야 할 파드 복제본 수를 지정하며, 컨트롤러는 이 값과 실제 파드 수를 비교해 스케일링한다. strategy는 롤링 업데이트 방식을, selector는 관리 대상 파드를 식별하는 라벨 조건을 정의한다. 복제본 수는 replicas 필드로만 결정된다.

Question 47Container

파드에 CPU 요청량 250m과 제한량 500m을 설정했을 때의 의미로 옳은 것은?

  1. 항상 0.5 CPU를 전용으로 할당받는다
  2. 노드에 0.25 CPU만 남아 있어도 제한량까지 사용할 수 있다
  3. 스케줄링 시 0.25 CPU를 기준으로 노드 자원을 확보하고 실행 중에는 0.5 CPU로 제한된다 Correct answer.
  4. CPU 사용량이 0.25를 넘으면 파드가 즉시 종료된다

Explanation

requests는 스케줄러가 노드에 파드를 배치할 때 확보하는 자원량이고, limits는 컨테이너가 실제로 사용할 수 있는 상한이다. CPU 제한을 초과하면 스로틀링이 발생하지만 파드가 종료되지는 않는다. 메모리 제한 초과 시에는 OOM 종료가 발생한다는 점과 구분해야 한다.

Question 48Container

ConfigMap을 파드의 환경 변수로 주입하려 할 때 사용하는 필드 조합은?

  1. securityContext.runAsUser
  2. affinity.nodeAffinity
  3. envFrom.configMapRef Correct answer.
  4. volumes.hostPath

Explanation

envFrom에 configMapRef를 지정하면 ConfigMap의 키-값 쌍이 모두 환경 변수로 주입된다. 특정 키만 주입하려면 env.valueFrom.configMapKeyRef를 사용한다. 나머지 필드는 볼륨 마운트, 보안 컨텍스트, 스케줄링 규칙에 관한 설정이다.

Question 49Container

무중단 배포를 위해 Deployment의 롤링 업데이트 중 가용 파드 수를 보장하려면 어떤 설정을 조정해야 하는가?

  1. progressDeadlineSeconds
  2. maxUnavailable과 maxSurge Correct answer.
  3. revisionHistoryLimit
  4. minReadySeconds만

Explanation

RollingUpdate 전략에서 maxUnavailable은 업데이트 중 동시에 사용 불가능할 수 있는 파드 수를, maxSurge는 원하는 수를 초과해 추가 생성할 수 있는 파드 수를 제한한다. 두 값을 적절히 조합하면 서비스 가능한 파드 수를 유지하며 점진적으로 교체할 수 있다. 나머지 필드는 이력 보관이나 준비 대기 시간에 관한 설정이다.

Question 50Container

PersistentVolumeClaim을 사용하는 파드가 데이터를 유지하도록 설계할 때 가장 적절한 워크로드 컨트롤러는?

  1. Job
  2. Deployment
  3. StatefulSet Correct answer.
  4. CronJob

Explanation

StatefulSet은 파드마다 고유하고 안정적인 이름과 순서를 부여하고, volumeClaimTemplates로 각 파드에 전용 PVC를 연결해 재시작 후에도 동일한 스토리지를 다시 사용하게 한다. Deployment의 파드는 대체 가능한 존재로 취급되어 개별 파드에 영속적인 신원을 보장하지 않는다. 상태를 가진 데이터베이스 같은 워크로드에는 StatefulSet이 적합하다.