퀴즈: 조정 소유권과 유지보수 범위

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

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

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

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

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

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

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

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

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

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

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

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

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