퀴즈: 설정까지 재현되는 복구

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

1. ConfigMap의 HEALTHY 값을 바꿨지만 envFrom을 쓰는 기존 파드의 응답은 그대로입니다. 먼저 고려할 설명은?

   1. 실행 중인 컨테이너의 환경변수는 이 수정으로 자동 갱신되지 않는다
   2. ConfigMap의 data는 항상 불변이므로 수정 요청이 무조건 무시된다
   3. Deployment가 모든 외부 설정 변경을 자동으로 이전 값으로 되돌린다
   4. Service가 정상 파드에는 새 환경변수를 전달하지 못하도록 막는다

2. 이전 Deployment 리비전도 같은 settings ConfigMap 이름을 참조합니다. settings의 오류 내용을 남긴 채 rollout undo를 하면?

   1. Pod 템플릿과 외부 ConfigMap의 data가 같은 시점으로 함께 복구된다
   2. 이전 Pod 템플릿으로 돌아가지만 외부 설정 내용의 복구는 보장되지 않는다
   3. ConfigMap 이름이 같으면 이전 리비전이 없어도 설정 내용을 복구한다
   4. 이전 리비전에서 사용한 모든 외부 객체를 삭제한 뒤 다시 생성한다

3. 새 파드 한 개의 준비 응답은 503인데 서비스는 200입니다. 새 버전의 배포 성공을 판단하려면 무엇을 더 봐야 하나요?

   1. 서비스 주소가 변경 전과 같은지를 보고 같으면 배포 완료로 판단한다
   2. HTTP를 한 번 더 호출해 200이면 새 복제본 상태를 생략한다
   3. 응답한 파드의 소유 관계와 현재 템플릿의 갱신·준비 복제본을 대조한다
   4. API 적용 명령이 성공했는지를 보고 새 파드의 준비 실패를 무시한다

4. 복제본 2개에 maxSurge=1, maxUnavailable=0인 예제를 해석한 것 중 가장 정확한 것은?

   1. 현재 실행되는 모든 파드가 어떤 상황에서도 정확히 2개여야 한다
   2. 새 파드가 준비되지 않아도 기존 파드는 즉시 하나씩 제거돼야 한다
   3. 이 설정만 있으면 노드 고장이나 설정 오류에도 무중단이 보장된다
   4. 새 파드가 준비될 때까지 기존 가용 용량을 유지하도록 배포를 제한한다

5. settings-v1에 immutable=true를 적용한 뒤 data 수정이 거절됐습니다. 이 결과가 직접 증명하는 것은?

   1. 그 객체의 설정 데이터 변경이 거절된다는 점이다
   2. 그 객체를 삭제하고 재생성하는 권한도 없다는 점이다
   3. 같은 이름이 영원히 같은 UID를 갖는다는 점이다
   4. 그 안의 값이 암호화되어 비밀 저장에 안전하다는 점이다

6. 버전별 불변 설정을 쓰는 배포에서 이전 버전으로 되돌릴 수 있으려면 무엇을 보존해야 하나요?

   1. 이전 설정 이름만 기억하면 내용은 정리해도 된다
   2. 이전 템플릿과 그것이 참조하는 설정 내용을 함께 보존한다
   3. 현재 서비스의 ClusterIP만 기록하고 모든 옛 설정은 지운다
   4. 새 설정에 예전 이름을 붙여 참조 이름이 같도록 만든다

7. 롤백 후 정상 파드 한 개를 교체하는 개인 VM 시험에서 복구 지속성의 강한 증거는?

   1. 삭제 전 저장해 둔 정상 응답이 파일에 남아 있는 것
   2. 교체한 파드와 이전 파드의 이름 접두어가 같은 것
   3. 새 UID의 파드가 이전 설정을 읽고 준비·HTTP 대조를 통과한 것
   4. 다른 팀 파드가 정상이므로 자기 팀 파드 조회를 생략하는 것

8. 롤아웃 관측 명령이 10초 제한에 걸렸지만 컨트롤러의 최종 판정은 아직 조회하지 못했습니다. 올바른 다음 행동은?

   1. 설치가 실패한 것이 확정됐으므로 같은 설치 명령부터 다시 실행한다
   2. 지켜보는 창만 닫혔으므로 추가 확인 없이 복구 완료로 기록한다
   3. 같은 이름의 Deployment를 새로 만들어 기존 관측을 이어 붙인다
   4. 같은 실행의 상태·조건·파드 응답을 조회해 미완료와 실패를 구분한다