Quiz: deletion protection and restoration evidence

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

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

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

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

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

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

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

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

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

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

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

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