KCNA模擬試験A

쿠버네티스의 선언형 모델에서 컨트롤러가 하는 일을 가장 정확히 설명한 것은?

• 사용자가 보낸 명령을 순서대로 큐에 넣고 하나씩 실행한다
• 원하는 상태와 현재 상태를 계속 비교해 차이를 줄이는 쪽으로 행동한다
• 매니페스트를 검증한 뒤 통과한 것만 etcd 에 저장하고 끝낸다
• 노드의 자원 여유를 계산해 파드를 어느 노드에 둘지 결정한다

쿠버네티스 오브젝트의 spec 과 status 필드의 관계로 올바른 것은?

• spec 은 컨트롤 플레인이 채우고 status 는 사용자가 채운다
• spec 은 사용자가 원하는 상태를 적고 status 는 시스템이 관찰한 현재 상태를 적는다
• spec 과 status 는 같은 값을 중복 저장해 손상에 대비하는 구조다
• status 는 오브젝트가 삭제될 때만 채워지는 종료 기록용 필드다

네임스페이스에 속하지 않는(cluster-scoped) 리소스로만 짝지어진 것은?

• Node 와 PersistentVolume
• ConfigMap 과 Secret
• Deployment 와 StatefulSet
• Role 과 RoleBinding

kubelet 이 담당하는 일로 올바른 것은?

• 클러스터 전체의 파드를 어느 노드에 배치할지 계산한다
• 자기 노드에 할당된 파드를 컨테이너 런타임으로 띄우고 상태를 apiserver 에 보고한다
• Service 의 가상 IP 를 실제 파드 IP 로 바꾸는 규칙을 노드에 설치한다
• etcd 에 저장된 오브젝트를 주기적으로 백업한다

kube-proxy 를 가장 정확히 설명한 것은?

• 모든 파드 트래픽이 반드시 통과하는 사용자 공간 프록시 프로세스다
• Service 오브젝트를 감시해 노드의 패킷 전달 규칙(iptables 또는 IPVS)을 갱신한다
• 외부에서 들어오는 HTTP 요청의 경로를 보고 백엔드를 고르는 L7 라우터다
• 파드에 IP 를 할당하고 노드 사이의 오버레이 터널을 만든다

etcd 에 대한 설명으로 올바른 것은?

• 메트릭 시계열을 저장하는 시계열 데이터베이스다
• 각 노드가 자기 몫만 따로 저장하는 분산 캐시다
• Raft 합의로 일관성을 지키는 키-값 저장소이며 클러스터 상태의 유일한 원본이다
• 컨테이너 이미지 레이어를 보관하는 내부 레지스트리다

파드에 여러 컨테이너를 함께 넣는 것이 적절한 경우는?

• 프런트엔드와 데이터베이스처럼 서로 다른 주기로 확장해야 하는 두 서비스를 묶을 때
• 로그 수집 사이드카처럼 같은 볼륨과 네트워크를 공유하며 한 몸으로 살고 죽어야 할 때
• 장애 시 서로를 대신할 수 있도록 같은 애플리케이션을 두 벌 올릴 때
• 노드 자원을 아끼려고 서로 관련 없는 작업을 한데 모을 때

initContainer 의 동작으로 올바른 것은?

• 앱 컨테이너와 동시에 시작해 준비 작업을 병렬로 처리한다
• 정의된 순서대로 하나씩 완료된 뒤에야 앱 컨테이너가 시작된다
• 앱 컨테이너가 죽을 때마다 함께 다시 실행되어 상태를 복구한다
• 앱 컨테이너보다 항상 더 많은 자원을 예약해 두는 전용 컨테이너다

파드의 restartPolicy 를 Never 로 두면 kubelet 은 어떻게 동작하는가?

• 컨테이너가 실패해도 다시 시작하지 않고 파드를 Failed 상태로 남긴다
• 컨테이너가 실패하면 파드를 삭제하고 새 파드를 만든다
• 컨테이너가 실패하면 지수 백오프를 두고 다시 시작한다
• 컨테이너가 실패하면 다른 노드로 파드를 옮겨 다시 시도한다

컨테이너의 resources.requests 가 실제로 쓰이는 곳은?

• 컨테이너가 그 값을 넘겨 쓰면 커널이 즉시 프로세스를 종료한다
• 스케줄러가 노드를 고를 때 남은 할당 가능 자원과 비교하는 기준이 된다
• 오토스케일러가 파드 개수를 정할 때만 참고하고 배치에는 쓰이지 않는다
• 컨테이너 시작 시 그만큼의 메모리를 미리 확보해 페이지를 채운다

CPU limits 와 메모리 limits 의 강제 방식이 다른 점으로 올바른 것은?

• CPU 는 초과 시 스로틀링되고 메모리는 초과 시 프로세스가 종료된다
• CPU 는 초과 시 프로세스가 종료되고 메모리는 스로틀링된다
• 둘 다 초과하면 파드가 다른 노드로 축출된다
• 둘 다 경고 이벤트만 남기고 실제로 막지는 않는다

ConfigMap 을 환경변수로 주입한 뒤 ConfigMap 의 값을 바꾸면 실행 중인 파드는 어떻게 되는가?

• kubelet 이 환경변수를 갱신해 다음 요청부터 새 값이 적용된다
• 파드가 자동으로 재시작되어 새 값을 읽는다
• 환경변수는 프로세스 시작 시 고정되므로 파드를 다시 만들기 전까지 옛 값이 유지된다
• apiserver 가 변경을 거부하고 ConfigMap 수정 자체가 실패한다

kubectl describe pod 의 Events 를 먼저 보라고 하는 이유로 가장 적절한 것은?

• Events 에는 컨테이너가 stdout 으로 낸 애플리케이션 로그가 담기기 때문
• Events 에 스케줄링 실패, 이미지 풀 실패, 프로브 실패처럼 파드가 뜨지 못한 이유가 기록되기 때문
• Events 가 etcd 에 영구 보관되어 과거 이력을 모두 볼 수 있기 때문
• Events 를 봐야만 파드에 배정된 IP 와 노드를 알 수 있기 때문

쿠버네티스 API 그룹과 버전 표기에 대한 설명으로 올바른 것은?

• v1 은 코어 그룹을 뜻하고 apps/v1 처럼 그룹 이름이 붙는 경우도 있다
• 모든 리소스는 반드시 그룹 이름을 붙여 core/v1 형태로 써야 한다
• 알파 버전과 정식 버전은 같은 클러스터에 동시에 존재할 수 없다
• API 버전은 클러스터 버전과 항상 같은 숫자를 쓴다

CRD(CustomResourceDefinition)가 하는 일로 올바른 것은?

• 새 리소스 종류를 API 에 등록해 kubectl 과 RBAC 이 기본 리소스처럼 다루게 한다
• 등록한 리소스의 동작 로직까지 함께 제공해 별도 컨트롤러가 필요 없게 한다
• 기존 리소스의 스키마를 덮어써 필드를 추가하거나 제거한다
• 클러스터 밖의 외부 API 를 프록시해 kubectl 로 호출하게 한다

kubectl 이 클러스터에 접속할 때 쓰는 정보가 담긴 곳은?

• 노드의 /var/lib/kubelet/config.yaml
• kubeconfig 파일의 clusters·users·contexts 세 부분
• apiserver 가 발급해 주는 세션 쿠키
• 환경변수 KUBERNETES_SERVICE_HOST 하나

RBAC 에서 Role 과 ClusterRole 의 차이로 올바른 것은?

• Role 은 읽기 권한만, ClusterRole 은 쓰기 권한까지 담을 수 있다
• Role 은 한 네임스페이스 안에서만 유효하고 ClusterRole 은 클러스터 범위 리소스에도 쓸 수 있다
• Role 은 사용자에게, ClusterRole 은 ServiceAccount 에만 연결할 수 있다
• Role 은 즉시 적용되고 ClusterRole 은 apiserver 재시작 뒤에 적용된다

ServiceAccount 를 가장 정확히 설명한 것은?

• 클러스터 관리자가 사람에게 발급하는 로그인 계정이다
• 파드 안의 프로세스가 API 서버에 자신을 증명할 때 쓰는 클러스터 내부 신원이다
• 노드가 컨트롤 플레인에 등록할 때 쓰는 부트스트랩 인증서다
• 이미지 레지스트리 접속용 자격증명만 담는 전용 오브젝트다

쿠버네티스에서 Service 가 필요한 근본적인 이유는?

• 파드 IP 는 파드가 다시 만들어질 때마다 바뀌므로 고정된 접점이 필요하기 때문
• 파드끼리는 IP 로 서로 통신할 수 없도록 막혀 있기 때문
• 파드가 여러 노드에 흩어지면 노드를 넘는 통신이 불가능하기 때문
• 파드는 포트를 열 수 없고 Service 만 포트를 열 수 있기 때문

ClusterIP·NodePort·LoadBalancer 타입의 관계로 올바른 것은?

• 세 타입은 서로 배타적이라 하나를 쓰면 나머지 기능은 없다
• NodePort 는 ClusterIP 위에 노드 포트를 더하고, LoadBalancer 는 그 위에 외부 로드밸런서를 더한다
• LoadBalancer 는 ClusterIP 를 만들지 않고 외부 IP 만 노출한다
• NodePort 는 클러스터 내부에서는 접근할 수 없고 외부에서만 쓸 수 있다

클러스터 안에서 DNS 이름 해석을 담당하는 컴포넌트는?

• kube-proxy
• CoreDNS
• etcd
• kubelet

쿠버네티스 네트워크 모델이 요구하는 조건으로 올바른 것은?

• 모든 파드는 NAT 없이 서로의 IP 로 통신할 수 있어야 한다
• 같은 노드의 파드끼리만 직접 통신하고 노드를 넘을 때는 NAT 를 거쳐야 한다
• 파드는 반드시 노드와 같은 IP 를 공유해야 한다
• 파드 사이의 통신은 항상 Service 를 거쳐야 한다

PersistentVolume 의 Retain 회수 정책이 뜻하는 바는?

• PVC 가 삭제되면 PV 의 데이터를 지우고 다시 바인딩 가능한 상태로 만든다
• PVC 가 삭제되면 PV 와 실제 스토리지가 함께 삭제된다
• PVC 가 삭제되어도 PV 와 데이터가 남고 관리자가 손으로 처리할 때까지 Released 상태에 머문다
• PVC 가 삭제되면 같은 이름의 PVC 가 다시 만들어질 때까지 대기하다 자동 재바인딩된다

StorageClass 를 쓰는 목적으로 가장 적절한 것은?

• PVC 요청이 들어올 때 프로비저너가 볼륨을 자동으로 만들어 주도록 한다
• 이미 만들어진 PV 들을 성능 등급별로 보기 좋게 분류만 해 둔다
• PVC 가 요청할 수 있는 최대 용량을 네임스페이스 단위로 제한한다
• 볼륨의 데이터를 주기적으로 스냅샷으로 백업한다

kubectl apply 가 같은 매니페스트를 두 번 적용해도 결과가 같은 이유는?

• apply 가 실행 전에 기존 오브젝트를 항상 삭제하고 새로 만들기 때문
• 선언한 최종 상태를 보내고 서버가 현재 상태와의 차이만 반영하기 때문
• apiserver 가 같은 요청을 감지하면 무시하도록 캐시를 두기 때문
• kubectl 이 로컬에 이전 실행 기록을 남겨 두 번째 실행을 건너뛰기 때문

쿠버네티스 라벨과 어노테이션의 차이로 올바른 것은?

• 라벨은 셀렉터로 선택할 수 있고 어노테이션은 선택 대상이 아닌 부가 정보를 담는다
• 라벨은 사람만 읽고 어노테이션은 컨트롤러만 읽는다
• 라벨은 값 길이에 제한이 없고 어노테이션은 63자로 제한된다
• 라벨은 생성 후 바꿀 수 없고 어노테이션은 언제든 바꿀 수 있다

오케스트레이터가 없던 시절과 비교해 쿠버네티스가 새로 맡아 준 일로 보기 어려운 것은?

• 노드가 죽었을 때 그 위의 워크로드를 다른 노드에 다시 띄우는 일
• 애플리케이션 코드의 버그를 찾아 자동으로 고쳐 주는 일
• 선언한 복제본 수를 계속 유지하는 일
• 새 버전을 점진적으로 교체하며 배포하는 일

Deployment 의 maxSurge 와 maxUnavailable 을 둘 다 0 으로 두면?

• 가장 안전한 설정이라 무중단 배포가 보장된다
• 쿠버네티스가 자동으로 기본값을 되살려 정상 동작한다
• 옛 파드를 전부 지운 뒤 새 파드를 한 번에 만든다
• 새 파드도 못 만들고 옛 파드도 못 줄여 롤아웃이 진행되지 못한다

kubectl rollout undo 가 이전 버전으로 되돌릴 수 있는 근거는?

• Deployment 가 이전 ReplicaSet 을 revisionHistoryLimit 만큼 남겨 두기 때문
• kubectl 이 로컬 디스크에 이전 매니페스트를 보관하기 때문
• etcd 가 모든 오브젝트의 변경 이력을 무기한 저장하기 때문
• 컨테이너 레지스트리가 이전 이미지를 자동으로 되돌려 주기 때문

StatefulSet 이 Deployment 와 다른 점으로 올바른 것은?

• 파드가 항상 같은 노드에 고정되어 절대 다른 노드로 옮겨지지 않는다
• 복제본을 하나로만 둘 수 있어 수평 확장이 불가능하다
• 볼륨을 쓸 수 없고 메모리에만 상태를 둘 수 있다
• 파드 이름이 0부터의 순번으로 고정되고 각자 자기 PVC 를 계속 물고 간다

Job 의 completions 를 6, parallelism 을 2 로 두면 어떻게 실행되는가?

• 파드 6개를 동시에 띄우고 그중 2개만 성공하면 끝난다
• 2개의 파드가 각각 6번씩 재시작을 반복한다
• 6개의 파드를 순서대로 하나씩만 실행한다
• 한 번에 최대 2개씩 돌려 성공한 파드가 누적 6개가 될 때까지 이어 간다

CronJob 의 concurrencyPolicy: Forbid 가 뜻하는 것은?

• 이전 실행이 아직 끝나지 않았으면 이번 실행을 건너뛴다
• 이전 실행을 강제 종료하고 새 실행을 시작한다
• 동시에 최대 두 개까지만 실행을 허용한다
• 스케줄이 겹치면 뒤의 실행을 큐에 넣었다가 순서대로 돌린다

노드에 taint 를 걸었을 때 일어나는 일로 올바른 것은?

• 그 노드의 모든 파드가 즉시 다른 노드로 옮겨진다
• 그 노드가 클러스터에서 제거되고 kubelet 이 멈춘다
• 그 노드에는 DaemonSet 파드만 들어갈 수 있게 된다
• 대응하는 toleration 이 없는 파드는 그 노드에 새로 스케줄되지 않는다

nodeSelector 와 affinity 의 차이로 올바른 것은?

• nodeSelector 는 라벨이 정확히 맞아야 하는 단순 조건이고 affinity 는 선호 조건과 표현식을 쓸 수 있다
• nodeSelector 는 파드 사이의 관계를, affinity 는 노드와의 관계를 다룬다
• nodeSelector 는 스케줄러가 무시할 수 있고 affinity 는 반드시 지켜진다
• nodeSelector 는 이미 실행 중인 파드도 옮기고 affinity 는 새 파드에만 적용된다

HorizontalPodAutoscaler 가 하는 일로 올바른 것은?

• 파드의 CPU·메모리 요청량을 관측값에 맞춰 조정한다
• 노드가 부족하면 클라우드에 노드를 추가로 요청한다
• 지표를 보고 워크로드의 복제본 수를 늘리거나 줄인다
• 파드를 자원이 남는 노드로 다시 배치한다

파드가 Pending 상태에서 움직이지 않을 때 원인으로 보기 어려운 것은?

• 요청한 자원을 감당할 노드가 없다
• PVC 가 아직 바인딩되지 않았다
• 컨테이너의 애플리케이션이 시작하자마자 에러를 내고 종료한다
• 노드의 taint 를 견딜 toleration 이 없다

ImagePullBackOff 상태의 원인으로 보기 어려운 것은?

• 이미지 이름이나 태그를 잘못 적었다
• 비공개 레지스트리인데 imagePullSecrets 를 붙이지 않았다
• 노드에서 레지스트리로 나가는 네트워크가 막혀 있다
• 컨테이너가 메모리 상한을 넘겨 OOM 으로 종료됐다

kubelet 이 노드의 메모리 압박으로 파드를 축출할 때 우선순위가 가장 높은(먼저 쫓겨나는) 것은?

• requests 와 limits 를 같게 지정한 Guaranteed 파드
• requests 만 지정하고 limits 는 더 크게 지정한 Burstable 파드
• requests 도 limits 도 지정하지 않은 BestEffort 파드
• 축출 순서는 무작위로 정해진다

kubectl drain 이 하는 일로 올바른 것은?

• 노드를 스케줄 불가로 표시하고 그 위의 파드를 안전하게 내보낸다
• 노드를 클러스터에서 즉시 삭제하고 etcd 기록도 지운다
• 노드의 디스크를 비워 이미지 캐시를 정리한다
• 노드의 모든 파드를 그대로 둔 채 새 파드만 막는다

PodDisruptionBudget 이 보호하는 상황으로 올바른 것은?

• 노드가 갑자기 전원이 끊겨 파드가 사라지는 경우
• 컨테이너가 OOM 으로 죽는 경우
• 이미지를 내려받지 못해 파드가 못 뜨는 경우
• 관리자가 노드를 비우는 것처럼 계획된 중단으로 파드가 한꺼번에 사라지는 경우

DaemonSet 이 적합한 워크로드로 가장 알맞은 것은?

• 요청량에 따라 복제본을 늘렸다 줄였다 해야 하는 웹 API
• 하루에 한 번 정해진 시각에만 실행되는 정산 배치
• 노드마다 하나씩 떠서 그 노드의 로그와 지표를 수집하는 에이전트
• 순번과 전용 볼륨이 필요한 데이터베이스 클러스터

Deployment 의 셀렉터와 파드 템플릿 라벨이 어긋나면 어떻게 되는가?

• apiserver 가 유효성 검사에서 거부해 생성이 실패한다
• 생성은 되지만 셀렉터가 자기 파드를 못 찾아 복제본이 무한정 늘어난다
• 쿠버네티스가 템플릿 라벨을 셀렉터에 맞춰 자동으로 고쳐 준다
• 경고만 남기고 셀렉터를 무시한 채 정상 동작한다

쿠버네티스가 애플리케이션을 '셀프힐링' 한다고 말할 때의 정확한 의미는?

• 컨테이너 이미지의 취약점을 찾아 자동으로 패치한다
• 요청이 실패하면 애플리케이션 대신 응답을 만들어 돌려준다
• 데이터베이스가 손상되면 백업에서 자동으로 복원한다
• 실패한 컨테이너를 다시 띄우고 사라진 복제본을 다시 만들어 선언한 상태로 되돌린다

Helm 차트가 매니페스트 묶음보다 나은 점으로 가장 정확한 것은?

• 설치한 릴리스의 버전을 추적해 이전 상태로 되돌릴 수 있다
• 매니페스트를 자동으로 검증해 문법 오류가 있으면 고쳐 준다
• 컨테이너 이미지를 함께 담고 있어 레지스트리가 필요 없다
• 클러스터에 적용할 때 RBAC 권한을 자동으로 넉넉히 만들어 준다

Kustomize 가 Helm 과 다른 접근을 취하는 지점으로 올바른 것은?

• 차트 저장소에서 패키지를 내려받아 설치하는 것을 기본으로 한다
• 클러스터에 서버 컴포넌트를 설치해야만 동작한다
• 템플릿 언어 없이 원본 YAML 에 패치를 겹쳐 환경별 변형을 만든다
• YAML 대신 전용 DSL 로 리소스를 기술한다

GitOps 에서 '조정(reconciliation)'이 뜻하는 것은?

• 개발자가 파이프라인에서 kubectl apply 를 실행하는 단계
• 여러 개발자의 브랜치를 병합해 충돌을 푸는 일
• 배포 후 통합 테스트를 돌려 결과를 보고하는 일
• 에이전트가 Git 의 선언과 클러스터의 실제 상태를 계속 비교해 차이를 되돌리는 일

블루-그린 배포와 카나리 배포의 차이로 올바른 것은?

• 블루-그린은 새 버전을 위한 환경을 따로 두지 않고, 카나리는 환경을 두 벌 운영한다
• 블루-그린은 되돌리기가 불가능하고 카나리만 롤백할 수 있다
• 블루-그린은 트래픽을 한 번에 전환하고, 카나리는 일부 트래픽만 새 버전에 보내며 비율을 늘린다
• 블루-그린은 상태가 있는 서비스에만, 카나리는 상태가 없는 서비스에만 쓸 수 있다

Ingress 리소스만 만들고 아무 일도 일어나지 않았다면 가장 먼저 의심할 것은?

• Service 의 타입이 ClusterIP 라서 Ingress 가 붙을 수 없다
• Ingress 는 네임스페이스를 넘어서만 동작하므로 같은 네임스페이스에 두면 안 된다
• Ingress 는 HTTPS 만 지원하므로 인증서 없이는 동작하지 않는다
• 클러스터에 Ingress 컨트롤러가 설치되어 있지 않다

Gateway API 가 Ingress 를 보완하려는 문제로 가장 적절한 것은?

• Ingress 가 TLS 종료를 전혀 지원하지 않는 문제
• Ingress 가 하나의 클러스터에 한 개만 존재할 수 있는 문제
• Ingress 가 표현하지 못하는 기능을 벤더별 어노테이션으로 채워 이식성이 깨지는 문제
• Ingress 가 YAML 이 아닌 형식으로만 정의되는 문제

컨테이너 이미지를 만들 때 멀티 스테이지 빌드를 쓰는 주된 이유는?

• 여러 아키텍처용 이미지를 한 번에 만들려고
• 빌드 시간을 줄이려고 캐시를 강제로 무효화하려고
• 이미지 레이어를 하나로 합쳐 레지스트리 호환성을 높이려고
• 빌드 도구와 소스를 최종 이미지에서 덜어 내 크기와 공격 표면을 줄이려고

CI 와 CD 의 역할 구분으로 가장 정확한 것은?

• CI 는 개발자가 손으로 하는 통합이고 CD 는 그것을 자동화한 것이다
• CI 는 운영 환경 배포를, CD 는 테스트 환경 배포를 담당한다
• CI 는 변경을 자주 통합하고 자동으로 빌드·검증하는 일이고, CD 는 검증된 산출물을 환경으로 내보내는 일이다
• CI 와 CD 는 같은 말이며 도구에 따라 이름만 다르다

이미지 태그로 latest 를 쓰는 것이 배포에서 문제가 되는 이유는?

• 쿠버네티스가 latest 태그를 가진 이미지를 아예 내려받지 못한다
• latest 태그는 레지스트리에서 자동으로 삭제된다
• latest 태그를 쓰면 이미지 크기가 커진다
• 같은 태그가 시점에 따라 다른 이미지를 가리켜 어떤 버전이 도는지 알 수 없게 된다

오퍼레이터 패턴을 가장 정확히 설명한 것은?

• 쿠버네티스 대신 사람이 직접 워크로드를 관리하는 전통적 운영 방식을 가리킨다
• 여러 클러스터를 하나의 콘솔에서 관리하는 상용 제품의 이름이다
• 운영자가 반복하던 절차를 커스텀 리소스와 컨트롤러로 코드화해 클러스터가 대신 수행하게 한다
• 파드 안에서 실행되는 셸 스크립트를 정해진 시각에 돌리는 방식이다

자동 확장(autoscaling)을 설계할 때 클라우드 네이티브 관점에서 가장 중요한 전제는?

• 모든 복제본이 같은 노드에 모여 있어야 지연이 줄어든다
• 확장 기준은 반드시 CPU 사용률 하나여야 한다
• 확장 시점에 애플리케이션을 다시 빌드해야 한다
• 워크로드가 상태를 인스턴스 안에 두지 않아 아무 복제본이나 요청을 처리할 수 있어야 한다

서버리스 모델의 특징으로 가장 정확한 것은?

• 서버가 존재하지 않으므로 인프라 비용이 발생하지 않는다
• 함수 하나가 항상 상주해 첫 요청도 지연 없이 처리된다
• 서버 관리와 용량 계획을 플랫폼에 맡기고 사용량 기준으로 자원이 배정된다
• 컨테이너 이미지를 쓸 수 없고 코드 조각만 올릴 수 있다

마이크로서비스로 나눌 때 치러야 하는 대가로 가장 적절한 것은?

• 서비스마다 언어를 통일해야 하므로 기술 선택의 폭이 줄어든다
• 한 서비스만 배포하는 것이 불가능해져 전체를 함께 배포해야 한다
• 데이터베이스를 하나로 합쳐야 하므로 결합이 오히려 강해진다
• 함수 호출이던 것이 네트워크 호출이 되어 실패와 지연을 항상 다뤄야 한다

CNCF 랜드스케이프에서 프로젝트 성숙도 단계의 순서로 올바른 것은?

• Incubating → Sandbox → Graduated
• Graduated → Incubating → Sandbox
• Sandbox → Incubating → Graduated
• Sandbox → Graduated → Incubating

오픈 스탠다드가 클라우드 네이티브 생태계에서 중요한 이유로 가장 적절한 것은?

• 표준을 따르면 성능이 항상 더 빨라지기 때문
• 표준이 있으면 보안 취약점이 생기지 않기 때문
• 표준 준수 제품은 무료로 제공되어야 하기 때문
• 구현을 바꿔도 인터페이스가 같아 특정 벤더에 묶이지 않게 해 주기 때문

역할 기반 접근 제어(RBAC)가 클라우드 네이티브 아키텍처에서 갖는 의미로 가장 적절한 것은?

• 네트워크 트래픽을 암호화해 도청을 막는다
• 컨테이너 이미지의 서명을 검증해 출처를 보장한다
• 최소 권한 원칙을 API 수준에서 강제해 침해의 파급 범위를 좁힌다
• 노드 사이의 부하를 고르게 나눈다

다중 테넌시를 네임스페이스만으로 구현할 때의 한계로 올바른 것은?

• 네임스페이스를 여러 개 만들면 클러스터 성능이 절반으로 떨어진다
• 네임스페이스가 다르면 파드끼리 네트워크로 통신할 수 없다
• 네임스페이스마다 별도의 etcd 인스턴스가 필요하다
• 네임스페이스는 API 오브젝트의 경계일 뿐 커널과 노드는 여전히 공유된다