クイズ：デプロイと復旧の証拠

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

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

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

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

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

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

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

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

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

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

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

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