etcd 스냅샷을 복원한 후 클러스터를 다시 시작할 때 올바른 절차는 무엇입니까?

A) 스냅샷 복원 후 기존 data-dir을 그대로 사용한다 B) 스냅샷 복원 시 새로운 data-dir을 지정하고, etcd 설정에서 data-dir 경로를 변경한 뒤 재시작한다 C) 스냅샷 복원 후 모든 노드에서 kubelet만 재시작한다 D) 스냅샷 복원은 자동으로 etcd를 재시작한다

정답: B

etcdutl snapshot restore 명령은 새로운 data-dir에 데이터를 복원합니다. 복원 후 etcd의 설정 파일(또는 static pod manifest)에서 data-dir 경로를 새 경로로 변경하고 etcd를 재시작해야 합니다. 기존 data-dir을 덮어쓰면 데이터 손상 위험이 있습니다.

etcdctl snapshot save 명령으로 백업할 때 필수로 지정해야 하는 인증서 관련 플래그 조합은?

A) --cacert, --cert, --key B) --ca-file, --cert-file만 C) --tls-cert만 D) 인증서 없이도 백업 가능하다

정답: A

etcd가 TLS로 보호되는 경우 etcdctl에 --cacert(CA 인증서), --cert(클라이언트 인증서), --key(클라이언트 키)를 모두 지정해야 합니다. 추가로 --endpoints 플래그로 etcd 엔드포인트도 지정해야 합니다.

3노드 etcd 클러스터에서 한 멤버를 제거한 뒤 같은 노드를 다시 추가할 때 반드시 해야 하는 작업은?

A) 기존 data-dir을 그대로 유지하고 재시작만 한다 B) 기존 data-dir을 삭제하고, etcdctl member add로 새 멤버로 추가한 뒤 initial-cluster-state를 existing으로 설정한다 C) etcdctl member update만 실행하면 된다 D) 클러스터 전체를 재시작해야 한다

정답: B

제거된 멤버를 재추가할 때는 기존 데이터 디렉토리를 반드시 삭제해야 합니다. 그런 다음 etcdctl member add로 새 멤버를 등록하고, initial-cluster-state=existing으로 설정하여 기존 클러스터에 합류하도록 해야 합니다.

3노드 etcd 클러스터에서 2노드가 동시에 장애가 발생하여 쿼럼이 손실되었습니다. 복구 방법은?

A) 남은 1노드에서 자동으로 복구된다 B) 남은 1노드에서 etcdctl snapshot save 후, --force-new-cluster 플래그로 단일 노드 클러스터를 생성한 뒤 나머지 멤버를 추가한다 C) 3노드 모두 재시작하면 자동 복구된다 D) etcdctl defrag만 실행하면 된다

정답: B

쿼럼이 손실되면 정상 읽기/쓰기가 불가합니다. 남은 노드에서 스냅샷을 저장한 뒤, --force-new-cluster 옵션으로 단일 노드 클러스터를 새로 구성하고, 이후 나머지 멤버를 하나씩 추가하여 클러스터를 재구성해야 합니다.

etcd 성능이 저하될 때 우선적으로 확인해야 하는 메트릭은?

A) etcd_server_proposals_committed_total B) etcd_disk_wal_fsync_duration_seconds 및 etcd_disk_backend_commit_duration_seconds C) etcd_network_client_grpc_received_bytes_total D) etcd_server_version

정답: B

etcd 성능 저하의 가장 흔한 원인은 디스크 지연입니다. WAL fsync 지연(etcd_disk_wal_fsync_duration_seconds)과 백엔드 커밋 지연(etcd_disk_backend_commit_duration_seconds)을 먼저 확인해야 합니다. 이 값이 높으면 SSD 사용이나 디스크 I/O 최적화가 필요합니다.

kubeadm을 사용하여 클러스터를 1.29에서 1.30으로 업그레이드할 때 올바른 순서는?

A) 워커 노드 먼저 업그레이드 후 컨트롤 플레인 업그레이드 B) kubeadm 업그레이드 -> kubelet, kubectl 업그레이드 -> 워커 노드 업그레이드 순서로, 컨트롤 플레인부터 시작 C) kubectl만 업그레이드하면 나머지는 자동으로 된다 D) 모든 노드에서 동시에 kubeadm upgrade apply를 실행한다

정답: B

올바른 순서는: 1) 컨트롤 플레인에서 kubeadm을 먼저 업그레이드, 2) kubeadm upgrade plan으로 확인, 3) kubeadm upgrade apply로 컨트롤 플레인 컴포넌트 업그레이드, 4) kubelet과 kubectl 업그레이드 후 재시작, 5) 워커 노드를 drain 후 동일 절차 반복입니다.

워커 노드를 drain하는 중 DaemonSet Pod 때문에 실패합니다. 어떻게 해결해야 합니까?

A) DaemonSet을 먼저 삭제한다 B) --ignore-daemonsets 플래그를 추가하여 drain을 실행한다 C) --force 플래그만 추가한다 D) drain 없이 바로 업그레이드한다

정답: B

kubectl drain 명령에 --ignore-daemonsets 플래그를 추가하면 DaemonSet에 의해 관리되는 Pod를 무시하고 drain을 진행합니다. DaemonSet Pod는 노드에 항상 존재해야 하므로 퇴거 대상에서 제외하는 것이 올바른 방법입니다.

kubeadm upgrade apply 후 kubelet이 시작되지 않습니다. 가장 가능성 높은 원인은?

A) kube-proxy 설정 오류 B) kubelet 패키지가 아직 이전 버전이라 버전 불일치가 발생했다 C) CNI 플러그인 문제 D) etcd가 중지되어 있다

정답: B

kubeadm upgrade apply는 컨트롤 플레인 컴포넌트만 업그레이드합니다. kubelet과 kubectl은 별도로 패키지를 업그레이드해야 합니다. 버전 불일치가 발생하면 kubelet이 정상적으로 시작되지 않을 수 있습니다.

3개의 컨트롤 플레인 노드가 있는 HA 클러스터를 업그레이드할 때 올바른 방법은?

A) 모든 컨트롤 플레인에서 동시에 kubeadm upgrade apply를 실행한다 B) 첫 번째 컨트롤 플레인에서 kubeadm upgrade apply를 실행하고, 나머지는 kubeadm upgrade node를 실행한다 C) 아무 노드에서나 kubeadm upgrade apply를 실행하면 된다 D) 워커 노드를 먼저 업그레이드한 후 컨트롤 플레인을 업그레이드한다

정답: B

HA 클러스터에서는 첫 번째 컨트롤 플레인 노드에서만 kubeadm upgrade apply를 실행합니다. 나머지 컨트롤 플레인 노드에서는 kubeadm upgrade node를 실행하여 로컬 kubelet 설정과 인증서를 업데이트합니다.

etcd의 데이터가 계속 증가하여 공간 부족 경고가 발생합니다. 자동 압축을 설정하려면?

A) etcd 시작 옵션에 --auto-compaction-retention=1 --auto-compaction-mode=periodic을 추가한다 B) etcdctl compact 명령을 수동으로 실행해야만 한다 C) etcd는 자동으로 압축되므로 별도 설정이 필요 없다 D) boltdb를 수동으로 교체해야 한다

정답: A

etcd에 --auto-compaction-mode=periodic과 --auto-compaction-retention 옵션을 설정하면 지정된 주기로 자동 압축이 실행됩니다. periodic 모드에서 retention이 1이면 1시간마다 압축됩니다. revision 모드도 사용 가능합니다. 압축 후에는 defrag도 함께 실행하는 것이 좋습니다.

dev 네임스페이스의 Pod만 읽을 수 있고, 모든 네임스페이스의 Node 정보는 읽을 수 있는 권한을 설정하려면?

A) 하나의 ClusterRole에 모든 권한을 넣고 ClusterRoleBinding으로 바인딩한다 B) Pod 읽기용 Role을 dev 네임스페이스에 만들고 RoleBinding으로 연결, Node 읽기용 ClusterRole을 만들고 ClusterRoleBinding으로 연결한다 C) 하나의 Role에 Pod와 Node 권한을 모두 넣는다 D) ServiceAccount에 직접 권한을 부여한다

정답: B

네임스페이스 범위의 리소스(Pod)는 Role + RoleBinding으로, 클러스터 범위의 리소스(Node)는 ClusterRole + ClusterRoleBinding으로 각각 설정해야 합니다. Role은 특정 네임스페이스에만 적용되고, Node는 네임스페이스가 없는 클러스터 리소스이므로 ClusterRole이 필요합니다.

aggregationRule이 설정된 ClusterRole의 동작에 대해 올바른 설명은?

A) 다른 ClusterRole의 규칙을 자동으로 병합하여 하나의 ClusterRole로 만든다 B) 여러 네임스페이스의 Role을 합친다 C) ClusterRole의 권한을 자동으로 축소한다 D) ServiceAccount를 자동으로 생성한다

정답: A

aggregationRule은 레이블 셀렉터를 사용하여 다른 ClusterRole의 규칙을 자동으로 병합합니다. 예를 들어 admin, edit, view 같은 기본 ClusterRole이 이 메커니즘을 사용합니다. 새 CRD를 추가할 때 적절한 레이블이 붙은 ClusterRole을 생성하면 자동으로 기존 역할에 권한이 추가됩니다.

보안을 위해 특정 Pod에서 ServiceAccount 토큰이 자동 마운트되지 않도록 하려면?

A) ServiceAccount를 삭제한다 B) Pod spec 또는 ServiceAccount에서 automountServiceAccountToken을 false로 설정한다 C) RBAC 권한을 모두 제거한다 D) 네임스페이스를 삭제한다

정답: B

Pod spec의 automountServiceAccountToken 필드를 false로 설정하거나, ServiceAccount 자체에 해당 필드를 false로 설정할 수 있습니다. Pod 수준 설정이 ServiceAccount 수준 설정보다 우선합니다. 이렇게 하면 /var/run/secrets/kubernetes.io/serviceaccount에 토큰이 마운트되지 않습니다.

production 네임스페이스에서 실행 중인 Pod가 monitoring 네임스페이스의 Pod로부터만 트래픽을 받도록 하려면?

A) ingress 규칙에서 namespaceSelector로 monitoring 네임스페이스를 선택한다 B) egress 규칙만 설정한다 C) 모든 트래픽을 허용하는 정책을 만든다 D) Pod의 label만 변경한다

정답: A

NetworkPolicy의 ingress 규칙에서 namespaceSelector를 사용하여 monitoring 네임스페이스의 레이블을 선택합니다. 이때 monitoring 네임스페이스에 적절한 레이블이 설정되어 있어야 합니다. namespaceSelector와 podSelector를 함께 사용하면 더 세밀한 제어가 가능합니다.

NetworkPolicy ingress 규칙에서 다음 두 설정의 차이는 무엇입니까?

설정 A: from 배열에 namespaceSelector와 podSelector를 같은 항목에 넣음 설정 B: from 배열에 namespaceSelector와 podSelector를 별도 항목으로 넣음

A) 차이가 없다 B) 설정 A는 AND 조건(두 조건을 모두 만족), 설정 B는 OR 조건(하나만 만족해도 허용) C) 설정 A가 OR 조건이다 D) 둘 다 OR 조건이다

정답: B

같은 from 항목 안에 namespaceSelector와 podSelector를 함께 넣으면 AND 조건입니다(두 조건 모두 만족하는 Pod만 허용). 별도의 from 항목으로 분리하면 OR 조건입니다(어느 하나라도 만족하면 허용). 이 차이는 NetworkPolicy에서 매우 중요하며 시험에서 자주 출제됩니다.

특정 네임스페이스에서 모든 ingress 트래픽을 기본 거부하려면?

A) NetworkPolicy 없이 기본적으로 모든 트래픽이 거부된다 B) podSelector를 비워두고(모든 Pod 선택), ingress 규칙을 비워둔 NetworkPolicy를 생성한다 C) egress 규칙만 비워두면 된다 D) 네임스페이스에 annotation을 추가한다

정답: B

podSelector를 빈 값으로 설정하면 네임스페이스의 모든 Pod를 선택합니다. policyTypes에 Ingress를 지정하되 ingress 규칙을 정의하지 않으면 모든 인바운드 트래픽이 거부됩니다. 이것이 기본 거부 정책의 표준 패턴입니다.

NetworkPolicy를 적용했는데 Pod 간 통신이 여전히 가능합니다. 가장 가능성 높은 원인은?

A) NetworkPolicy가 너무 많이 적용되어 있다 B) CNI 플러그인이 NetworkPolicy를 지원하지 않는다(예: Flannel) C) Pod가 재시작되지 않았다 D) kube-proxy가 중지되어 있다

정답: B

Flannel 같은 일부 CNI 플러그인은 NetworkPolicy를 지원하지 않습니다. Calico, Cilium, Weave Net 등 NetworkPolicy를 지원하는 CNI를 사용해야 합니다. NetworkPolicy 리소스를 생성해도 CNI가 지원하지 않으면 아무 효과가 없습니다.

사용자에게 impersonate 동사 권한을 부여하면 어떤 일이 가능한가?

A) 다른 사용자의 비밀번호를 변경할 수 있다 B) 다른 사용자, 그룹, 또는 ServiceAccount로 가장하여 API 요청을 할 수 있다 C) 사용자 계정을 삭제할 수 있다 D) 모든 Secret에 접근할 수 있다

정답: B

impersonate 권한은 kubectl 명령에서 --as, --as-group 플래그를 사용하여 다른 사용자나 그룹으로 가장할 수 있게 합니다. 이는 RBAC 정책 테스트나 디버깅에 유용하지만, 강력한 권한이므로 신중하게 부여해야 합니다.

Pod에서 특정 외부 IP 대역(10.0.0.0/8)으로만 egress를 허용하려면?

A) ingress 규칙에 CIDR을 설정한다 B) egress 규칙에서 ipBlock으로 cidr: 10.0.0.0/8을 지정한다 C) Service의 externalIPs를 설정한다 D) Pod의 hostNetwork를 true로 설정한다

정답: B

NetworkPolicy의 egress 규칙에서 ipBlock을 사용하면 CIDR 블록 기반으로 외부 트래픽을 제어할 수 있습니다. except 필드를 사용하면 특정 서브넷을 제외할 수도 있습니다. 이 방법은 클러스터 외부 서비스로의 트래픽을 제한할 때 유용합니다.

특정 ConfigMap 하나에만 읽기 권한을 부여하려면?

A) 모든 ConfigMap에 대한 get 권한을 부여한다 B) Role에서 resources에 configmaps를 지정하고 resourceNames에 특정 ConfigMap 이름을 명시한다 C) ConfigMap에 annotation을 추가한다 D) 네임스페이스를 분리한다

정답: B

Role의 rules에서 resourceNames 필드를 사용하면 특정 이름의 리소스에만 권한을 제한할 수 있습니다. 예를 들어 resources: configmaps, verbs: get, resourceNames: my-config으로 설정하면 my-config이라는 ConfigMap에만 읽기 권한이 부여됩니다.

CSI(Container Storage Interface) 드라이버의 주요 구성 요소는?

A) Controller Plugin만 있으면 된다 B) Controller Plugin(프로비저닝, 어태치)과 Node Plugin(마운트, 포맷)으로 구성된다 C) kubelet이 CSI 기능을 내장하고 있다 D) kube-proxy가 스토리지를 관리한다

정답: B

CSI 드라이버는 Controller Plugin과 Node Plugin으로 구성됩니다. Controller Plugin은 볼륨 생성/삭제, 어태치/디태치를 담당하며 보통 Deployment로 배포됩니다. Node Plugin은 볼륨 마운트/언마운트, 포맷을 담당하며 DaemonSet으로 배포됩니다.

kubelet의 eviction-hard 설정이 memory.available가 100Mi 미만으로 설정되어 있을 때의 동작은?

A) 노드가 자동으로 재부팅된다 B) 사용 가능한 메모리가 100Mi 미만이 되면 kubelet이 우선순위가 낮은 Pod부터 퇴거시킨다 C) 새 Pod 스케줄링만 차단한다 D) 노드의 모든 Pod가 동시에 종료된다

정답: B

kubelet의 eviction-hard 임계값에 도달하면 kubelet은 Pod를 퇴거시켜 리소스를 회수합니다. QoS 클래스(BestEffort, Burstable, Guaranteed 순)와 리소스 사용량을 기준으로 퇴거 대상을 선정합니다. 노드에는 MemoryPressure 같은 조건(condition)이 추가됩니다.

static Pod에 대한 설명 중 올바른 것은?

A) kubectl로 직접 삭제할 수 있다 B) kubelet이 직접 관리하며, 특정 디렉토리의 매니페스트 파일을 감시하여 생성/삭제한다 C) ReplicaSet에 의해 관리된다 D) etcd에 직접 저장된다

정답: B

static Pod는 kubelet이 지정된 디렉토리(기본값: /etc/kubernetes/manifests)의 YAML 파일을 감시하여 직접 관리합니다. API 서버에는 mirror Pod가 생성되어 조회는 가능하지만, kubectl delete로 삭제해도 kubelet이 다시 생성합니다. 컨트롤 플레인 컴포넌트가 주로 static Pod로 실행됩니다.

Kubernetes API 서버 감사 정책(Audit Policy)의 로깅 레벨 중 RequestResponse에 대한 설명은?

A) 이벤트 메타데이터만 기록한다 B) 요청 메타데이터와 요청 본문(body)을 기록한다 C) 요청 메타데이터, 요청 본문, 응답 본문을 모두 기록한다 D) 아무것도 기록하지 않는다

정답: C

감사 정책의 레벨은 None(기록 안함), Metadata(메타데이터만), Request(메타데이터+요청 본문), RequestResponse(메타데이터+요청 본문+응답 본문)입니다. RequestResponse는 가장 상세한 레벨로, Secret 접근이나 중요한 API 호출 추적에 유용하지만 로그 볼륨이 매우 커집니다.

Secret 리소스에 대한 접근만 RequestResponse 레벨로 감사 로깅하려면 어떻게 설정하나?

A) 모든 리소스를 RequestResponse로 설정한다 B) 감사 정책의 rules에서 resources에 secrets를 지정하고 level을 RequestResponse로 설정한다 C) kube-apiserver의 --audit-log-path만 설정하면 된다 D) etcd에서 직접 로깅을 설정한다

정답: B

감사 정책(audit policy) 파일의 rules 섹션에서 resources 그룹과 리소스 이름을 지정하여 특정 리소스에 대한 로깅 레벨을 설정할 수 있습니다. 규칙은 위에서 아래로 평가되며, 첫 번째 매칭 규칙이 적용됩니다.

kubeadm으로 설치한 클러스터의 컨트롤 플레인 인증서가 곧 만료됩니다. 갱신 방법은?

A) 인증서는 자동으로 영구적이므로 갱신이 필요 없다 B) kubeadm certs renew all 명령으로 갱신한 후 컨트롤 플레인 컴포넌트를 재시작한다 C) 인증서를 수동으로 삭제하면 자동 재생성된다 D) 새 클러스터를 설치해야 한다

정답: B

kubeadm certs renew all 명령으로 모든 인증서를 갱신할 수 있습니다. 갱신 후 kube-apiserver, kube-controller-manager, kube-scheduler, etcd의 static Pod를 재시작해야 합니다. kubeadm은 기본적으로 1년 유효기간의 인증서를 발급합니다.

kubeadm certs check-expiration 명령이 보여주는 정보는?

A) kubelet 인증서만 보여준다 B) kubeadm이 관리하는 모든 인증서의 만료 일자와 잔여 유효기간, CA 정보를 보여준다 C) 외부 CA 인증서의 정보를 보여준다 D) TLS Secret의 만료 정보를 보여준다

정답: B

kubeadm certs check-expiration은 API 서버, 컨트롤러 매니저, 스케줄러, etcd 등의 인증서 만료일, 잔여 유효기간, 인증서를 발급한 CA 정보를 테이블 형태로 보여줍니다. 인증서 관리 계획을 세울 때 유용합니다.

기본 스케줄러 외에 추가 커스텀 스케줄러를 배포하려면?

A) 기본 스케줄러를 수정해야 한다 B) 별도의 스케줄러를 Deployment로 배포하고, Pod spec의 schedulerName 필드에 해당 스케줄러 이름을 지정한다 C) 모든 Pod가 자동으로 커스텀 스케줄러를 사용한다 D) kubelet 설정을 변경한다

정답: B

커스텀 스케줄러는 별도의 Deployment로 배포할 수 있습니다. Pod가 특정 스케줄러를 사용하려면 spec.schedulerName 필드에 커스텀 스케줄러 이름을 지정합니다. 지정하지 않은 Pod는 기본 스케줄러(default-scheduler)가 처리합니다.

BestEffort QoS Pod에만 리소스 쿼터를 적용하려면?

A) 모든 Pod에 동일한 쿼터를 적용한다 B) ResourceQuota에 scopeSelector를 사용하여 BestEffort 스코프를 지정한다 C) PriorityClass로만 제한할 수 있다 D) LimitRange만 사용한다

정답: B

ResourceQuota의 scopeSelector 또는 scopes 필드를 사용하면 BestEffort, NotBestEffort, Terminating, NotTerminating 등의 스코프로 특정 조건의 Pod에만 쿼터를 적용할 수 있습니다. 예를 들어 BestEffort 스코프를 지정하면 리소스 요청/제한이 없는 Pod에만 쿼터가 적용됩니다.

LimitRange와 ResourceQuota의 주요 차이점은?

A) 둘 다 네임스페이스 전체의 총 리소스를 제한한다 B) LimitRange는 개별 Pod/컨테이너의 기본값과 최대/최소 리소스를 설정하고, ResourceQuota는 네임스페이스 전체의 총 리소스 사용량을 제한한다 C) ResourceQuota는 개별 컨테이너에만 적용된다 D) LimitRange는 클러스터 전체에 적용된다

정답: B

LimitRange는 개별 컨테이너 또는 Pod 수준에서 기본 리소스 요청/제한, 최소/최대 값을 설정합니다. ResourceQuota는 네임스페이스 전체에서 사용할 수 있는 총 리소스량(CPU, 메모리, Pod 수 등)을 제한합니다. 두 가지를 함께 사용하면 세밀한 리소스 관리가 가능합니다.