퀴즈: 삭제 보호와 복원 증거

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

1. Git에서 retained 정의를 지웠지만 객체는 같은 UID로 남고 OutOfSync/Succeeded이며 PruneSkipped가 있습니다. 가장 타당한 해석은?

   1. Prune=false에 따라 삭제를 건너뛰었고 Git과의 차이는 남아 있다.
   2. Git 복원이 완료되어 새 객체가 같은 UID를 재사용한 상태이다.
   3. 저장소 인증이 실패해서 현재 커밋의 비교 자체를 하지 못했다.
   4. 리소스 health 검사가 삭제 승인을 대신해 곧 자동 삭제된다.

2. Prune=confirm인 ConfigMap을 Git에서 제거하자 operation이 Running이고 삭제 승인 대기 메시지가 있습니다. 다음 행동으로 적절한 것은?

   1. 컨트롤러를 재시작하여 Running 작업을 자동 성공으로 전환한다.
   2. 현재 Application과 전체 삭제 예정 목록을 검토한 뒤 승인한다.
   3. live 객체를 직접 삭제하고 Git 비교가 끝날 때까지 기다린다.
   4. Delete=false를 추가하면 현재 prune 승인이 끝났다고 기록한다.

3. 빈 목표 커밋 B가 SyncError인데 operationState에는 Succeeded와 커밋 A가 남아 있습니다. 무엇을 확인한 것인가?

   1. B의 작업이 성공했고 오류 조건은 의미 없는 과거 기록이다.
   2. A와 B는 같은 브랜치이므로 두 작업의 성공을 합쳐도 된다.
   3. 과거 A의 작업 성공이며 현재 B의 자동 삭제는 거부된 상태다.
   4. 리소스 UID가 같으므로 B의 모든 변경이 실제로 실행됐다.

4. 빈 목표 보호를 검증할 재료로 가장 적절한 것은?

   1. 존재하지 않는 Git 디렉터리로 경로를 바꾸고 오류를 기다린다.
   2. 클러스터 접속 주소를 틀리게 바꾸고 리소스가 남는지 본다.
   3. 저장소 읽기 권한을 제거한 뒤 마지막 성공 상태만 확인한다.
   4. 유효한 빈 List를 커밋하고 현재 revision·조건·보존 UID를 본다.

5. allowEmpty=true로 disposable을 삭제한 뒤 Git 정의를 복원하자 같은 이름의 새 UID가 생겼습니다. 보고서에 맞는 표현은?

   1. 선언한 ConfigMap을 재생성했으며 데이터 백업 복구는 별도 검증이다.
   2. 이전 객체가 같은 신원으로 부활했으며 연결된 데이터도 복구됐다.
   3. 이전 UID가 없어졌으므로 Git 복원은 어떤 의미에서도 실패했다.
   4. 새 UID가 있으므로 영속 볼륨의 시점 복구까지 통과한 상태다.

6. Delete=false를 넣었으니 Git에서 제거한 리소스도 prune되지 않는다는 리뷰가 있습니다. 올바른 검토 의견은?

   1. Delete와 Prune는 같은 옵션의 두 이름이므로 그대로 승인한다.
   2. Application 삭제 시 정리와 Git 제거에 따른 prune를 나눠 검토한다.
   3. 자동 동기화를 사용하면 두 옵션은 모두 무시되므로 제거한다.
   4. 리소스 health가 Healthy일 때만 Delete 옵션이 Prune로 바뀐다.