퀴즈: 왜 CRD 인가

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

1. CRD 를 적용했을 때 API 서버가 '공짜로' 제공하는 것이 아닌 것은?

   1. CR 이 선언한 대로 파드를 띄우는 동작
   2. 스키마 기반 검증과 기본값 주입
   3. etcd 저장과 watch 스트림
   4. 리소스 단위 RBAC 와 감사 로그

2. Helm values 대신 CR 을 쓸 때 얻는 가장 구조적인 이득은?

   1. 잘못된 값이 배포 시점이 아니라 apply 시점에 거부된다
   2. 템플릿 문법이 사라져 작성해야 할 YAML 이 크게 줄어든다
   3. 차트에 들어가던 설정이 빠져 컨테이너 이미지 크기가 줄어든다
   4. 차트 재렌더링이 없어져 클러스터 업그레이드가 쉬워진다

3. 다음 중 CRD 를 만들지 않는 편이 나은 상황은?

   1. 새벽 장애에 사람이 개입하던 복구 절차를 코드로 옮기려 한다
   2. Deployment 와 HPA 만으로 충분한 스테이트리스 웹앱을 배포한다
   3. 데이터베이스의 페일오버와 백업 검증까지 자동화해야 한다
   4. 여러 팀에 표준화된 배포 인터페이스를 API 로 제공해야 한다

4. 필드 간 제약(예: prod 계층이면 복제본 2 이상)을 표현하는 2026년 기준 권장 방법은?

   1. 컨트롤러의 reconcile 안에서 검사하고 status 에 오류로 기록
   2. CI 파이프라인에서 매니페스트를 정적 검사해 머지 단계에서 차단
   3. 스키마의 x-kubernetes-validations 에 CEL 규칙으로 선언
   4. 검증 웹훅 서버를 띄워 admission 단계에서 필드 조합을 검사

5. "CRD 는 코드가 아니라 API 계약" 이라는 말의 실무적 함의는?

   1. CRD 는 클러스터마다 다르게 정의해 환경 차이를 흡수해야 한다
   2. CRD 는 컨트롤러가 준비된 뒤에 배포해야 오류가 나지 않는다
   3. 한 번 공개한 필드는 저장된 오브젝트와 사용자 매니페스트 때문에 되돌리기 어렵다
   4. CRD 는 선언형 YAML 이라 Go 타입 정의에서 생성할 수 없다

6. 오퍼레이터 도입을 검토할 때 가장 먼저 확인해야 할 것은?

   1. 팀이 Go 와 컨트롤러 런타임을 다룰 수 있는지
   2. 이미 잘 관리되는 공식·커뮤니티 오퍼레이터가 있는지
   3. 컨트롤러를 상시 돌릴 클러스터 노드 여유가 충분한지
   4. CRD 의 그룹과 복수형 이름을 무엇으로 할지

7. CR 을 라벨 셀렉터로 골라낼 수 있는 이유는?

   1. CRD 를 만들 때 스키마에 라벨 셀렉터 필드를 정의해 두었기 때문
   2. 컨트롤러가 CR 을 캐시하며 라벨 인덱스를 따로 만들기 때문
   3. kubectl 이 전체 목록을 받아 클라이언트에서 필터링하기 때문
   4. CR 도 다른 오브젝트와 같은 metadata 를 가진 정식 API 오브젝트이기 때문