KCNA — 쿠버네티스·클라우드 네이티브 입문 · 모의고사 · 퀴즈

KCNA 모의고사 A

LabHub 에서 이어서 보기

문항 60개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

쿠버네티스의 선언형 모델에서 컨트롤러가 하는 일을 가장 정확히 설명한 것은?
1. 사용자가 보낸 명령을 순서대로 큐에 넣고 하나씩 실행한다
2. 원하는 상태와 현재 상태를 계속 비교해 차이를 줄이는 쪽으로 행동한다
3. 매니페스트를 검증한 뒤 통과한 것만 etcd 에 저장하고 끝낸다
4. 노드의 자원 여유를 계산해 파드를 어느 노드에 둘지 결정한다
쿠버네티스 오브젝트의 spec 과 status 필드의 관계로 올바른 것은?
1. spec 은 컨트롤 플레인이 채우고 status 는 사용자가 채운다
2. spec 은 사용자가 원하는 상태를 적고 status 는 시스템이 관찰한 현재 상태를 적는다
3. spec 과 status 는 같은 값을 중복 저장해 손상에 대비하는 구조다
4. status 는 오브젝트가 삭제될 때만 채워지는 종료 기록용 필드다
네임스페이스에 속하지 않는(cluster-scoped) 리소스로만 짝지어진 것은?
1. Node 와 PersistentVolume
2. ConfigMap 과 Secret
3. Deployment 와 StatefulSet
4. Role 과 RoleBinding
kubelet 이 담당하는 일로 올바른 것은?
1. 클러스터 전체의 파드를 어느 노드에 배치할지 계산한다
2. 자기 노드에 할당된 파드를 컨테이너 런타임으로 띄우고 상태를 apiserver 에 보고한다
3. Service 의 가상 IP 를 실제 파드 IP 로 바꾸는 규칙을 노드에 설치한다
4. etcd 에 저장된 오브젝트를 주기적으로 백업한다
kube-proxy 를 가장 정확히 설명한 것은?
1. 모든 파드 트래픽이 반드시 통과하는 사용자 공간 프록시 프로세스다
2. Service 오브젝트를 감시해 노드의 패킷 전달 규칙(iptables 또는 IPVS)을 갱신한다
3. 외부에서 들어오는 HTTP 요청의 경로를 보고 백엔드를 고르는 L7 라우터다
4. 파드에 IP 를 할당하고 노드 사이의 오버레이 터널을 만든다
etcd 에 대한 설명으로 올바른 것은?
1. 메트릭 시계열을 저장하는 시계열 데이터베이스다
2. 각 노드가 자기 몫만 따로 저장하는 분산 캐시다
3. Raft 합의로 일관성을 지키는 키-값 저장소이며 클러스터 상태의 유일한 원본이다
4. 컨테이너 이미지 레이어를 보관하는 내부 레지스트리다
파드에 여러 컨테이너를 함께 넣는 것이 적절한 경우는?
1. 프런트엔드와 데이터베이스처럼 서로 다른 주기로 확장해야 하는 두 서비스를 묶을 때
2. 로그 수집 사이드카처럼 같은 볼륨과 네트워크를 공유하며 한 몸으로 살고 죽어야 할 때
3. 장애 시 서로를 대신할 수 있도록 같은 애플리케이션을 두 벌 올릴 때
4. 노드 자원을 아끼려고 서로 관련 없는 작업을 한데 모을 때
initContainer 의 동작으로 올바른 것은?
1. 앱 컨테이너와 동시에 시작해 준비 작업을 병렬로 처리한다
2. 정의된 순서대로 하나씩 완료된 뒤에야 앱 컨테이너가 시작된다
3. 앱 컨테이너가 죽을 때마다 함께 다시 실행되어 상태를 복구한다
4. 앱 컨테이너보다 항상 더 많은 자원을 예약해 두는 전용 컨테이너다
파드의 `restartPolicy` 를 `Never` 로 두면 kubelet 은 어떻게 동작하는가?
1. 컨테이너가 실패해도 다시 시작하지 않고 파드를 Failed 상태로 남긴다
2. 컨테이너가 실패하면 파드를 삭제하고 새 파드를 만든다
3. 컨테이너가 실패하면 지수 백오프를 두고 다시 시작한다
4. 컨테이너가 실패하면 다른 노드로 파드를 옮겨 다시 시도한다
컨테이너의 `resources.requests` 가 실제로 쓰이는 곳은?
1. 컨테이너가 그 값을 넘겨 쓰면 커널이 즉시 프로세스를 종료한다
2. 스케줄러가 노드를 고를 때 남은 할당 가능 자원과 비교하는 기준이 된다
3. 오토스케일러가 파드 개수를 정할 때만 참고하고 배치에는 쓰이지 않는다
4. 컨테이너 시작 시 그만큼의 메모리를 미리 확보해 페이지를 채운다
CPU limits 와 메모리 limits 의 강제 방식이 다른 점으로 올바른 것은?
1. CPU 는 초과 시 스로틀링되고 메모리는 초과 시 프로세스가 종료된다
2. CPU 는 초과 시 프로세스가 종료되고 메모리는 스로틀링된다
3. 둘 다 초과하면 파드가 다른 노드로 축출된다
4. 둘 다 경고 이벤트만 남기고 실제로 막지는 않는다
ConfigMap 을 환경변수로 주입한 뒤 ConfigMap 의 값을 바꾸면 실행 중인 파드는 어떻게 되는가?
1. kubelet 이 환경변수를 갱신해 다음 요청부터 새 값이 적용된다
2. 파드가 자동으로 재시작되어 새 값을 읽는다
3. 환경변수는 프로세스 시작 시 고정되므로 파드를 다시 만들기 전까지 옛 값이 유지된다
4. apiserver 가 변경을 거부하고 ConfigMap 수정 자체가 실패한다
`kubectl describe pod` 의 Events 를 먼저 보라고 하는 이유로 가장 적절한 것은?
1. Events 에는 컨테이너가 stdout 으로 낸 애플리케이션 로그가 담기기 때문
2. Events 에 스케줄링 실패, 이미지 풀 실패, 프로브 실패처럼 파드가 뜨지 못한 이유가 기록되기 때문
3. Events 가 etcd 에 영구 보관되어 과거 이력을 모두 볼 수 있기 때문
4. Events 를 봐야만 파드에 배정된 IP 와 노드를 알 수 있기 때문
쿠버네티스 API 그룹과 버전 표기에 대한 설명으로 올바른 것은?
1. `v1` 은 코어 그룹을 뜻하고 `apps/v1` 처럼 그룹 이름이 붙는 경우도 있다
2. 모든 리소스는 반드시 그룹 이름을 붙여 `core/v1` 형태로 써야 한다
3. 알파 버전과 정식 버전은 같은 클러스터에 동시에 존재할 수 없다
4. API 버전은 클러스터 버전과 항상 같은 숫자를 쓴다
CRD(CustomResourceDefinition)가 하는 일로 올바른 것은?
1. 새 리소스 종류를 API 에 등록해 kubectl 과 RBAC 이 기본 리소스처럼 다루게 한다
2. 등록한 리소스의 동작 로직까지 함께 제공해 별도 컨트롤러가 필요 없게 한다
3. 기존 리소스의 스키마를 덮어써 필드를 추가하거나 제거한다
4. 클러스터 밖의 외부 API 를 프록시해 kubectl 로 호출하게 한다
`kubectl` 이 클러스터에 접속할 때 쓰는 정보가 담긴 곳은?
1. 노드의 `/var/lib/kubelet/config.yaml`
2. kubeconfig 파일의 clusters·users·contexts 세 부분
3. apiserver 가 발급해 주는 세션 쿠키
4. 환경변수 `KUBERNETES_SERVICE_HOST` 하나
RBAC 에서 Role 과 ClusterRole 의 차이로 올바른 것은?
1. Role 은 읽기 권한만, ClusterRole 은 쓰기 권한까지 담을 수 있다
2. Role 은 한 네임스페이스 안에서만 유효하고 ClusterRole 은 클러스터 범위 리소스에도 쓸 수 있다
3. Role 은 사용자에게, ClusterRole 은 ServiceAccount 에만 연결할 수 있다
4. Role 은 즉시 적용되고 ClusterRole 은 apiserver 재시작 뒤에 적용된다
ServiceAccount 를 가장 정확히 설명한 것은?
1. 클러스터 관리자가 사람에게 발급하는 로그인 계정이다
2. 파드 안의 프로세스가 API 서버에 자신을 증명할 때 쓰는 클러스터 내부 신원이다
3. 노드가 컨트롤 플레인에 등록할 때 쓰는 부트스트랩 인증서다
4. 이미지 레지스트리 접속용 자격증명만 담는 전용 오브젝트다
쿠버네티스에서 Service 가 필요한 근본적인 이유는?
1. 파드 IP 는 파드가 다시 만들어질 때마다 바뀌므로 고정된 접점이 필요하기 때문
2. 파드끼리는 IP 로 서로 통신할 수 없도록 막혀 있기 때문
3. 파드가 여러 노드에 흩어지면 노드를 넘는 통신이 불가능하기 때문
4. 파드는 포트를 열 수 없고 Service 만 포트를 열 수 있기 때문
ClusterIP·NodePort·LoadBalancer 타입의 관계로 올바른 것은?
1. 세 타입은 서로 배타적이라 하나를 쓰면 나머지 기능은 없다
2. NodePort 는 ClusterIP 위에 노드 포트를 더하고, LoadBalancer 는 그 위에 외부 로드밸런서를 더한다
3. LoadBalancer 는 ClusterIP 를 만들지 않고 외부 IP 만 노출한다
4. NodePort 는 클러스터 내부에서는 접근할 수 없고 외부에서만 쓸 수 있다
클러스터 안에서 DNS 이름 해석을 담당하는 컴포넌트는?
1. kube-proxy
2. CoreDNS
3. etcd
4. kubelet
쿠버네티스 네트워크 모델이 요구하는 조건으로 올바른 것은?
1. 모든 파드는 NAT 없이 서로의 IP 로 통신할 수 있어야 한다
2. 같은 노드의 파드끼리만 직접 통신하고 노드를 넘을 때는 NAT 를 거쳐야 한다
3. 파드는 반드시 노드와 같은 IP 를 공유해야 한다
4. 파드 사이의 통신은 항상 Service 를 거쳐야 한다
PersistentVolume 의 `Retain` 회수 정책이 뜻하는 바는?
1. PVC 가 삭제되면 PV 의 데이터를 지우고 다시 바인딩 가능한 상태로 만든다
2. PVC 가 삭제되면 PV 와 실제 스토리지가 함께 삭제된다
3. PVC 가 삭제되어도 PV 와 데이터가 남고 관리자가 손으로 처리할 때까지 Released 상태에 머문다
4. PVC 가 삭제되면 같은 이름의 PVC 가 다시 만들어질 때까지 대기하다 자동 재바인딩된다
StorageClass 를 쓰는 목적으로 가장 적절한 것은?
1. PVC 요청이 들어올 때 프로비저너가 볼륨을 자동으로 만들어 주도록 한다
2. 이미 만들어진 PV 들을 성능 등급별로 보기 좋게 분류만 해 둔다
3. PVC 가 요청할 수 있는 최대 용량을 네임스페이스 단위로 제한한다
4. 볼륨의 데이터를 주기적으로 스냅샷으로 백업한다
`kubectl apply` 가 같은 매니페스트를 두 번 적용해도 결과가 같은 이유는?
1. apply 가 실행 전에 기존 오브젝트를 항상 삭제하고 새로 만들기 때문
2. 선언한 최종 상태를 보내고 서버가 현재 상태와의 차이만 반영하기 때문
3. apiserver 가 같은 요청을 감지하면 무시하도록 캐시를 두기 때문
4. kubectl 이 로컬에 이전 실행 기록을 남겨 두 번째 실행을 건너뛰기 때문
쿠버네티스 라벨과 어노테이션의 차이로 올바른 것은?
1. 라벨은 셀렉터로 선택할 수 있고 어노테이션은 선택 대상이 아닌 부가 정보를 담는다
2. 라벨은 사람만 읽고 어노테이션은 컨트롤러만 읽는다
3. 라벨은 값 길이에 제한이 없고 어노테이션은 63자로 제한된다
4. 라벨은 생성 후 바꿀 수 없고 어노테이션은 언제든 바꿀 수 있다
오케스트레이터가 없던 시절과 비교해 쿠버네티스가 새로 맡아 준 일로 보기 어려운 것은?
1. 노드가 죽었을 때 그 위의 워크로드를 다른 노드에 다시 띄우는 일
2. 애플리케이션 코드의 버그를 찾아 자동으로 고쳐 주는 일
3. 선언한 복제본 수를 계속 유지하는 일
4. 새 버전을 점진적으로 교체하며 배포하는 일
Deployment 의 `maxSurge` 와 `maxUnavailable` 을 둘 다 0 으로 두면?
1. 가장 안전한 설정이라 무중단 배포가 보장된다
2. 쿠버네티스가 자동으로 기본값을 되살려 정상 동작한다
3. 옛 파드를 전부 지운 뒤 새 파드를 한 번에 만든다
4. 새 파드도 못 만들고 옛 파드도 못 줄여 롤아웃이 진행되지 못한다
`kubectl rollout undo` 가 이전 버전으로 되돌릴 수 있는 근거는?
1. Deployment 가 이전 ReplicaSet 을 revisionHistoryLimit 만큼 남겨 두기 때문
2. kubectl 이 로컬 디스크에 이전 매니페스트를 보관하기 때문
3. etcd 가 모든 오브젝트의 변경 이력을 무기한 저장하기 때문
4. 컨테이너 레지스트리가 이전 이미지를 자동으로 되돌려 주기 때문
StatefulSet 이 Deployment 와 다른 점으로 올바른 것은?
1. 파드가 항상 같은 노드에 고정되어 절대 다른 노드로 옮겨지지 않는다
2. 복제본을 하나로만 둘 수 있어 수평 확장이 불가능하다
3. 볼륨을 쓸 수 없고 메모리에만 상태를 둘 수 있다
4. 파드 이름이 0부터의 순번으로 고정되고 각자 자기 PVC 를 계속 물고 간다
Job 의 `completions` 를 6, `parallelism` 을 2 로 두면 어떻게 실행되는가?
1. 파드 6개를 동시에 띄우고 그중 2개만 성공하면 끝난다
2. 2개의 파드가 각각 6번씩 재시작을 반복한다
3. 6개의 파드를 순서대로 하나씩만 실행한다
4. 한 번에 최대 2개씩 돌려 성공한 파드가 누적 6개가 될 때까지 이어 간다
CronJob 의 `concurrencyPolicy: Forbid` 가 뜻하는 것은?
1. 이전 실행이 아직 끝나지 않았으면 이번 실행을 건너뛴다
2. 이전 실행을 강제 종료하고 새 실행을 시작한다
3. 동시에 최대 두 개까지만 실행을 허용한다
4. 스케줄이 겹치면 뒤의 실행을 큐에 넣었다가 순서대로 돌린다
노드에 taint 를 걸었을 때 일어나는 일로 올바른 것은?
1. 그 노드의 모든 파드가 즉시 다른 노드로 옮겨진다
2. 그 노드가 클러스터에서 제거되고 kubelet 이 멈춘다
3. 그 노드에는 DaemonSet 파드만 들어갈 수 있게 된다
4. 대응하는 toleration 이 없는 파드는 그 노드에 새로 스케줄되지 않는다
nodeSelector 와 affinity 의 차이로 올바른 것은?
1. nodeSelector 는 라벨이 정확히 맞아야 하는 단순 조건이고 affinity 는 선호 조건과 표현식을 쓸 수 있다
2. nodeSelector 는 파드 사이의 관계를, affinity 는 노드와의 관계를 다룬다
3. nodeSelector 는 스케줄러가 무시할 수 있고 affinity 는 반드시 지켜진다
4. nodeSelector 는 이미 실행 중인 파드도 옮기고 affinity 는 새 파드에만 적용된다
HorizontalPodAutoscaler 가 하는 일로 올바른 것은?
1. 파드의 CPU·메모리 요청량을 관측값에 맞춰 조정한다
2. 노드가 부족하면 클라우드에 노드를 추가로 요청한다
3. 지표를 보고 워크로드의 복제본 수를 늘리거나 줄인다
4. 파드를 자원이 남는 노드로 다시 배치한다
파드가 Pending 상태에서 움직이지 않을 때 원인으로 보기 어려운 것은?
1. 요청한 자원을 감당할 노드가 없다
2. PVC 가 아직 바인딩되지 않았다
3. 컨테이너의 애플리케이션이 시작하자마자 에러를 내고 종료한다
4. 노드의 taint 를 견딜 toleration 이 없다
`ImagePullBackOff` 상태의 원인으로 보기 어려운 것은?
1. 이미지 이름이나 태그를 잘못 적었다
2. 비공개 레지스트리인데 imagePullSecrets 를 붙이지 않았다
3. 노드에서 레지스트리로 나가는 네트워크가 막혀 있다
4. 컨테이너가 메모리 상한을 넘겨 OOM 으로 종료됐다
kubelet 이 노드의 메모리 압박으로 파드를 축출할 때 우선순위가 가장 높은(먼저 쫓겨나는) 것은?
1. requests 와 limits 를 같게 지정한 Guaranteed 파드
2. requests 만 지정하고 limits 는 더 크게 지정한 Burstable 파드
3. requests 도 limits 도 지정하지 않은 BestEffort 파드
4. 축출 순서는 무작위로 정해진다
`kubectl drain` 이 하는 일로 올바른 것은?
1. 노드를 스케줄 불가로 표시하고 그 위의 파드를 안전하게 내보낸다
2. 노드를 클러스터에서 즉시 삭제하고 etcd 기록도 지운다
3. 노드의 디스크를 비워 이미지 캐시를 정리한다
4. 노드의 모든 파드를 그대로 둔 채 새 파드만 막는다
PodDisruptionBudget 이 보호하는 상황으로 올바른 것은?
1. 노드가 갑자기 전원이 끊겨 파드가 사라지는 경우
2. 컨테이너가 OOM 으로 죽는 경우
3. 이미지를 내려받지 못해 파드가 못 뜨는 경우
4. 관리자가 노드를 비우는 것처럼 계획된 중단으로 파드가 한꺼번에 사라지는 경우
DaemonSet 이 적합한 워크로드로 가장 알맞은 것은?
1. 요청량에 따라 복제본을 늘렸다 줄였다 해야 하는 웹 API
2. 하루에 한 번 정해진 시각에만 실행되는 정산 배치
3. 노드마다 하나씩 떠서 그 노드의 로그와 지표를 수집하는 에이전트
4. 순번과 전용 볼륨이 필요한 데이터베이스 클러스터
Deployment 의 셀렉터와 파드 템플릿 라벨이 어긋나면 어떻게 되는가?
1. apiserver 가 유효성 검사에서 거부해 생성이 실패한다
2. 생성은 되지만 셀렉터가 자기 파드를 못 찾아 복제본이 무한정 늘어난다
3. 쿠버네티스가 템플릿 라벨을 셀렉터에 맞춰 자동으로 고쳐 준다
4. 경고만 남기고 셀렉터를 무시한 채 정상 동작한다
쿠버네티스가 애플리케이션을 '셀프힐링' 한다고 말할 때의 정확한 의미는?
1. 컨테이너 이미지의 취약점을 찾아 자동으로 패치한다
2. 요청이 실패하면 애플리케이션 대신 응답을 만들어 돌려준다
3. 데이터베이스가 손상되면 백업에서 자동으로 복원한다
4. 실패한 컨테이너를 다시 띄우고 사라진 복제본을 다시 만들어 선언한 상태로 되돌린다
Helm 차트가 매니페스트 묶음보다 나은 점으로 가장 정확한 것은?
1. 설치한 릴리스의 버전을 추적해 이전 상태로 되돌릴 수 있다
2. 매니페스트를 자동으로 검증해 문법 오류가 있으면 고쳐 준다
3. 컨테이너 이미지를 함께 담고 있어 레지스트리가 필요 없다
4. 클러스터에 적용할 때 RBAC 권한을 자동으로 넉넉히 만들어 준다
Kustomize 가 Helm 과 다른 접근을 취하는 지점으로 올바른 것은?
1. 차트 저장소에서 패키지를 내려받아 설치하는 것을 기본으로 한다
2. 클러스터에 서버 컴포넌트를 설치해야만 동작한다
3. 템플릿 언어 없이 원본 YAML 에 패치를 겹쳐 환경별 변형을 만든다
4. YAML 대신 전용 DSL 로 리소스를 기술한다
GitOps 에서 '조정(reconciliation)'이 뜻하는 것은?
1. 개발자가 파이프라인에서 kubectl apply 를 실행하는 단계
2. 여러 개발자의 브랜치를 병합해 충돌을 푸는 일
3. 배포 후 통합 테스트를 돌려 결과를 보고하는 일
4. 에이전트가 Git 의 선언과 클러스터의 실제 상태를 계속 비교해 차이를 되돌리는 일
블루-그린 배포와 카나리 배포의 차이로 올바른 것은?
1. 블루-그린은 새 버전을 위한 환경을 따로 두지 않고, 카나리는 환경을 두 벌 운영한다
2. 블루-그린은 되돌리기가 불가능하고 카나리만 롤백할 수 있다
3. 블루-그린은 트래픽을 한 번에 전환하고, 카나리는 일부 트래픽만 새 버전에 보내며 비율을 늘린다
4. 블루-그린은 상태가 있는 서비스에만, 카나리는 상태가 없는 서비스에만 쓸 수 있다
Ingress 리소스만 만들고 아무 일도 일어나지 않았다면 가장 먼저 의심할 것은?
1. Service 의 타입이 ClusterIP 라서 Ingress 가 붙을 수 없다
2. Ingress 는 네임스페이스를 넘어서만 동작하므로 같은 네임스페이스에 두면 안 된다
3. Ingress 는 HTTPS 만 지원하므로 인증서 없이는 동작하지 않는다
4. 클러스터에 Ingress 컨트롤러가 설치되어 있지 않다
Gateway API 가 Ingress 를 보완하려는 문제로 가장 적절한 것은?
1. Ingress 가 TLS 종료를 전혀 지원하지 않는 문제
2. Ingress 가 하나의 클러스터에 한 개만 존재할 수 있는 문제
3. Ingress 가 표현하지 못하는 기능을 벤더별 어노테이션으로 채워 이식성이 깨지는 문제
4. Ingress 가 YAML 이 아닌 형식으로만 정의되는 문제
컨테이너 이미지를 만들 때 멀티 스테이지 빌드를 쓰는 주된 이유는?
1. 여러 아키텍처용 이미지를 한 번에 만들려고
2. 빌드 시간을 줄이려고 캐시를 강제로 무효화하려고
3. 이미지 레이어를 하나로 합쳐 레지스트리 호환성을 높이려고
4. 빌드 도구와 소스를 최종 이미지에서 덜어 내 크기와 공격 표면을 줄이려고
CI 와 CD 의 역할 구분으로 가장 정확한 것은?
1. CI 는 개발자가 손으로 하는 통합이고 CD 는 그것을 자동화한 것이다
2. CI 는 운영 환경 배포를, CD 는 테스트 환경 배포를 담당한다
3. CI 는 변경을 자주 통합하고 자동으로 빌드·검증하는 일이고, CD 는 검증된 산출물을 환경으로 내보내는 일이다
4. CI 와 CD 는 같은 말이며 도구에 따라 이름만 다르다
이미지 태그로 `latest` 를 쓰는 것이 배포에서 문제가 되는 이유는?
1. 쿠버네티스가 latest 태그를 가진 이미지를 아예 내려받지 못한다
2. latest 태그는 레지스트리에서 자동으로 삭제된다
3. latest 태그를 쓰면 이미지 크기가 커진다
4. 같은 태그가 시점에 따라 다른 이미지를 가리켜 어떤 버전이 도는지 알 수 없게 된다
오퍼레이터 패턴을 가장 정확히 설명한 것은?
1. 쿠버네티스 대신 사람이 직접 워크로드를 관리하는 전통적 운영 방식을 가리킨다
2. 여러 클러스터를 하나의 콘솔에서 관리하는 상용 제품의 이름이다
3. 운영자가 반복하던 절차를 커스텀 리소스와 컨트롤러로 코드화해 클러스터가 대신 수행하게 한다
4. 파드 안에서 실행되는 셸 스크립트를 정해진 시각에 돌리는 방식이다
자동 확장(autoscaling)을 설계할 때 클라우드 네이티브 관점에서 가장 중요한 전제는?
1. 모든 복제본이 같은 노드에 모여 있어야 지연이 줄어든다
2. 확장 기준은 반드시 CPU 사용률 하나여야 한다
3. 확장 시점에 애플리케이션을 다시 빌드해야 한다
4. 워크로드가 상태를 인스턴스 안에 두지 않아 아무 복제본이나 요청을 처리할 수 있어야 한다
서버리스 모델의 특징으로 가장 정확한 것은?
1. 서버가 존재하지 않으므로 인프라 비용이 발생하지 않는다
2. 함수 하나가 항상 상주해 첫 요청도 지연 없이 처리된다
3. 서버 관리와 용량 계획을 플랫폼에 맡기고 사용량 기준으로 자원이 배정된다
4. 컨테이너 이미지를 쓸 수 없고 코드 조각만 올릴 수 있다
마이크로서비스로 나눌 때 치러야 하는 대가로 가장 적절한 것은?
1. 서비스마다 언어를 통일해야 하므로 기술 선택의 폭이 줄어든다
2. 한 서비스만 배포하는 것이 불가능해져 전체를 함께 배포해야 한다
3. 데이터베이스를 하나로 합쳐야 하므로 결합이 오히려 강해진다
4. 함수 호출이던 것이 네트워크 호출이 되어 실패와 지연을 항상 다뤄야 한다
CNCF 랜드스케이프에서 프로젝트 성숙도 단계의 순서로 올바른 것은?
1. Incubating → Sandbox → Graduated
2. Graduated → Incubating → Sandbox
3. Sandbox → Incubating → Graduated
4. Sandbox → Graduated → Incubating
오픈 스탠다드가 클라우드 네이티브 생태계에서 중요한 이유로 가장 적절한 것은?
1. 표준을 따르면 성능이 항상 더 빨라지기 때문
2. 표준이 있으면 보안 취약점이 생기지 않기 때문
3. 표준 준수 제품은 무료로 제공되어야 하기 때문
4. 구현을 바꿔도 인터페이스가 같아 특정 벤더에 묶이지 않게 해 주기 때문
역할 기반 접근 제어(RBAC)가 클라우드 네이티브 아키텍처에서 갖는 의미로 가장 적절한 것은?
1. 네트워크 트래픽을 암호화해 도청을 막는다
2. 컨테이너 이미지의 서명을 검증해 출처를 보장한다
3. 최소 권한 원칙을 API 수준에서 강제해 침해의 파급 범위를 좁힌다
4. 노드 사이의 부하를 고르게 나눈다
다중 테넌시를 네임스페이스만으로 구현할 때의 한계로 올바른 것은?
1. 네임스페이스를 여러 개 만들면 클러스터 성능이 절반으로 떨어진다
2. 네임스페이스가 다르면 파드끼리 네트워크로 통신할 수 없다
3. 네임스페이스마다 별도의 etcd 인스턴스가 필요하다
4. 네임스페이스는 API 오브젝트의 경계일 뿐 커널과 노드는 여전히 공유된다