Ambassador 컨테이너 패턴은 어떤 목적으로 사용됩니까?

A) 로그를 수집하여 외부로 전송한다 B) 메인 컨테이너를 대신하여 외부 서비스와의 연결을 프록시하고, 연결 관리를 단순화한다 C) 초기화 작업을 수행한다 D) 데이터를 변환하여 메인 컨테이너에 전달한다

정답: B

Ambassador 패턴은 메인 컨테이너가 localhost로 통신하면, Ambassador 컨테이너가 외부 서비스(예: 데이터베이스, 캐시)로의 연결을 프록시합니다. 이를 통해 서비스 디스커버리, 연결 풀링, TLS 처리 등을 메인 앱에서 분리할 수 있습니다.

Adapter 컨테이너 패턴의 특징은?

A) 메인 컨테이너의 트래픽을 프록시한다 B) 메인 컨테이너의 출력 데이터를 표준화된 형식으로 변환한다 C) 메인 컨테이너와 동일한 작업을 수행한다 D) 초기화 작업만 담당한다

정답: B

Adapter 패턴은 메인 컨테이너의 출력(로그, 메트릭 등)을 표준화된 형식으로 변환합니다. 예를 들어 다양한 형식의 로그를 공통 JSON 형식으로 변환하거나, 애플리케이션별 메트릭을 Prometheus 형식으로 변환하는 데 사용됩니다.

Pod에 3개의 Init 컨테이너가 정의되어 있고, 두 번째 Init 컨테이너가 실패하면?

A) 세 번째 Init 컨테이너가 실행된다 B) 메인 컨테이너가 바로 시작된다 C) Pod의 restartPolicy에 따라 두 번째 Init 컨테이너가 재시도되며, 성공할 때까지 세 번째는 실행되지 않는다 D) Pod가 즉시 삭제된다

정답: C

Init 컨테이너는 순서대로 실행되며, 각각 성공해야 다음으로 넘어갑니다. 하나가 실패하면 restartPolicy에 따라 재시도됩니다. Always나 OnFailure 정책이면 재시도하고, Never이면 Pod가 Failed 상태가 됩니다. 모든 Init 컨테이너가 성공해야 메인 컨테이너가 시작됩니다.

helm install 시 values.yaml의 특정 값을 오버라이드하려면?

A) values.yaml 파일을 직접 수정해야만 한다 B) --set 플래그나 -f 플래그로 커스텀 values 파일을 지정할 수 있다 C) 환경 변수로만 오버라이드 가능하다 D) ConfigMap을 사용해야 한다

정답: B

helm install이나 helm upgrade 시 --set key=value로 개별 값을 오버라이드하거나, -f custom-values.yaml로 별도의 values 파일을 지정할 수 있습니다. --set이 -f보다 우선합니다. 복잡한 오버라이드는 파일을 사용하는 것이 좋습니다.

helm upgrade 후 문제가 발생하여 이전 버전으로 롤백하려면?

A) helm delete 후 재설치해야 한다 B) helm rollback 명령으로 이전 리비전으로 롤백할 수 있다 C) kubectl rollout undo를 사용한다 D) values.yaml을 이전 값으로 변경하고 다시 upgrade한다

정답: B

helm rollback RELEASE_NAME REVISION 명령으로 특정 리비전으로 롤백할 수 있습니다. helm history RELEASE_NAME으로 리비전 목록을 확인하고, 원하는 리비전 번호를 지정합니다. 롤백도 새 리비전으로 기록됩니다.

Helm chart를 설치하기 전에 렌더링된 YAML 매니페스트를 확인하려면?

A) helm install --dry-run 또는 helm template 명령을 사용한다 B) kubectl apply --dry-run만 사용할 수 있다 C) values.yaml을 직접 읽어야 한다 D) Helm은 미리보기를 지원하지 않는다

정답: A

helm template은 로컬에서 chart를 렌더링하여 YAML을 출력합니다. helm install --dry-run은 서버 사이드 검증도 포함하여 렌더링합니다. 두 명령 모두 실제 리소스를 생성하지 않으므로 배포 전 검증에 유용합니다.

Helm chart에서 다른 chart에 대한 의존성을 관리하려면?

A) 수동으로 모든 YAML 파일을 복사한다 B) Chart.yaml의 dependencies 섹션에 정의하고 helm dependency update를 실행한다 C) requirements.txt 파일을 사용한다 D) kubectl로 의존성을 관리한다

정답: B

Chart.yaml의 dependencies 섹션에 의존 chart의 이름, 버전, 리포지토리를 정의합니다. helm dependency update를 실행하면 charts/ 디렉토리에 의존 chart가 다운로드됩니다. condition이나 tags를 사용하여 선택적으로 활성화할 수도 있습니다.

Sidecar 컨테이너와 메인 컨테이너 간에 파일을 공유하려면?

A) 네트워크를 통해서만 공유할 수 있다 B) emptyDir 볼륨을 정의하고 양쪽 컨테이너에서 volumeMounts로 마운트한다 C) 컨테이너 간 직접 파일 시스템 접근이 가능하다 D) ConfigMap만 사용할 수 있다

정답: B

emptyDir 볼륨을 Pod 수준에서 정의하고, 각 컨테이너의 volumeMounts에서 해당 볼륨을 마운트하면 동일한 디렉토리를 공유할 수 있습니다. emptyDir는 Pod 생명주기에 따라 생성/삭제되며, medium: Memory로 설정하면 tmpfs를 사용할 수도 있습니다.

Helm에서 pre-install, post-install 같은 hook의 용도는?

A) Kubernetes 이벤트를 모니터링한다 B) chart 설치/업그레이드/삭제의 특정 시점에 Job이나 다른 리소스를 실행할 수 있게 한다 C) 네트워크 정책을 자동 설정한다 D) Pod 재시작 정책을 관리한다

정답: B

Helm hook은 릴리스 라이프사이클의 특정 시점에 작업을 실행합니다. 예를 들어 pre-install로 데이터베이스 마이그레이션, post-install로 초기 데이터 로딩, pre-delete로 백업 수행 등이 가능합니다. hook은 annotation으로 리소스에 지정됩니다.

Kubernetes 1.28+에서 도입된 Sidecar 컨테이너(restartPolicy: Always인 initContainers)의 동작은?

A) 메인 컨테이너와 동시에 시작된다 B) Init 컨테이너 순서대로 시작되지만, 시작 후 종료를 기다리지 않고 다음 Init 컨테이너가 실행되며 Pod 종료 시까지 계속 실행된다 C) 메인 컨테이너 이후에 시작된다 D) Init 컨테이너와 완전히 동일하게 동작한다

정답: B

Kubernetes 1.28+에서 initContainers에 restartPolicy: Always를 설정하면 네이티브 사이드카로 동작합니다. 기존 Init 컨테이너 순서에 따라 시작되지만, 시작 후 완료를 기다리지 않고 다음 컨테이너가 진행됩니다. Pod 전체 생명주기 동안 실행되며, Pod 종료 시 메인 컨테이너 이후에 종료됩니다.

CRD를 생성하면 어떤 일이 가능해집니까?

A) 기존 Kubernetes 리소스의 스키마를 변경할 수 있다 B) 새로운 API 리소스 타입을 정의하여 kubectl로 관리할 수 있는 커스텀 리소스를 만들 수 있다 C) Kubernetes 코어 API를 수정할 수 있다 D) Pod의 런타임 동작을 변경할 수 있다

정답: B

CRD를 생성하면 Kubernetes API에 새로운 리소스 타입이 등록됩니다. kubectl로 해당 리소스의 CRUD 작업이 가능하며, etcd에 저장됩니다. Operator 패턴에서 CRD는 원하는 상태를 선언적으로 정의하는 데 사용됩니다.

CRD의 커스텀 리소스에 대해 필드 검증(validation)을 설정하려면?

A) 별도의 Webhook을 반드시 사용해야 한다 B) CRD의 spec.versions.schema.openAPIV3Schema에 JSON Schema를 정의한다 C) ConfigMap에 검증 규칙을 저장한다 D) Kubernetes는 커스텀 리소스 검증을 지원하지 않는다

정답: B

CRD의 openAPIV3Schema 필드에 JSON Schema를 정의하면 커스텀 리소스 생성/수정 시 필드 타입, 필수 필드, 패턴 등을 자동으로 검증합니다. 더 복잡한 검증이 필요하면 Validating Admission Webhook을 추가로 사용할 수 있습니다.

Validating Admission Webhook은 언제 호출되며 어떤 역할을 합니까?

A) 리소스가 etcd에 저장된 후 호출된다 B) API 요청이 인증/인가를 통과한 후, etcd에 저장되기 전에 호출되어 요청을 허용하거나 거부한다 C) kubectl 명령 실행 전에 호출된다 D) Pod 시작 시 호출된다

정답: B

Validating Admission Webhook은 API 요청이 인증, 인가, 뮤테이션 단계를 통과한 후 호출됩니다. 요청을 검사하여 허용(allow) 또는 거부(deny)를 결정합니다. 요청 내용을 변경할 수는 없으며, 변경이 필요하면 Mutating Admission Webhook을 사용합니다.

두 종류의 Webhook이 모두 설정된 경우 실행 순서는?

A) Validating이 먼저 실행된다 B) Mutating이 먼저 실행되고, 그 다음 Validating이 실행된다 C) 동시에 실행된다 D) 순서는 무작위이다

정답: B

Admission 처리 순서는: 1) Mutating Admission Webhook이 먼저 실행되어 요청을 수정, 2) 이후 Validating Admission Webhook이 수정된 요청을 검증합니다. 이 순서 덕분에 Mutating에서 추가된 기본값 등을 Validating에서 검증할 수 있습니다.

Kubernetes API에서 특정 리소스의 API 버전이 deprecated(지원 중단)되었을 때 해야 할 일은?

A) 아무것도 하지 않아도 된다 B) deprecated된 API 버전을 사용하는 모든 매니페스트와 도구를 새 API 버전으로 업데이트해야 한다 C) Kubernetes가 자동으로 마이그레이션한다 D) 이전 버전 클러스터로 다운그레이드한다

정답: B

API 버전이 deprecated되면 일정 릴리스 후 제거됩니다. kubectl convert 명령이나 수동으로 매니페스트의 apiVersion을 업데이트해야 합니다. CI/CD 파이프라인, Helm chart, 운영 스크립트 등에서 사용하는 모든 매니페스트를 확인해야 합니다.

kubectl convert 명령은 어떤 목적으로 사용됩니까?

A) 컨테이너 이미지 형식을 변환한다 B) Kubernetes 리소스 매니페스트의 API 버전을 다른 버전으로 변환한다 C) YAML을 JSON으로 변환한다 D) Secret을 인코딩한다

정답: B

kubectl convert는 리소스 매니페스트의 apiVersion을 변환합니다. 예를 들어 apps/v1beta1의 Deployment를 apps/v1로 변환할 수 있습니다. 이 플러그인은 별도 설치가 필요하며, API 마이그레이션 시 유용합니다.

Admission Webhook 설정에서 failurePolicy: Ignore의 의미는?

A) Webhook 호출이 실패하면 API 요청을 거부한다 B) Webhook 호출이 실패하면 해당 Webhook을 무시하고 API 요청을 허용한다 C) Webhook을 비활성화한다 D) 에러를 로그에만 기록한다

정답: B

failurePolicy: Ignore는 Webhook 서버에 연결할 수 없거나 타임아웃 시 해당 Webhook을 건너뛰고 요청을 허용합니다. failurePolicy: Fail(기본값)은 Webhook 실패 시 API 요청을 거부합니다. 중요한 보안 Webhook은 Fail로, 부가 기능은 Ignore로 설정하는 것이 일반적입니다.

CRD에서 additionalPrinterColumns를 설정하면 어떤 효과가 있습니까?

A) 리소스의 저장 형식이 변경된다 B) kubectl get 명령 출력에 커스텀 열이 추가되어 중요한 필드를 바로 확인할 수 있다 C) 리소스의 검증 규칙이 추가된다 D) API 서버의 성능이 향상된다

정답: B

additionalPrinterColumns를 사용하면 kubectl get 출력에 커스텀 리소스의 특정 필드를 열로 표시할 수 있습니다. jsonPath를 지정하여 spec이나 status의 특정 필드 값을 표시합니다. 리소스의 상태를 빠르게 파악하는 데 유용합니다.

CRD에서 status 서브리소스를 활성화하면 어떤 이점이 있습니까?

A) status 필드가 자동으로 업데이트된다 B) spec과 status의 업데이트가 분리되어, 컨트롤러가 status만 독립적으로 업데이트할 수 있다 C) status 필드가 삭제된다 D) 검증이 비활성화된다

정답: B

status 서브리소스를 활성화하면 /status 엔드포인트가 생성됩니다. 이를 통해 spec 업데이트와 status 업데이트를 분리할 수 있습니다. 사용자는 spec을 변경하고, 컨트롤러는 status를 변경하는 관심사 분리가 가능합니다. RBAC로 별도 권한 관리도 가능합니다.

Admission Webhook이 특정 네임스페이스에만 적용되도록 하려면?

A) 모든 네임스페이스에 적용해야 한다 B) Webhook 설정의 namespaceSelector에 레이블 매칭 조건을 지정한다 C) 네임스페이스마다 별도의 Webhook을 생성해야 한다 D) Pod에 annotation을 추가한다

정답: B

ValidatingWebhookConfiguration이나 MutatingWebhookConfiguration의 namespaceSelector 필드에 matchLabels나 matchExpressions를 지정하면 해당 조건에 맞는 네임스페이스의 리소스에만 Webhook이 적용됩니다. kube-system 등 시스템 네임스페이스를 제외하는 데 자주 사용됩니다.

Startup Probe는 어떤 상황에서 사용됩니까?

A) 컨테이너가 정상적으로 종료되었는지 확인한다 B) 시작하는 데 오래 걸리는 애플리케이션에서 초기화가 완료될 때까지 liveness/readiness 검사를 지연시킨다 C) 트래픽 라우팅을 관리한다 D) 디스크 사용량을 모니터링한다

정답: B

Startup Probe는 컨테이너 시작 시 한 번만 사용되며, 성공할 때까지 liveness와 readiness 프로브가 실행되지 않습니다. Java 앱이나 대규모 데이터 로딩이 필요한 앱처럼 초기화에 시간이 오래 걸리는 경우, liveness 프로브에 의한 불필요한 재시작을 방지합니다.

Kubernetes 1.24+에서 gRPC 기반 health check 프로브를 설정하려면?

A) exec 프로브에서 grpcurl 명령을 사용해야만 한다 B) 프로브에 grpc 필드를 사용하여 포트를 지정한다 C) HTTP 프로브만 사용 가능하다 D) TCP 소켓 프로브로 대체해야 한다

정답: B

Kubernetes 1.24+에서는 grpc 프로브 타입이 GA되었습니다. livenessProbe나 readinessProbe에서 grpc.port를 지정하면 gRPC Health Checking Protocol을 사용하여 health check를 수행합니다. 선택적으로 service 필드로 특정 서비스를 지정할 수 있습니다.

kubectl debug 명령으로 생성되는 임시 컨테이너의 특징은?

A) 영구적으로 Pod에 추가된다 B) 실행 중인 Pod에 임시로 디버깅용 컨테이너를 추가하며, Pod 재시작 없이 트러블슈팅에 사용된다 C) Pod를 새로 생성한다 D) 노드 수준에서만 실행된다

정답: B

임시 컨테이너는 kubectl debug으로 실행 중인 Pod에 추가할 수 있습니다. 프로브, 포트, 리소스 제한 등을 지정할 수 없으며, Pod 재시작 없이 디버깅 도구가 포함된 이미지로 문제를 진단할 수 있습니다. 디버그 이미지가 없는 distroless 컨테이너 문제 해결에 특히 유용합니다.

topologySpreadConstraints를 사용하는 목적은?

A) Pod의 리소스 사용량을 제한한다 B) Pod를 특정 토폴로지 도메인(노드, 존, 리전)에 균등하게 분산 배치한다 C) 네트워크 정책을 설정한다 D) 스토리지를 관리한다

정답: B

topologySpreadConstraints는 Pod를 노드, 가용 영역(zone), 리전 등의 토폴로지 도메인에 걸쳐 균등하게 분산시킵니다. maxSkew로 도메인 간 최대 불균형 수를 지정하고, whenUnsatisfiable로 조건을 만족하지 못할 때의 동작(DoNotSchedule 또는 ScheduleAnyway)을 결정합니다.

maxSkew: 1로 설정하면 어떤 의미입니까?

A) 최대 1개의 Pod만 생성된다 B) 토폴로지 도메인 간 Pod 수 차이가 최대 1을 초과하지 않도록 한다 C) 1개 도메인에만 배치한다 D) 스케줄링 지연이 1초이다

정답: B

maxSkew: 1은 토폴로지 도메인 간 매칭 Pod 수의 최대 차이가 1을 넘지 않아야 함을 의미합니다. 예를 들어 3개 zone에 Pod를 분산할 때, 각 zone의 Pod 수 차이가 1 이내로 유지됩니다. 값이 작을수록 더 균등한 분산을 보장합니다.

Gateway API가 기존 Ingress보다 개선된 점은?

A) Gateway API는 Ingress와 동일하다 B) Gateway API는 역할 기반 분리(인프라 관리자, 앱 개발자), 다중 프로토콜 지원(HTTP, TCP, gRPC), 더 세밀한 라우팅 규칙을 제공한다 C) Gateway API는 HTTP만 지원한다 D) Gateway API는 클러스터 외부에서만 사용된다

정답: B

Gateway API는 GatewayClass, Gateway, HTTPRoute 등의 리소스를 통해 역할 기반 관리를 지원합니다. 인프라팀이 GatewayClass와 Gateway를 관리하고, 앱팀이 Route를 관리합니다. HTTP, TCP, TLS, gRPC 등 다양한 프로토콜과 헤더 기반 라우팅, 가중치 분배 등을 지원합니다.

Gateway API의 HTTPRoute에서 두 서비스에 트래픽을 80:20으로 분배하려면?

A) Ingress annotation을 사용한다 B) HTTPRoute의 backendRefs에 두 서비스를 지정하고 각각 weight를 80과 20으로 설정한다 C) Service의 selector를 변경한다 D) 별도의 로드밸런서를 사용한다

정답: B

HTTPRoute의 rules.backendRefs에 여러 서비스를 지정하고 weight 필드를 설정하면 가중치 기반 트래픽 분배가 가능합니다. 이는 카나리 배포, A/B 테스트, 점진적 롤아웃에 유용합니다.

projected 볼륨 타입은 어떤 목적으로 사용됩니까?

A) 외부 스토리지를 마운트한다 B) 여러 볼륨 소스(Secret, ConfigMap, downwardAPI, serviceAccountToken)를 하나의 디렉토리에 통합 마운트한다 C) 볼륨을 암호화한다 D) 볼륨을 다른 Pod와 공유한다

정답: B

projected 볼륨은 여러 소스의 데이터를 단일 마운트 포인트에 결합합니다. Secret, ConfigMap, Downward API, ServiceAccount 토큰을 하나의 디렉토리에 함께 마운트할 수 있습니다. 특히 bound service account token을 사용할 때 자주 활용됩니다.

Kubernetes 네이티브 리소스만으로 간단한 Canary 배포를 구현하려면?

A) Deployment의 strategy를 Canary로 설정한다 B) 두 개의 Deployment를 만들고 동일한 label selector를 사용하는 Service로 연결한 뒤, 카나리 Deployment의 replicas를 조절하여 트래픽 비율을 관리한다 C) StatefulSet만 사용한다 D) DaemonSet으로만 가능하다

정답: B

Kubernetes에는 네이티브 Canary 배포 전략이 없습니다. 하지만 동일한 Service 셀렉터에 매칭되는 두 Deployment를 생성하고 replica 수를 조절하면 간단한 Canary가 가능합니다. 더 정교한 제어를 위해서는 Istio, Gateway API 등의 가중치 라우팅을 사용합니다.

kubectl debug를 사용하여 노드의 파일 시스템에 접근하려면?

A) SSH로만 접근 가능하다 B) kubectl debug node/NODE_NAME --image=IMAGE 명령으로 노드에 디버깅 Pod를 생성하여 호스트 파일 시스템에 접근한다 C) kubelet을 재시작해야 한다 D) 노드에 DaemonSet을 배포해야 한다

정답: B

kubectl debug node/NODE_NAME 명령은 해당 노드에 특권(privileged) Pod를 생성하고 호스트의 파일 시스템을 /host에 마운트합니다. chroot /host로 호스트 환경에 직접 접근할 수 있어, kubelet 로그 확인, 네트워크 설정 점검, 디스크 상태 확인 등에 유용합니다.