Quiz: reconciliation ownership and maintenance scope

자식 Application에 enabled=false를 patch한 API 응답은 성공했지만 같은 UID에서 true로 되돌아왔습니다. ownerReferences가 ApplicationSet을 가리킬 때 먼저 조사할 곳은?

• 부모 ApplicationSet의 template와 자식 필드 예외 정책
• ConfigMap의 데이터 백업과 볼륨 복원 정책
• 새 Pod의 readiness 경로와 재시작 횟수
• Git 원격의 인증서 만료와 DNS 캐시 시간

enabled=false 상태에서 sync.revision은 새 커밋이고 OutOfSync이며 실제 설정은 옛 값입니다. 가장 타당한 설명은?

• 저장소를 전혀 읽지 못해 새 커밋의 존재를 모르는 상태다.
• 새 목표를 비교했지만 자동 적용은 중지된 상태일 수 있다.
• 리소스가 Healthy이므로 새 데이터도 이미 적용된 상태다.
• Git 브랜치 이름이 같으므로 revision 차이는 무시해도 된다.

자동 동기화를 끈 상태에서 승인된 수동 sync가 같은 Git 커밋을 적용했습니다. 보고서에 맞는 표현은?

• 모든 변경 경로가 차단되어 수동 요청도 실행되지 않았다.
• 수동 sync가 성공했으므로 enabled가 반드시 true로 바뀌었다.
• 자동화 중지는 수동 요청 권한까지 없애는 잠금이 아니다.
• 수동 sync는 실제 데이터를 바꾸지 않는 읽기 전용 비교다.

특정 자식 하나의 자동화 토글만 임시로 허용하려고 합니다. 이번 단일 source 실습에서 가장 좁은 예외는?

• 모든 자식의 spec 전체를 비교에서 제외한다.
• 모든 자식의 source와 syncPolicy를 함께 제외한다.
• ConfigMap 전체를 Git 비교에서 제외한다.
• 자식 name과 enabled 필드의 jsonPointer를 함께 지정한다.

수동으로 맞춘 뒤 Synced가 됐습니다. 임시 예외를 종료하고 자동화 복귀를 검증하는 방법은?

• 예외 제거와 부모·자식 정책을 확인한 뒤 새 Git 변경의 실제 적용을 본다.
• 기존 Synced 화면만 다시 읽고 새로운 검증 없이 종료한다.
• 수동 동기화를 한 번 더 누르면 자동화가 복구됐다고 보고한다.
• ConfigMap 이름이 같으면 정책과 Git revision은 확인하지 않는다.

operation.initiatedBy.username에 담당자 이름이 적혀 있습니다. 이 문자열의 올바른 취급은?

• 문자열만으로 인증된 사용자와 승인 권한이 증명됐다고 기록한다.
• 요청 메타데이터로 보고 실제 인증·권한 감사 증거와 구분한다.
• username이 있으면 해당 operation은 자동 조정이라고 간주한다.
• 요청 메타데이터가 있으므로 실제 객체 변경 여부는 생략한다.