Certified Kubernetes Application Developer (CKAD) #21 풀스케일 실기 모의고사: 18개 작업 + 해설
#1 시험 환경에서 #20 시험 팁까지 전 도메인을 모두 다뤘습니다. 이번 글은 실제 CKAD 형식에 맞춘 실기 모의고사입니다. 전 도메인을 통합한 18개 작업으로 구성했고, 각 작업별로 배점이 정해져 있습니다.
권장 제한 시간은 실제 시험과 같은 2시간입니다. 합격선은 **66%**이며, 18개 작업의 배점을 합산해 채점합니다. 한 작업에 막히면 표시해 두고 넘어간 뒤 쉬운 작업부터 점수를 쌓는 운영이 합격선을 넘기는 길입니다.
각 작업은 먼저 스스로 끝까지 푼 뒤 정답을 펼쳐 보십시오. 정답을 먼저 읽으면 손이 익지 않습니다. 정답에는 kubectl 명령과 필요한 YAML, 그리고 왜 그렇게 푸는지와 자주 빠지는 함정을 짚는 해설이 함께 있습니다.
풀이 방법 #
- minikube나 kind로 로컬 클러스터를 띄웁니다. NetworkPolicy 작업까지 정확히 채점하려면 Calico 같은 CNI가 설치된 환경이 좋습니다(
minikube start --cni=calico). - 작업마다 지정된 컨텍스트와 네임스페이스를 먼저 전환합니다. 이 시리즈에서 반복한 대로 컨텍스트와 네임스페이스 오설정은 정답을 써도 0점입니다.
k config use-context <문제에서 지정한 컨텍스트>
k config set-context --current --namespace=<문제 네임스페이스>- 작업에 필요한 네임스페이스는 시작 전에 미리 만들어 둡니다.
for ns in web build batch data sec net rbac probe cfg deploy; do
kubectl create namespace $ns 2>/dev/null
done- 18개를 끝까지 푼 뒤 정답을 펼쳐 한 번에 채점합니다. 중간에 정답을 보면 실제 시험 감각이 흐려집니다. #1에서 잡은
alias k=kubectl과export do="--dry-run=client -o yaml"셋업을 먼저 적용하면 시간을 아낍니다.
도메인 분포 #
실제 CKAD의 도메인 비중에 맞춰 18개 작업을 배치했습니다.
| # | 도메인 | 작업 수 | 작업 번호 |
|---|---|---|---|
| 1 | Application Design and Build | 4 | 1, 2, 3, 4 |
| 2 | Application Deployment | 4 | 5, 6, 7, 8 |
| 3 | Observability and Maintenance | 3 | 9, 10, 11 |
| 4 | Environment,Configuration,Security | 4 | 12, 13, 14, 15 |
| 5 | Services and Networking | 3 | 16, 17, 18 |
배점은 도메인 비중과 작업 난이도를 반영해 합계 100점으로 두었습니다. 채점 기준은 글 끝에 정리했습니다.
작업 1 (5점): Application Design and Build #
네임스페이스 web에 nginx 이미지로 replicas가 3인 Deployment front를 만드세요. 그다음 이 Deployment를 80 포트로 받아 컨테이너의 80 포트로 전달하는 ClusterIP Service front-svc를 만드세요.
정답
k -n web create deploy front --image=nginx --replicas=3
k -n web expose deploy front --name=front-svc --port=80 --target-port=80해설: 단순 생성 작업은 매니페스트를 손으로 쓰지 않고 명령형 generator로 끝내는 것이 가장 빠릅니다. expose는 Deployment의 selector를 자동으로 가져오므로 Service의 selector를 직접 적을 필요가 없습니다. --target-port를 생략하면 --port와 같은 값으로 설정되므로 두 값이 같을 때는 생략해도 됩니다.
작업 2 (6점): Application Design and Build #
네임스페이스 web에 Pod cache-loader를 만드세요. 이 Pod는 메인 컨테이너로 redis 이미지를 실행하고, 그보다 먼저 init container wait-dns가 busybox 이미지로 until nslookup front-svc.web.svc.cluster.local; do sleep 2; done 명령을 수행해 Service DNS가 준비될 때까지 기다린 뒤 메인 컨테이너가 시작되도록 하세요.
정답
k -n web run cache-loader --image=redis $do > cache.yaml생성한 뼈대에 init container를 추가합니다.
apiVersion: v1
kind: Pod
metadata:
name: cache-loader
namespace: web
spec:
initContainers:
- name: wait-dns
image: busybox
command: ["sh", "-c", "until nslookup front-svc.web.svc.cluster.local; do sleep 2; done"]
containers:
- name: cache-loader
image: redisk apply -f cache.yaml해설: init container는 메인 컨테이너 시작 전에 순서대로 실행되어 성공해야만 다음 단계로 넘어갑니다. 함정은 command를 셸 형태로 줄 때 ["sh", "-c", "..."]로 감싸지 않으면 until 같은 셸 문법이 동작하지 않는다는 점입니다. 작업 1의 Service가 있어야 init container가 종료되므로, 두 작업을 함께 검증할 수 있습니다.
작업 3 (6점): Application Design and Build #
네임스페이스 web에 Pod printer를 만드세요. busybox 이미지를 사용하되 컨테이너가 시작되면 echo CKAD-2026 && sleep 3600 명령을 실행해야 합니다. 이미지의 기본 entrypoint가 아니라 이 명령으로 덮어쓰세요.
정답
k -n web run printer --image=busybox --command -- sh -c "echo CKAD-2026 && sleep 3600"생성된 매니페스트는 다음과 같은 형태입니다.
spec:
containers:
- name: printer
image: busybox
command: ["sh", "-c", "echo CKAD-2026 && sleep 3600"]해설: kubectl run에서 --command를 붙이면 -- 뒤의 토큰이 컨테이너의 command(Docker의 entrypoint)로 들어갑니다. --command를 빼면 같은 토큰이 args로 들어가 기본 entrypoint의 인자로 동작하므로 의도와 달라집니다. 명령 자체에 &&가 있으므로 sh -c로 감싸야 셸이 해석합니다.
작업 4 (5점): Application Design and Build #
네임스페이스 build에 컨테이너 이미지 httpd:2.4를 사용하는 Pod web-static를 만들고, 라벨 tier=frontend와 env=staging을 붙이세요. 그다음 라벨 env=staging을 가진 Pod만 조회하는 명령을 적으세요.
정답
k -n build run web-static --image=httpd:2.4 --labels="tier=frontend,env=staging"
k -n build get pods -l env=staging해설: --labels는 쉼표로 여러 라벨을 한 번에 붙입니다. 라벨 셀렉터 조회는 -l key=value 형태이며, -l env처럼 값을 생략하면 해당 키가 존재하는 모든 Pod를, -l '!env'는 해당 키가 없는 Pod를 고릅니다. 라벨은 CKAD 전반에서 채점 스크립트가 리소스를 찾는 기준이 되므로 오타가 없어야 합니다.
작업 5 (6점): Application Deployment #
네임스페이스 deploy에 nginx:1.25 이미지로 Deployment api를 replicas 4로 만드세요. 그다음 이미지를 nginx:1.26으로 롤링 업데이트하고, 롤아웃이 끝나면 이전 버전으로 롤백하세요. 마지막에 현재 이미지가 nginx:1.25인지 확인하는 명령을 적으세요.
정답
k -n deploy create deploy api --image=nginx:1.25 --replicas=4
k -n deploy set image deploy/api nginx=nginx:1.26
k -n deploy rollout status deploy/api
k -n deploy rollout undo deploy/api
k -n deploy rollout status deploy/api
k -n deploy get deploy api -o jsonpath='{.spec.template.spec.containers[0].image}'해설: set image의 컨테이너 이름은 create deploy로 만든 기본 컨테이너 이름과 같아야 합니다. 여기서는 Deployment 이름과 같은 nginx가 아니라, generator가 붙인 컨테이너 이름을 확인해야 하는데 kubectl create deploy api --image=nginx:1.25의 컨테이너 이름은 이미지의 첫 토큰인 nginx입니다. rollout undo는 바로 직전 리비전으로 되돌리며, 특정 리비전을 지정하려면 --to-revision=N을 씁니다.
작업 6 (6점): Application Deployment #
네임스페이스 batch에 Job pi-calc를 만드세요. perl 이미지로 perl -Mbignum=bpi -wle "print bpi(200)" 명령을 실행하며, 완료가 4번 일어나야 하고(completions) 동시에 2개까지 실행되도록(parallelism) 설정하세요. 재시도는 최대 3회로 제한하세요.
정답
k -n batch create job pi-calc --image=perl $do \
-- perl -Mbignum=bpi -wle "print bpi(200)" > pi.yaml생성한 뼈대에 completions, parallelism, backoffLimit을 추가합니다.
apiVersion: batch/v1
kind: Job
metadata:
name: pi-calc
namespace: batch
spec:
completions: 4
parallelism: 2
backoffLimit: 3
template:
spec:
restartPolicy: Never
containers:
- name: pi-calc
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(200)"]k apply -f pi.yaml해설: completions는 성공해야 하는 Pod 수, parallelism은 동시에 띄울 수, backoffLimit은 실패 재시도 한도입니다. generator는 이 세 필드를 만들어 주지 않으므로 dry-run 뼈대에 직접 추가합니다. Job의 restartPolicy는 Never 또는 OnFailure만 허용하며 Always는 거부됩니다.
작업 7 (5점): Application Deployment #
네임스페이스 batch에 CronJob cleanup을 만드세요. busybox 이미지로 매 5분마다 date; echo cleanup done 명령을 실행하며, 성공한 Job 기록은 3개, 실패한 Job 기록은 1개까지만 보존하세요.
정답
k -n batch create cronjob cleanup --image=busybox \
--schedule="*/5 * * * *" $do -- sh -c "date; echo cleanup done" > cj.yaml생성한 뼈대에 history limit를 추가합니다.
apiVersion: batch/v1
kind: CronJob
metadata:
name: cleanup
namespace: batch
spec:
schedule: "*/5 * * * *"
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 1
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: cleanup
image: busybox
command: ["sh", "-c", "date; echo cleanup done"]k apply -f cj.yaml해설: successfulJobsHistoryLimit과 failedJobsHistoryLimit은 CronJob.spec 바로 아래에 두지, jobTemplate 안에 두지 않습니다. 스케줄 표현식은 분,시,일,월,요일 5필드이며 */5는 5분 간격을 뜻합니다. 명령에 세미콜론이 있으므로 sh -c로 감쌌습니다.
작업 8 (5점): Application Deployment #
네임스페이스 deploy에 다음 두 파일을 가진 kustomize 오버레이를 구성하세요. base/deployment.yaml은 nginx 이미지의 Deployment site이며, 오버레이는 공통 라벨 app=site와 이미지 태그 nginx:1.27을 적용한 뒤 kubectl apply -k로 배포해야 합니다.
정답
base/deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: site
spec:
replicas: 1
selector:
matchLabels:
app: site
template:
metadata:
labels:
app: site
spec:
containers:
- name: nginx
image: nginxbase/kustomization.yaml:
resources:
- deployment.yamloverlay/kustomization.yaml:
resources:
- ../base
labels:
- pairs:
app: site
includeSelectors: false
images:
- name: nginx
newTag: "1.27"k -n deploy apply -k overlay해설: kustomize의 images 변환기는 매니페스트를 직접 고치지 않고 이름이 일치하는 이미지의 태그만 바꿉니다. 라벨 변환은 최신 kustomize에서 commonLabels 대신 labels 항목을 권장하며, selector 까지 바꾸고 싶지 않을 때 includeSelectors: false를 둡니다. apply -k는 디렉터리에서 kustomization.yaml을 찾아 빌드 결과를 적용합니다.
작업 9 (6점): Observability and Maintenance #
네임스페이스 probe에 Pod health를 만드세요. nginx 이미지를 사용하고, 컨테이너의 80 포트로 5초마다 HTTP GET /를 보내는 liveness probe와, 시작 후 5초 뒤부터 3초마다 같은 경로로 확인하는 readiness probe를 붙이세요.
정답
k -n probe run health --image=nginx $do > health.yaml생성한 뼈대에 두 probe를 추가합니다.
spec:
containers:
- name: health
image: nginx
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /
port: 80
periodSeconds: 5
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 3k apply -f health.yaml해설: liveness는 실패하면 컨테이너를 재시작하고, readiness는 실패하면 Service 엔드포인트에서 제외합니다. initialDelaySeconds는 첫 점검까지 대기, periodSeconds는 점검 간격입니다. probe 유형은 httpGet,exec,tcpSocket 셋 중 하나이며 필드 경로가 헷갈리면 k explain pod.spec.containers.livenessProbe로 확인합니다.
작업 10 (5점): Observability and Maintenance #
네임스페이스 probe에 이미 동작 중인 Pod broken이 CrashLoopBackOff 상태입니다. 원인을 진단하고, 가장 최근에 종료된 컨테이너의 직전 로그를 파일 /tmp/broken.log에 저장하세요.
정답
k -n probe describe pod broken
k -n probe logs broken --previous > /tmp/broken.log해설: CrashLoopBackOff는 컨테이너가 반복 종료되는 상태이므로, 현재 실행 중인 로그가 비어 있을 수 있습니다. --previous(-p) 플래그는 직전에 종료된 컨테이너의 로그를 가져오는 핵심입니다. describe의 Events와 Last State의 Reason,Exit Code가 원인을 가르며, OOMKilled,종료 코드 1 등을 여기서 읽습니다.
작업 11 (5점): Observability and Maintenance #
전체 클러스터에서 CPU 사용량이 가장 높은 Pod를 찾으려 합니다. 모든 네임스페이스의 Pod 리소스 사용량을 CPU 기준 내림차순으로 정렬해 출력하는 명령을 적으세요. metrics-server가 설치되어 있다고 가정합니다.
정답
k top pod -A --sort-by=cpu해설: kubectl top은 metrics-server의 데이터를 읽어 실시간 사용량을 보여 줍니다. -A는 --all-namespaces의 축약이고 --sort-by=cpu 또는 --sort-by=memory로 정렬 기준을 정합니다. metrics-server가 없으면 error: Metrics API not available이 나므로, 로컬 클러스터에서는 minikube addons enable metrics-server 같은 사전 설치가 필요합니다.
작업 12 (7점): Environment,Configuration,Security #
네임스페이스 cfg에 ConfigMap app-cfg를 키 APP_MODE=production, LOG_LEVEL=info로 만드세요. 그다음 Pod reader(busybox, sleep 3600)를 만들되, APP_MODE는 환경 변수로 주입하고 ConfigMap 전체는 /etc/config 경로에 volume으로 마운트하세요.
정답
k -n cfg create configmap app-cfg \
--from-literal=APP_MODE=production --from-literal=LOG_LEVEL=info
k -n cfg run reader --image=busybox $do --command -- sleep 3600 > reader.yaml생성한 뼈대에 env와 volume을 추가합니다.
spec:
containers:
- name: reader
image: busybox
command: ["sleep", "3600"]
env:
- name: APP_MODE
valueFrom:
configMapKeyRef:
name: app-cfg
key: APP_MODE
volumeMounts:
- name: cfg-vol
mountPath: /etc/config
volumes:
- name: cfg-vol
configMap:
name: app-cfgk apply -f reader.yaml해설: 단일 키를 env로 줄 때는 configMapKeyRef, 전체를 env로 줄 때는 envFrom.configMapRef, 파일로 마운트할 때는 volumes.configMap을 씁니다. volume으로 마운트하면 각 키가 /etc/config/APP_MODE처럼 파일이 되며, env와 달리 ConfigMap 갱신이 자동 반영됩니다. 이 차이는 #13의 핵심입니다.
작업 13 (6점): Environment,Configuration,Security #
네임스페이스 sec에 Secret db-cred를 키 username=admin, password=s3cr3t로 만드세요. 그다음 Pod db-client(busybox, sleep 3600)에서 password를 환경 변수 DB_PASSWORD로 주입하세요.
정답
k -n sec create secret generic db-cred \
--from-literal=username=admin --from-literal=password=s3cr3t
k -n sec run db-client --image=busybox $do --command -- sleep 3600 > db.yaml생성한 뼈대에 env를 추가합니다.
spec:
containers:
- name: db-client
image: busybox
command: ["sleep", "3600"]
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-cred
key: passwordk apply -f db.yaml해설: Secret 단일 키는 secretKeyRef로 가져오며, ConfigMap의 configMapKeyRef와 구조가 같고 참조 종류만 다릅니다. kubectl create secret은 값을 자동으로 base64 인코딩하므로 직접 인코딩하지 않습니다. 값을 검증할 때는 k -n sec get secret db-cred -o jsonpath='{.data.password}' | base64 -d로 디코딩합니다.
작업 14 (6점): Environment,Configuration,Security #
네임스페이스 sec에 Pod hardened를 만드세요. nginx 이미지를 쓰되 컨테이너를 UID 1000, GID 3000으로 실행하고, 권한 상승을 금지하며(allowPrivilegeEscalation: false), 루트 파일시스템을 읽기 전용으로 두세요.
정답
k -n sec run hardened --image=nginx $do > hardened.yaml생성한 뼈대에 securityContext를 추가합니다.
spec:
containers:
- name: hardened
image: nginx
securityContext:
runAsUser: 1000
runAsGroup: 3000
allowPrivilegeEscalation: false
readOnlyRootFilesystem: truek apply -f hardened.yaml해설: runAsUser,runAsGroup은 Pod 레벨과 컨테이너 레벨 둘 다 둘 수 있고, 컨테이너 레벨이 우선합니다. 반면 allowPrivilegeEscalation과 readOnlyRootFilesystem은 컨테이너 레벨 securityContext에만 있습니다. nginx는 읽기 전용 루트에서 임시 경로 쓰기가 막혀 기동 실패할 수 있으므로, 실제 운영에서는 emptyDir로 쓰기 경로를 따로 마운트합니다. 채점은 필드 설정 여부만 보는 경우가 많습니다.
작업 15 (6점): Environment,Configuration,Security #
네임스페이스 data에 Pod sized를 만드세요. nginx 이미지를 쓰고 CPU 요청 100m,제한 200m, 메모리 요청 128Mi,제한 256Mi를 설정하세요. 이 Pod의 QoS class를 확인하는 명령도 적으세요.
정답
k -n data run sized --image=nginx $do > sized.yaml생성한 뼈대에 resources를 추가합니다.
spec:
containers:
- name: sized
image: nginx
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "200m"
memory: "256Mi"k apply -f sized.yaml
k -n data get pod sized -o jsonpath='{.status.qosClass}'해설: requests와 limits가 모두 설정되었으나 값이 서로 다르므로 이 Pod의 QoS class는 Burstable입니다. requests와 limits가 모든 리소스에서 정확히 같으면 Guaranteed, 아무 값도 없으면 BestEffort가 됩니다. CPU의 m은 밀리코어, 메모리의 Mi는 메비바이트 단위입니다.
작업 16 (6점): Services and Networking #
네임스페이스 net에 nginx 이미지의 Deployment shop을 replicas 2로 만들고, 클러스터 외부에서 노드의 30080 포트로 접근 가능한 NodePort Service shop-np로 노출하세요. Service의 포트는 80, 타깃 포트는 80입니다.
정답
k -n net create deploy shop --image=nginx --replicas=2
k -n net expose deploy shop --name=shop-np --type=NodePort --port=80 --target-port=80nodePort 값을 30080으로 고정합니다.
k -n net patch svc shop-np --type='json' \
-p='[{"op":"replace","path":"/spec/ports/0/nodePort","value":30080}]'해설: expose로 NodePort를 만들면 nodePort는 30000〜32767 범위에서 자동 할당됩니다. 특정 값으로 고정하려면 매니페스트의 spec.ports[0].nodePort를 직접 지정하거나 위처럼 patch 합니다. dry-run으로 YAML을 뽑아 nodePort: 30080을 직접 적어 apply 하는 방법이 더 단순할 수 있습니다.
작업 17 (6점): Services and Networking #
네임스페이스 net에 Ingress shop-ing를 만드세요. 호스트 shop.example.com의 경로 /로 들어오는 트래픽을 작업 16에서 만든 Service shop-np의 80 포트로 라우팅하세요. pathType은 Prefix를 사용하세요.
정답
k -n net create ingress shop-ing \
--rule="shop.example.com/*=shop-np:80" $do > ing.yaml생성된 매니페스트는 다음과 같습니다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: shop-ing
namespace: net
spec:
rules:
- host: shop.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: shop-np
port:
number: 80k apply -f ing.yaml해설: create ingress의 --rule에서 host/path=service:port 형식을 쓰며, 경로 끝의 /*는 pathType: Prefix로 변환됩니다. backend의 port는 number 또는 name으로 지정합니다. 실제로 라우팅이 동작하려면 ingress-nginx 같은 Ingress 컨트롤러가 클러스터에 설치되어 있어야 하지만, 채점은 리소스 정의가 정확한지를 봅니다.
작업 18 (4점): Services and Networking #
네임스페이스 net에 NetworkPolicy db-allow를 만드세요. 라벨 app=db를 가진 Pod로의 ingress 트래픽을, 같은 네임스페이스에서 라벨 role=api를 가진 Pod가 TCP 5432 포트로 접근할 때만 허용하세요. 그 외 ingress는 모두 차단합니다.
정답
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: db-allow
namespace: net
spec:
podSelector:
matchLabels:
app: db
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
role: api
ports:
- protocol: TCP
port: 5432k apply -f db-allow.yaml해설: podSelector는 정책이 적용될 대상 Pod(app=db)를 고르고, ingress.from은 허용할 출발지(role=api)를 고릅니다. NetworkPolicy는 한 Pod에 하나라도 적용되면 명시되지 않은 트래픽은 모두 차단되므로, 별도의 deny-all 정책 없이도 그 외 ingress가 막힙니다. from과 ports를 같은 규칙 안에 두면 두 조건의 AND가 됩니다. NetworkPolicy는 이를 지원하는 CNI에서만 강제됩니다.
채점 기준 #
각 작업의 배점을 합산해 채점합니다. 합계는 100점이며 66점 이상이 합격권입니다.
| 도메인 | 작업,배점 | 소계 |
|---|---|---|
| Application Design and Build | 1(5) , 2(6) , 3(6) , 4(5) | 22 |
| Application Deployment | 5(6) , 6(6) , 7(5) , 8(5) | 22 |
| Observability and Maintenance | 9(6) , 10(5) , 11(5) | 16 |
| Environment,Configuration,Security | 12(7) , 13(6) , 14(6) , 15(6) | 25 |
| Services and Networking | 16(6) , 17(6) , 18(4) | 16 |
| 합계 | (합계) | 100 |
채점은 실제 시험과 같이 결과물 기준입니다. 명령을 어떻게 쳤는지가 아니라 만들어진 리소스가 요구사항과 일치하는지를 봅니다. 한 작업 안에서도 라벨,포트,요청량 같은 항목별로 부분 점수가 나뉘므로, 막히는 항목이 있어도 채울 수 있는 부분은 끝까지 채우는 편이 점수에 유리합니다.
도메인별 약점 복습 #
채점 후 점수가 낮은 도메인을 아래 표의 해당 글로 돌아가 복습하십시오.
| 도메인 | 관련 작업 | 복습할 글 |
|---|---|---|
| Application Design and Build | 1, 2, 3, 4 | #2 , #3 , #4 |
| Application Deployment | 5, 6, 7, 8 | #5 , #7 , #9 , #10 |
| Observability and Maintenance | 9, 10, 11 | #11 , #12 |
| Environment,Configuration,Security | 12, 13, 14, 15 | #13 , #14 , #15 , #16 |
| Services and Networking | 16, 17, 18 | #18 , #19 |
특정 작업에서 시간이 부족했다면 도메인 지식보다 손 빠르기 문제일 수 있습니다. 이 경우 #1 kubectl 셋업과 #20 시간 관리를 다시 읽고, 같은 18개 작업을 시간을 재며 한 번 더 푸십시오. CKAD는 같은 작업을 두세 번 반복하면 작업당 소요 시간이 눈에 띄게 줄어듭니다.
시리즈를 마치며 #
#1의 kubectl 셋업에서 출발해 Pod,멀티 컨테이너,이미지,워크로드,배포 전략,Helm,kustomize,probe,관측,ConfigMap,Secret,RBAC,SecurityContext,리소스,볼륨,Service,Ingress,NetworkPolicy 까지 CKAD 전 도메인을 21편으로 통과했습니다. 이 모의고사에서 66점을 넘겼다면 실제 시험장에서도 충분히 합격선을 넘길 수 있는 손이 만들어졌습니다. 축하합니다.
CKAD가 앱 개발자의 첫 실기였다면, 다음 단계는 클러스터 자체를 운영하는 CKA입니다. 여기서 익힌 kubectl 속도와 dry-run 습관, 매니페스트 감각이 그대로 발판이 되니, 합격의 기세를 이어 다음 실기로 넘어가시기를 권합니다.