퀴즈: 배포와 복구의 증거

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

1. 새 커밋이 Synced인데 파드는 Ready가 아니며 HTTP가 실패합니다. 가장 정확한 해석은?

   1. 새 선언과 일치할 수 있지만 서비스 준비와 응답 성공은 별도로 확인해야 합니다
   2. Synced이므로 HTTP 실패는 반드시 클라이언트 DNS 문제입니다
   3. Git 변경이 반영되지 않았다는 뜻이므로 같은 커밋을 계속 푸시합니다
   4. 컨테이너가 실행 중이면 readiness 결과는 배포 판단에서 제외합니다

2. Application의 targetRevision이 정상 커밋 A의 전체 SHA입니다. 브랜치 main에 새 커밋 B만 푸시했습니다. 기대할 수 있는 동작은?

   1. 자동 동기화가 켜져 있으면 언제나 B로 이동합니다
   2. A를 계속 추적하며 B 배포를 원하면 추적 대상도 갱신해야 합니다
   3. A는 브랜치가 이동하는 순간 저장소에서 삭제됩니다
   4. B가 도착하면 Argo CD가 자동 동기화를 영구 비활성화합니다

3. 정상 A 이후 나쁜 B를 git revert한 새 커밋 C로 복구합니다. 이번 stateless 설정 복구의 적절한 확인은?

   1. 관찰 SHA가 A와 같을 때만 성공입니다
   2. C를 푸시했다는 로그만 있으면 충분합니다
   3. C의 변경 내용과 관찰 SHA·준비 상태·실제 응답을 대조합니다
   4. C에 revert라는 메시지가 있으면 파드 상태를 생략합니다

4. 새 파드의 readiness가 실패하는데 Service 요청은 계속 200입니다. RollingUpdate 환경에서 먼저 확인할 것은?

   1. Kubernetes가 readiness 실패를 무시하는지
   2. 응답이 200이면 새 버전의 모든 파드가 정상인지
   3. Git이 이미지 태그를 자동으로 되돌렸는지
   4. 이전 정상 파드가 엔드포인트에 남아 요청을 처리하는지

5. 배포 승인 함수가 빈 JSON에서도 성공했습니다. 어떤 검증을 추가해야 합니까?

   1. 필수 증거가 없으면 거절하고, 필드 누락·이전 커밋·잘못된 본문 반례를 각각 시험합니다
   2. 누락한 숫자는 모두 0으로 보정한 뒤 성공으로 처리합니다
   3. 정상 응답 한 가지를 다시 실행해 통과 횟수를 늘립니다
   4. 필드가 없다는 로그를 지워 사용자 혼란을 줄입니다

6. VM에서 Service ClusterIP로 보낸 한 번의 HTTP 요청이 정상입니다. 이 증거의 범위는?

   1. 외부 DNS·TLS·인증·모든 업무 흐름의 성공까지 검증했습니다
   2. 그 요청과 경로의 성공을 확인했으며 외부 경로와 다른 업무 흐름은 별도 검사합니다
   3. 서비스의 지속적인 SLO 달성을 증명했습니다
   4. 이 릴리스의 DB 마이그레이션 되돌리기까지 안전합니다