Certified Kubernetes Application Developer (CKAD) #21 풀스케일 실기 모의고사: 18개 작업 + 해설

#1 시험 환경에서 #20 시험 팁까지 전 도메인을 모두 다뤘습니다. 이번 글은 실제 CKAD 형식에 맞춘 실기 모의고사입니다. 전 도메인을 통합한 18개 작업으로 구성했고, 각 작업별로 배점이 정해져 있습니다.

권장 제한 시간은 실제 시험과 같은 2시간입니다. 합격선은 **66%**이며, 18개 작업의 배점을 합산해 채점합니다. 한 작업에 막히면 표시해 두고 넘어간 뒤 쉬운 작업부터 점수를 쌓는 운영이 합격선을 넘기는 길입니다.

각 작업은 먼저 스스로 끝까지 푼 뒤 정답을 펼쳐 보십시오. 정답을 먼저 읽으면 손이 익지 않습니다. 정답에는 kubectl 명령과 필요한 YAML, 그리고 왜 그렇게 푸는지와 자주 빠지는 함정을 짚는 해설이 함께 있습니다.

풀이 방법 #

  1. minikube나 kind로 로컬 클러스터를 띄웁니다. NetworkPolicy 작업까지 정확히 채점하려면 Calico 같은 CNI가 설치된 환경이 좋습니다(minikube start --cni=calico).
  2. 작업마다 지정된 컨텍스트와 네임스페이스를 먼저 전환합니다. 이 시리즈에서 반복한 대로 컨텍스트와 네임스페이스 오설정은 정답을 써도 0점입니다.
k config use-context <문제에서 지정한 컨텍스트>
k config set-context --current --namespace=<문제 네임스페이스>
  1. 작업에 필요한 네임스페이스는 시작 전에 미리 만들어 둡니다.
for ns in web build batch data sec net rbac probe cfg deploy; do
  kubectl create namespace $ns 2>/dev/null
done
  1. 18개를 끝까지 푼 뒤 정답을 펼쳐 한 번에 채점합니다. 중간에 정답을 보면 실제 시험 감각이 흐려집니다. #1에서 잡은 alias k=kubectlexport do="--dry-run=client -o yaml" 셋업을 먼저 적용하면 시간을 아낍니다.

도메인 분포 #

실제 CKAD의 도메인 비중에 맞춰 18개 작업을 배치했습니다.

#도메인작업 수작업 번호
1Application Design and Build41, 2, 3, 4
2Application Deployment45, 6, 7, 8
3Observability and Maintenance39, 10, 11
4Environment,Configuration,Security412, 13, 14, 15
5Services and Networking316, 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: redis
k 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=frontendenv=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 apireplicas 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의 restartPolicyNever 또는 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

해설: successfulJobsHistoryLimitfailedJobsHistoryLimitCronJob.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: nginx

base/kustomization.yaml:

resources:
  - deployment.yaml

overlay/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: 3
k 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-cfg
k 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: password
k 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: true
k apply -f hardened.yaml

해설: runAsUser,runAsGroup은 Pod 레벨과 컨테이너 레벨 둘 다 둘 수 있고, 컨테이너 레벨이 우선합니다. 반면 allowPrivilegeEscalationreadOnlyRootFilesystem은 컨테이너 레벨 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 shopreplicas 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=80

nodePort 값을 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: 80
k 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: 5432
k apply -f db-allow.yaml

해설: podSelector는 정책이 적용될 대상 Pod(app=db)를 고르고, ingress.from은 허용할 출발지(role=api)를 고릅니다. NetworkPolicy는 한 Pod에 하나라도 적용되면 명시되지 않은 트래픽은 모두 차단되므로, 별도의 deny-all 정책 없이도 그 외 ingress가 막힙니다. fromports를 같은 규칙 안에 두면 두 조건의 AND가 됩니다. NetworkPolicy는 이를 지원하는 CNI에서만 강제됩니다.


채점 기준 #

각 작업의 배점을 합산해 채점합니다. 합계는 100점이며 66점 이상이 합격권입니다.

도메인작업,배점소계
Application Design and Build1(5) , 2(6) , 3(6) , 4(5)22
Application Deployment5(6) , 6(6) , 7(5) , 8(5)22
Observability and Maintenance9(6) , 10(5) , 11(5)16
Environment,Configuration,Security12(7) , 13(6) , 14(6) , 15(6)25
Services and Networking16(6) , 17(6) , 18(4)16
합계(합계)100

채점은 실제 시험과 같이 결과물 기준입니다. 명령을 어떻게 쳤는지가 아니라 만들어진 리소스가 요구사항과 일치하는지를 봅니다. 한 작업 안에서도 라벨,포트,요청량 같은 항목별로 부분 점수가 나뉘므로, 막히는 항목이 있어도 채울 수 있는 부분은 끝까지 채우는 편이 점수에 유리합니다.

도메인별 약점 복습 #

채점 후 점수가 낮은 도메인을 아래 표의 해당 글로 돌아가 복습하십시오.

도메인관련 작업복습할 글
Application Design and Build1, 2, 3, 4#2 , #3 , #4
Application Deployment5, 6, 7, 8#5 , #7 , #9 , #10
Observability and Maintenance9, 10, 11#11 , #12
Environment,Configuration,Security12, 13, 14, 15#13 , #14 , #15 , #16
Services and Networking16, 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 습관, 매니페스트 감각이 그대로 발판이 되니, 합격의 기세를 이어 다음 실기로 넘어가시기를 권합니다.

X