퀴즈: 설정 배포와 업무 복구의 증거

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

1. 새 Git revision과 Synced·Healthy가 일치하지만 업무 경로는 500이다. 이 관측의 해석은?

   1. 컨트롤러의 동기화 성공과 업무 요청 성공은 별도이므로 설정과 응답을 조사한다
   2. Healthy는 모든 HTTP 경로를 검사하므로 사용자의 브라우저 캐시부터 삭제한다
   3. Synced는 이전 커밋에서만 가능하므로 상태 필드를 수동으로 초기화한다
   4. 500은 DNS 해석 실패를 뜻하므로 정상인 애플리케이션 설정은 조사하지 않는다

2. ConfigMap만 고친 뒤 기존 subPath 마운트의 nginx가 계속 500을 낸다. 가장 직접적인 다음 조사 항목은?

   1. Argo CD 전체 캐시를 비우고 모든 Application의 컨트롤러를 재시작한다
   2. API의 설정과 Pod 안의 파일, Pod UID를 함께 비교해 소비 경계를 확인한다
   3. 현재 설정은 이미 갱신됐으므로 외부 결제 시스템 장애로 보고서를 마감한다
   4. 원격 main을 이전 커밋으로 강제 이동하고 변경 이력을 없앤다

3. 설정 해시가 바뀌면 새 Pod가 생기도록 선언하려 한다. 이번 방식에서 주석을 둘 위치는?

   1. ConfigMap의 metadata.annotations에만 두어 kubelet이 새 Pod를 만들게 한다
   2. Deployment의 status.conditions에 두어 Ready를 직접 갱신한다
   3. Deployment의 spec.template.metadata.annotations에 두어 템플릿을 바꾼다
   4. Application의 metadata.labels에 두어 실행 중 파일을 직접 교체한다

4. 설정 커밋 다음에 템플릿 커밋을 배포했다. 어떤 조합이 이번 Git 복구의 증거로 가장 적절한가?

   1. Application 이름과 Healthy 색상만 같고 커밋 및 Pod 신원은 기록하지 않는다
   2. ConfigMap 본문이 새 값이면 이전 Pod의 500 응답은 더 조사하지 않는다
   3. 새 Pod의 이름만 다르면 응답 본문과 Deployment 교체 여부는 생략한다
   4. 커밋 계보·동기화 revision·새 Pod UID·마운트 파일·200 본문을 함께 비교한다

5. VM에서 ClusterIP 업무 경로가 세 번 200을 반환했다. 운영 보고서에 적절한 결론은?

   1. 내부 경로의 관측 표본은 성공했지만 외부 경로와 지속 가용성은 추가 확인한다
   2. 외부 DNS와 TLS도 같은 클러스터에 있으므로 별도 관측 없이 정상으로 확정한다
   3. 세 번 성공했으므로 월간 가용성 목표를 이미 달성했다고 계산한다
   4. Pod Ready가 있으므로 성공 본문이 이전 버전인지 구분하지 않는다

6. 부분 작성한 rollout.json이 있는 상태에서 이전 단계 준비를 눌렀다. 도우미의 올바른 동작은?

   1. 학습 시간을 줄이기 위해 현재 단계까지 정답 파일로 덮어쓴다
   2. 기존 파일을 보존하고 없는 이전 단계만 준비하며 현재 정답은 만들지 않는다
   3. 기존 파일을 지운 뒤 정상 관측처럼 꾸민 JSON으로 모든 단계를 통과시킨다
   4. 기존 관측을 지우고 재채점할 때마다 처음부터 같은 장애를 다시 만든다