Kubernetes and Cloud Native Associate (KCNA) #9 모의 객관식 시험: 50문항 + 해설
#1부터 #8까지 정리한 개념이 머릿속에 자리 잡았는지를 확인하는 단계입니다. 실제 KCNA와 동일한 도메인 분포로 50문항을 풉니다. 이번 글이 시리즈의 마지막 글입니다.
KCNA 실제 시험은 60문항이지만 본 모의고사는 채점을 50문항 기준으로 두었습니다. 합격선은 동일하게 **75%**이며, 50문항 중 38문항 이상을 맞추면 합격권으로 봅니다.
풀이 방법 #
- 60〜75분 안에 풀어 봅니다 (실제 시험은 60문항/90분이지만 본 모의고사는 50문항 기준)
- 한 문항씩 풀되 즉시 해설을 보지 말고, 끝까지 푼 뒤 채점합니다
- 38문항(75%) 이상 맞추면 합격권으로 봅니다
- 부족한 도메인이 보이면 해당 글로 돌아가 다시 정리합니다
도메인 분포 #
| 도메인 | 문항 수 | 범위 |
|---|---|---|
| Domain 1: Kubernetes Fundamentals (46%) | 23 | Q1 〜 Q23 |
| Domain 2: Container Orchestration (22%) | 11 | Q24 〜 Q34 |
| Domain 3: Cloud Native Architecture (16%) | 8 | Q35 〜 Q42 |
| Domain 4: Cloud Native Observability (8%) | 4 | Q43 〜 Q46 |
| Domain 5: Cloud Native Application Delivery (8%) | 4 | Q47 〜 Q50 |
Domain 1: Kubernetes Fundamentals #
Q1. control plane에서 클러스터의 모든 상태(원하는 상태와 현재 상태)를 저장하는 컴포넌트는 무엇인가?
해설
etcd는 클러스터 전체 상태를 보관하는 분산 키-값 저장소입니다. scheduler는 Pod를 노드에 배치하고, controller-manager는 컨트롤러 루프를 돌리며, kubelet은 worker node에서 컨테이너를 실행하므로 상태 저장과는 역할이 다릅니다.
Q2. 클러스터와 상호작용하는 모든 요청이 거쳐 가는 단일 진입점이자, etcd에 접근하는 유일한 컴포넌트는 무엇인가?
해설
kube-apiserver는 모든 kubectl,컨트롤러,kubelet 요청이 통과하는 control plane의 정문이며, etcd에 직접 읽고 쓰는 유일한 컴포넌트입니다. kube-proxy는 노드의 네트워크 규칙을 담당하고, kubelet은 컨테이너 실행을 담당합니다.
Q3. 새로 생성된 Pod 를 어느 worker node에서 실행할지 결정하는 control plane 컴포넌트는?
해설
kube-scheduler는 리소스 요구,노드 상태,affinity 등을 평가해 Pod 를 노드에 배치합니다. kubelet은 배치가 끝난 뒤 해당 노드에서 컨테이너를 실제로 띄우는 에이전트입니다.
Q4. worker node에서 control plane으로부터 PodSpec을 받아 컨테이너가 그대로 실행되고 있는지 보장하는 에이전트는?
해설
kubelet은 각 worker node에서 동작하며 PodSpec에 맞게 컨테이너가 떠 있는지 지속적으로 보장합니다. kube-proxy는 Service 트래픽 라우팅을 담당하고, containerd는 실제 컨테이너를 실행하는 런타임입니다.
Q5. Kubernetes에서 배포,관리되는 가장 작은 실행 단위는 무엇인가?
해설
Kubernetes가 스케줄링하고 관리하는 최소 단위는 Pod 입니다. 컨테이너는 Pod 안에서 동작하며, Kubernetes는 컨테이너를 직접 스케줄링하지 않고 항상 Pod 단위로 다룹니다.
Q6. 하나의 Pod 안에 두 개 이상의 컨테이너가 함께 들어가는 경우 이들이 공유하는 것은? (Choose TWO)
해설
같은 Pod 의 컨테이너는 네트워크 네임스페이스(같은 IP,localhost)와 볼륨을 공유합니다. 이미지는 컨테이너마다 다르고, CPU 코어 번호나 단일 PID 1을 공유하는 개념은 Pod 공유 모델에 해당하지 않습니다.
Q7. 지정한 수의 동일한 Pod 복제본이 항상 유지되도록 보장하는 리소스는?
해설
ReplicaSet은 원하는 복제본 수를 유지합니다. DaemonSet은 노드마다 하나씩, Job은 완료가 목표인 일회성 작업, StatefulSet은 안정적 식별자가 필요한 상태 저장 워크로드에 쓰입니다.
Q8. ReplicaSet과 비교했을 때 Deployment가 추가로 제공하는 핵심 기능은?
해설
Deployment는 ReplicaSet을 관리하면서 롤링 업데이트와 이전 버전으로의 롤백을 제공합니다. 노드별 배치는 DaemonSet, Cron 예약은 CronJob의 역할입니다.
Q9. 데이터베이스처럼 안정적인 네트워크 식별자와 순서가 있는 영구 스토리지가 필요한 워크로드에 적합한 리소스는?
해설
StatefulSet은 안정적인 Pod 이름,순서,고유 볼륨을 보장해 데이터베이스 같은 상태 저장 애플리케이션에 적합합니다. Deployment,ReplicaSet은 Pod 가 상호 교체 가능한 무상태 워크로드를 가정합니다.
Q10. 클러스터의 모든(또는 특정) 노드마다 정확히 하나의 Pod 복제본을 실행하려면 어떤 리소스를 사용하는가?
해설
DaemonSet은 노드마다 하나의 Pod 를 띄우므로 로그 수집기,노드 모니터링 에이전트 같은 노드 단위 작업에 적합합니다. ReplicaSet은 노드 분포가 아니라 총 복제본 수만 보장합니다.
Q11. 하루에 한 번 정해진 시각에 배치 작업을 자동 실행하려면 어떤 리소스를 사용하는가?
해설
CronJob은 cron 표현식 일정에 맞춰 Job을 생성합니다. Job은 한 번 실행되고 완료되는 작업이며, 반복 일정 자체를 관리하지는 않습니다.
Q12. 한 묶음의 Pod 에 안정적인 단일 가상 IP와 DNS 이름을 제공해 묶음 내부로 트래픽을 분산하는 리소스는?
해설
Service는 selector로 묶인 Pod 집합에 고정 ClusterIP와 DNS 이름을 부여하고 부하를 분산합니다. Ingress는 클러스터 외부의 HTTP 라우팅 계층으로 Service보다 한 단계 위에서 동작합니다.
Q13. 클러스터 내부에서만 접근 가능한 기본 Service 타입은 무엇인가?
해설
ClusterIP는 기본 타입으로 클러스터 내부 IP만 노출합니다. NodePort는 각 노드의 포트를 열고, LoadBalancer는 외부 로드밸런서를 프로비저닝하며, ExternalName은 외부 DNS로 매핑합니다.
Q14. 클라우드 환경에서 외부 로드밸런서를 자동으로 프로비저닝해 인터넷에서 Service에 접근하게 하는 Service 타입은?
해설
LoadBalancer 타입은 클라우드 제공자의 로드밸런서를 생성해 외부 트래픽을 받습니다. NodePort도 외부 접근을 열지만 노드 IP,포트를 직접 써야 하고, ClusterIP는 내부 전용입니다.
Q15. 여러 호스트,경로 규칙으로 외부 HTTP/HTTPS 트래픽을 여러 Service로 라우팅하는 L7 리소스는?
해설
Ingress는 호스트,경로 기반 규칙으로 HTTP/HTTPS 트래픽을 내부 Service로 라우팅하는 L7 리소스이며, 실제 동작에는 Ingress Controller가 필요합니다. Service는 L4 수준의 묶음 노출을 담당합니다.
Q16. 설정값(환경 변수,설정 파일)을 컨테이너 이미지와 분리해 평문으로 저장하는 리소스는?
해설
ConfigMap은 비민감 설정 데이터를 평문으로 저장해 이미지와 분리합니다. 비밀번호,토큰 같은 민감 정보는 base64로 인코딩되는 Secret에 둡니다.
Q17. ConfigMap과 Secret의 가장 중요한 차이로 옳은 것은?
해설
Secret은 비밀번호,토큰,키 같은 민감 정보를 위한 리소스로 base64 인코딩과 RBAC,암호화 옵션 같은 추가 보호를 적용합니다. 둘 다 환경 변수,볼륨으로 주입할 수 있어 A는 틀립니다.
Q18. 하나의 물리 클러스터를 팀,프로젝트 단위로 논리적으로 분리하고 이름 충돌을 방지하는 리소스는?
해설
Namespace는 클러스터를 논리적으로 분할해 리소스 이름 범위를 나누고 쿼터,접근 제어를 적용합니다. Label,Annotation은 리소스에 메타데이터를 붙이는 키-값으로 격리 경계 역할은 하지 않습니다.
Q19. Kubernetes의 동작 모델을 가장 정확히 설명한 것은?
해설
Kubernetes는 선언형(declarative) 모델로, 원하는 상태(desired state)를 선언하면 컨트롤러 루프가 현재 상태(current state)를 끊임없이 비교,조정(reconcile)합니다. 절차적으로 단계를 직접 실행하는 명령형 모델과 대비됩니다.
Q20. Service가 어떤 Pod 집합으로 트래픽을 보낼지 고를 때, 그리고 Deployment가 어떤 Pod 를 관리할지 정할 때 공통으로 사용하는 키-값 메타데이터는?
해설
Label은 Pod 에 붙이는 키-값 메타데이터이고, selector는 그 Label로 대상 Pod 집합을 고르는 질의입니다. Service,ReplicaSet,Deployment 모두 이 짝으로 대상을 묶습니다. Annotation은 식별이 아닌 부가 정보 저장용이라 selector 대상이 아닙니다.
Q21. 컨테이너가 트래픽을 받을 준비가 되었는지 판단해 준비되지 않으면 Service 엔드포인트에서 제외하는 프로브는?
해설
readiness probe가 실패하면 해당 Pod 는 Service 엔드포인트에서 빠져 트래픽을 받지 않습니다. liveness probe는 실패 시 컨테이너를 재시작하고, startup probe는 느린 시작을 가진 앱의 초기 기동을 확인합니다.
Q22. liveness probe가 반복 실패할 때 kubelet이 취하는 동작은?
해설
liveness probe가 실패하면 kubelet이 컨테이너를 재시작해 교착,행 상태를 복구합니다. Service 엔드포인트에서 빼는 것은 readiness probe의 동작입니다.
Q23. 선언형으로 작성한 매니페스트 파일을 클러스터에 적용해 원하는 상태로 만드는 표준 kubectl 명령은?
해설
kubectl apply -f는 매니페스트의 선언형 상태를 클러스터에 적용하는 표준 명령입니다. run은 명령형으로 리소스를 즉석 생성하고, exec는 컨테이너 안에서 명령을 실행하며, describe는 리소스 상세를 조회합니다.
Domain 2: Container Orchestration #
Q24. kubelet과 컨테이너 런타임 사이의 표준 인터페이스로, 어떤 런타임을 쓰든 동일하게 통신하게 해 주는 규약은?
해설
CRI(Container Runtime Interface)는 kubelet이 containerd,CRI-O 같은 런타임과 통신하는 표준 인터페이스입니다. CNI는 네트워킹, CSI는 스토리지, OCI는 이미지,런타임 포맷 표준으로 경계가 다릅니다.
Q25. Pod 에 IP를 할당하고 Pod 간 네트워크 연결을 구성하는 플러그인 표준은?
해설
CNI(Container Network Interface)는 Calico,Cilium,Flannel 같은 플러그인이 Pod 네트워킹을 구성하는 표준입니다. CRI는 런타임, CSI는 스토리지, OCI는 이미지 포맷 표준입니다.
Q26. 외부 스토리지 시스템을 Kubernetes에 연결해 볼륨을 프로비저닝,마운트하는 표준 인터페이스는?
해설
CSI(Container Storage Interface)는 외부 스토리지 공급자가 Kubernetes에 볼륨을 제공하는 표준입니다. CRI는 런타임, CNI는 네트워킹과의 경계를 나눕니다.
Q27. 다음 중 Kubernetes에서 흔히 사용되는 CRI 호환 컨테이너 런타임은? (Choose TWO)
해설
containerd와 CRI-O는 모두 CRI를 구현하는 컨테이너 런타임입니다. Calico는 CNI 플러그인, etcd는 상태 저장소, Prometheus는 모니터링 도구로 런타임이 아닙니다.
Q28. 컨테이너 이미지 포맷과 런타임 동작의 업계 표준을 정의해 이미지를 여러 도구 사이에서 호환되게 하는 표준은?
해설
OCI는 이미지 포맷과 런타임 명세를 표준화해 Docker,containerd,Podman 등이 같은 이미지를 다룰 수 있게 합니다. CRI,CNI,CSI는 각각 Kubernetes 내부의 런타임,네트워킹,스토리지 인터페이스입니다.
Q29. “누가 어떤 리소스에 어떤 동작을 할 수 있는가"를 역할 기반으로 제어하는 Kubernetes의 권한 모델은?
해설
RBAC(Role-Based Access Control)은 Role,ClusterRole과 바인딩으로 사용자,서비스 계정의 권한을 제어합니다. NetworkPolicy는 트래픽 제어, SecurityContext는 컨테이너 실행 권한 설정으로 인증,인가 모델과는 다릅니다.
Q30. Pod 간 네트워크 트래픽을 허용,차단하는 규칙을 정의하는 리소스는?
해설
NetworkPolicy는 라벨 셀렉터 기반으로 Pod 의 인그레스,이그레스 트래픽을 허용하거나 차단합니다. 다만 NetworkPolicy를 강제하려면 이를 지원하는 CNI 플러그인이 필요합니다. Ingress는 외부 HTTP 라우팅으로 역할이 다릅니다.
Q31. 컨테이너를 root가 아닌 사용자로 실행하거나 권한 상승을 막는 등 컨테이너,Pod 단위 보안 설정을 지정하는 필드는?
해설
SecurityContext는 runAsNonRoot, readOnlyRootFilesystem, capability 제한 같은 컨테이너,Pod 보안 설정을 담습니다. RBAC은 API 권한, NetworkPolicy는 네트워크 트래픽을 다룹니다.
Q32. 관리자가 미리 만들어 둔 실제 스토리지 자원과, 사용자가 필요한 용량,접근 모드를 요청하는 리소스의 짝으로 옳은 것은?
해설
PV는 실제 스토리지 자원이고 PVC는 사용자의 스토리지 요청입니다. PVC가 조건에 맞는 PV에 바인딩되어 Pod 가 볼륨을 사용합니다. 나머지 짝은 설정,네트워킹,권한으로 영역이 다릅니다.
Q33. 서비스 간 통신을 애플리케이션 코드 변경 없이 mTLS 암호화,트래픽 관리,관측으로 다루는 계층을 무엇이라 하는가?
해설
Service Mesh(Istio,Linkerd 등)는 사이드카 프록시로 서비스 간 통신에 mTLS,트래픽 라우팅,관측 기능을 코드 변경 없이 추가합니다. Ingress Controller는 외부 진입 라우팅, CNI는 기본 네트워킹을 담당합니다.
Q34. Service Mesh에서 각 애플리케이션 Pod 옆에 함께 배포되어 트래픽을 가로채는 프록시를 부르는 패턴 이름은?
해설
Service Mesh는 sidecar 패턴으로 각 Pod 에 프록시(예: Envoy)를 붙여 통신을 가로채고 관리합니다. init container는 본 컨테이너 시작 전에 한 번 실행되고 종료되는 컨테이너로 역할이 다릅니다.
Domain 3: Cloud Native Architecture #
Q35. CPU 사용률 같은 지표에 따라 워크로드의 Pod 복제본 수를 자동으로 늘리거나 줄이는 컴포넌트는?
해설
HPA는 부하에 따라 복제본 수(가로 방향)를 조절합니다. VPA는 Pod 의 CPU,메모리 요청량(세로 방향)을 조절하고, Cluster Autoscaler는 노드 수를 조절합니다.
Q36. 개별 Pod 의 CPU,메모리 요청과 제한 값을 사용 패턴에 맞춰 자동으로 조정하는 컴포넌트는?
해설
VPA(Vertical Pod Autoscaler)는 Pod 의 리소스 요청,제한을 세로로 조정합니다. HPA는 복제본 수, Cluster Autoscaler는 노드 수를 다루는 점에서 구분됩니다.
Q37. 스케줄링할 노드 용량이 부족해 Pending 상태인 Pod 가 생길 때 클라우드에서 노드를 추가하는 컴포넌트는?
해설
Cluster Autoscaler는 배치할 곳이 없어 Pending인 Pod 가 생기면 노드를 추가하고, 노드가 비면 줄여 비용을 절감합니다. HPA,VPA는 Pod 수준의 스케일링을 담당합니다.
Q38. 요청이 들어올 때만 함수가 실행되고 유휴 시 0으로 축소되어 비용을 줄이는 클라우드 네이티브 실행 모델은?
해설
서버리스(FaaS, Function as a Service)는 이벤트 기반으로 함수를 실행하고 유휴 시 0으로 스케일다운합니다. Kubernetes 위에서는 Knative가 대표적인 서버리스 플랫폼입니다.
Q39. Kubernetes 위에서 서버리스 워크로드와 0으로의 스케일다운을 제공하는 대표적인 CNCF 프로젝트는?
해설
Knative는 Kubernetes 위에서 서버리스 배포,자동 스케일링(0까지),이벤트 처리를 제공합니다. Prometheus는 모니터링, ArgoCD는 GitOps, Envoy는 프록시로 영역이 다릅니다.
Q40. CNCF 프로젝트의 성숙도 단계를 낮은 것부터 높은 순서로 올바르게 나열한 것은?
해설
CNCF 성숙도 단계는 Sandbox(초기) → Incubating(성장) → Graduated(성숙)의 순서입니다. Kubernetes,Prometheus,Envoy 등이 Graduated 단계에 해당합니다.
Q41. 다음 중 클라우드 네이티브 아키텍처의 핵심 성질로 보기 어려운 것은?
해설
클라우드 네이티브는 마이크로서비스,자가 치유,선언형 자동화를 지향합니다. 모놀리식을 강제로 묶는 것은 그 반대 방향이므로 핵심 성질로 보기 어렵습니다.
Q42. 관측 데이터(메트릭,로그,트레이스)의 생성과 수집 방식을 표준화해 특정 벤더에 묶이지 않게 하는 CNCF 오픈 스탠다드 프로젝트는?
해설
OpenTelemetry는 텔레메트리 데이터 수집,전송을 표준화하는 벤더 중립 프로젝트입니다. Prometheus는 메트릭 저장,질의, Jaeger는 트레이싱 백엔드, Fluentd는 로그 수집기로 각자 특정 영역에 집중합니다.
Domain 4: Cloud Native Observability #
Q43. 옵저버빌리티의 세 기둥(three pillars)으로 올바르게 묶인 것은?
해설
옵저버빌리티의 세 기둥은 메트릭,로그,트레이스입니다. SLI,SLO,SLA는 신뢰성 목표 지표 체계이고, CPU,메모리는 메트릭의 한 예일 뿐입니다.
Q44. 시계열 메트릭을 수집,저장하고 PromQL로 질의하는, 클라우드 네이티브에서 가장 널리 쓰이는 모니터링 도구는?
해설
Prometheus는 시계열 메트릭을 pull 방식으로 수집,저장하고 PromQL로 질의합니다. Jaeger는 분산 트레이싱, Fluentd는 로그 수집, Grafana는 시각화 대시보드로 역할이 나뉩니다.
Q45. 한 요청이 여러 마이크로서비스를 거치는 전체 경로와 각 구간의 지연을 따라가 병목을 찾는 관측 데이터는?
해설
분산 트레이스는 요청이 서비스들을 통과하는 경로와 각 구간의 소요 시간을 이어 보여 줍니다. 메트릭은 집계 수치, 로그는 개별 사건 기록으로 단일 요청의 종단 경로를 추적하지는 않습니다.
Q46. 클라우드 네이티브 환경에서 리소스 사용량을 가시화하고 낭비를 줄여 비용을 관리하는 실천을 무엇이라 하는가?
해설
FinOps는 클라우드 비용 가시화와 최적화를 다루는 실천으로 Kubecost 같은 도구가 쓰입니다. GitOps는 Git 기반 배포, DevSecOps는 보안 통합 개발 운영으로 비용 관리와는 초점이 다릅니다.
Domain 5: Cloud Native Application Delivery #
Q47. Git 저장소를 원하는 상태의 단일 소스로 삼아 클러스터 상태를 그에 맞춰 자동으로 동기화하는 운영 방식은?
해설
GitOps는 Git을 desired state의 단일 소스(source of truth)로 두고 에이전트가 클러스터를 그 상태로 지속 동기화합니다. 변경은 항상 Git 커밋,PR을 거치므로 감사와 롤백이 쉽습니다.
Q48. 다음 중 GitOps를 구현하는 대표적인 CNCF 도구로 올바르게 묶인 것은? (Choose TWO)
해설
ArgoCD와 Flux는 Git의 상태를 클러스터에 동기화하는 대표적 GitOps 도구입니다. Helm은 패키지 관리, Prometheus는 모니터링, Istio는 Service Mesh로 GitOps 동기화 자체를 담당하지는 않습니다.
Q49. GitOps에서 운영자가 클러스터에 직접 kubectl로 명령형 변경을 가하지 않고 Git 변경만 거치게 하는 이유로 가장 적절한 것은?
해설
GitOps의 핵심 이점은 모든 변경이 Git 한 곳을 거쳐 이력,리뷰,롤백이 가능해지는 데 있습니다. 클러스터를 직접 수정하면 Git 상태와 어긋나는 drift가 생겨 자동 동기화가 깨집니다.
Q50. 코드 변경을 자동으로 빌드,테스트하고 이어서 배포까지 자동화하는 파이프라인을 통칭하는 용어는?
해설
CI/CD는 지속적 통합(Continuous Integration)과 지속적 배포(Continuous Delivery/Deployment)를 묶은 자동화 파이프라인입니다. RBAC은 권한, CRD는 사용자 정의 리소스, CRI는 런타임 인터페이스로 영역이 다릅니다.
채점 #
전체 점수
정답 0 / 0
답변 0 / 0
| 점수 구간 | 평가 | 다음 단계 |
|---|---|---|
| 45+ (90%↑) | 매우 안정. 시험 예약 | 시험 응시 |
| 38〜44 (76〜88%) | 합격권. 약한 도메인 한 번 더 | 약점 도메인 #2〜#8 재정독 |
| 30〜37 (60〜74%) | 부족. 약한 도메인 집중 학습 | 두 약점 도메인 + 다른 모의고사 |
| 29 이하 | 한 바퀴 더 필요 | 시리즈 전체 재정독 |
도메인별 점수 분석 #
각 도메인의 정답 수를 세어 약점을 찾습니다.
| 도메인 | 문항 수 | 권장 정답 (75%) | 부족 시 복습 |
|---|---|---|---|
| Domain 1 (Q1〜Q23) | 23 | 17+ | #2,#3 |
| Domain 2 (Q24〜Q34) | 11 | 8+ | #4 |
| Domain 3 (Q35〜Q42) | 8 | 6+ | #5 |
| Domain 4 (Q43〜Q46) | 4 | 3+ | #6 |
| Domain 5 (Q47〜Q50) | 4 | 3+ | #7 |
비중이 46%로 가장 큰 Domain 1에서 점수를 확보하는 것이 합격의 핵심입니다. Domain 1과 Domain 2를 합치면 전체의 68%이므로, 이 두 도메인이 흔들리면 나머지 세 도메인을 다 맞춰도 합격선을 넘기기 어렵습니다.
합격선을 넘긴 경우 #
- 38문항 이상을 맞췄다면 합격권입니다. 시험 예약을 진행하시기 바랍니다 (Linux Foundation 교육 포털)
- 응시 직전 #8의 시험 팁과 자주 틀리는 패턴을 마지막으로 한 번 더 훑습니다
- 응시일은 학습 동기가 유지되는 1〜2주 안으로 잡습니다
- 온라인 감독(PSI) 환경 점검은 응시 전날 미리 마쳐 둡니다
합격선을 못 넘긴 경우 #
- 도메인별 점수를 보고 가장 부족한 도메인부터 다시 정리합니다
- 본 시리즈의 해당 글을 한 번 더 읽되, 표,매핑,함정 섹션을 중심으로 봅니다
- CNCF가 제공하는 공식 KCNA 학습 자료로 다른 출제 패턴도 풀어 봅니다
- 1주 정도 후 본 모의고사를 다시 풀어 진척도를 확인합니다
시리즈 마무리 #
KCNA 시리즈 9편이 모두 끝났습니다. 이 시리즈가 만든 것을 정리하겠습니다.
- #1. 시험 구조와 학습 전략
- #2. Domain 1 아키텍처와 핵심 리소스
- #3. Domain 1 API,컨테이너,스케줄링
- #4. Domain 2 런타임,보안,네트워킹,스토리지,Service Mesh
- #5. Domain 3 오토스케일링,서버리스,커뮤니티,오픈 스탠다드
- #6. Domain 4 텔레메트리,Prometheus,비용 관리
- #7. Domain 5 GitOps,CI/CD
- #8. 시험 팁과 자주 틀리는 패턴
- #9. 50문항 모의고사 ← 이번 글
K8s 실무 트랙 26편이 minikube와 kubectl 위의 감각이라면, 본 시리즈는 그 감각을 객관식 시험 문제로 풀어내는 어휘를 얹는 작업이었습니다. KCNA 합격 후 다음 단계는 터미널에서 직접 클러스터를 다루는 CKAD(앱 개발자)와 CKA(클러스터 관리자) 실기 자격증이며, 각각 독립된 시리즈로 정리될 예정입니다.
시험 합격을 기원합니다.