クイズ：設定の配信とサービス復旧の証拠

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

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

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

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

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

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

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

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

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

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

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

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