クイズ：リクエスト・準備・回収の証拠

App은 Synced=True·Ready=False지만 해당 파드의 HTTP는 정상입니다. 먼저 확인할 것은?

• Composition이 실제 자원의 조건 이름을 검사하는지
• Service를 삭제하면 상위 요청도 정상으로 바뀌는지
• 개발자에게 cluster-admin을 주면 응답이 빨라지는지
• Ready 검사를 없애면 운영 검증도 충분한지

자기 팀의 replicas=4 요청과 다른 팀의 replicas=1 요청은 왜 다르게 실패하나요?

• 둘 다 같은 스키마 오류라 팀 권한은 무관하다
• 앞은 입력 상한, 뒤는 대상 팀의 권한 위반이다
• 앞은 이미지 오류, 뒤는 Service 포트 오류다
• 둘 다 정상 수락 후 파드 준비 단계에서만 실패한다

변경 직후 이전 Ready 상태가 보입니다. 새 설정 반영의 더 강한 증거는?

• metadata.name이 이전 이름과 같다는 사실
• apply 명령이 종료 코드 0으로 끝난 사실
• 현재 관측 세대·갱신 복제수·해당 파드의 응답
• 과거에 한 번 성공한 HTTP 응답을 저장한 파일

App은 replicas=2인데 하위 Deployment를 3으로 고쳤다가 2로 돌아왔습니다. 가장 맞는 해석은?

• Kubernetes는 세 번째 복제본을 원래 허용하지 않는다
• 새 요청 UID가 생겨 이전 앱과 자동으로 병합됐다
• API 서버가 모든 수동 패치를 무조건 버리는 중이다
• 컨트롤러가 원본 App의 선언으로 하위 상태를 수렴시켰다

delete --wait=false는 성공했지만 deletionTimestamp와 finalizer가 남았습니다. 올바른 판정은?

• 삭제를 요청했지만 실제 부재는 아직 확인하지 못했다
• 성공 응답을 받았으니 모든 하위 자원이 이미 사라졌다
• finalizer가 하나라도 있으면 영구적으로 삭제할 수 없다
• 상위 객체가 남았으니 모든 하위 파드도 반드시 살아 있다

교육용 finalizer를 해제할 때 UID와 resourceVersion을 먼저 대조하는 이유는?

• 조회 API의 응답 속도를 보장하기 위해서
• 같은 이름의 새 객체나 동시 변경을 덮지 않기 위해서
• 다른 컨트롤러의 정리 작업을 자동으로 생략하기 위해서
• 네임스페이스의 모든 자원을 한 번에 삭제하기 위해서

자원 목록 조회가 인증 오류로 실패했습니다. 삭제 검사기의 올바른 처리는?

• 응답 목록이 없으므로 회수 완료로 저장
• 직전 성공 파일이 있으므로 현재 부재로 저장
• 관측 실패로 남기고 같은 대상의 조회 원인을 조사
• 다른 팀까지 삭제한 뒤 빈 결과인지 다시 확인

같은 이름으로 App을 다시 만들었고 예전 ready.json이 있습니다. 이 기록을 쓸 수 있나요?

• 이름과 네임스페이스가 같으면 충분하다
• HTTP가 한 번 응답했으면 어느 요청에도 쓸 수 있다
• 파일의 시각만 현재로 고치면 같은 관측이 된다
• UID가 달라 이전 요청의 기록을 재사용할 수 없다