Quiz: Recovery that reproduces configuration

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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