퀴즈: 요청·준비·회수의 증거

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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