クイズ: プラットフォームAPIとセルフサービス

v1과 v1alpha1을 served로 두고 v1만 storage로 지정했습니다. v1에만 용량 CEL을 넣었다면 무엇을 확인해야 합니까?

• 저장 버전이 하나이므로 v1 정상 요청만 검사하면 됩니다
• v1alpha1 경로에서도 금지 입력이 거절되는지 검사해야 합니다
• v1alpha1을 storage로도 설정하면 검증이 자동 복제됩니다
• 두 버전의 출력 컬럼만 같으면 요청 계약도 같아집니다

optionalOldSelf를 사용하지 않고 spec에 self == oldSelf 규칙을 붙였습니다. tier만 고정하려던 의도와 무엇이 다릅니까?

• 최초 생성 시 빈 oldSelf와 비교하므로 모든 생성을 막습니다
• status도 자동 비교하므로 관측 상태 변경만 거절합니다
• spec 전체를 비교하므로 정상 replicas 변경까지 거절합니다
• 객체 비교는 지원되지 않으므로 언제나 CRD 등록이 실패합니다

status 서브리소스가 켜진 AppClaim에 사용자가 일반 PATCH로 status.phase=Ready를 보냈습니다. 올바른 설명은?

• status 변경은 무시되며 이것이 실제 서비스 Ready를 증명하지 않습니다
• spec 수정 권한이 있으면 status와 외부 서비스도 함께 준비됩니다
• status라는 필드는 존재 자체가 금지되어 CRD가 제거됩니다
• 별도 status 객체가 생성되고 그 객체만 ResourceQuota에 셉니다

AppClaim 전용 Role에서 secrets get을 제거했는데 같은 주체의 조회가 계속 허용됩니다. 다음 확인은?

• CRD의 tier enum에서 시크릿과 관련된 문자열을 제거합니다
• ResourceQuota의 AppClaim 개수를 줄여 조회를 제한합니다
• 좁은 Role에 deny 동사를 추가해 다른 허용을 취소합니다
• 주체의 다른 바인딩과 최종 인가 판정의 범위를 확인합니다

테넌트가 roles create 권한만 얻었으며 추가할 고권한이나 escalate는 없습니다. 이것만으로 고권한 Role을 만들 수 있습니까?

• Role 생성과 즉시 바인딩이 함께 이루어져 관리자 권한이 생깁니다
• 기존 권한을 넘어서는 Role 생성은 별도 권한 상승 방지 검사에 걸립니다
• Role은 문서이므로 모든 권한을 자유롭게 담되 실행 시점에만 검사합니다
• ResourceQuota가 roles 개수만 허용하면 고권한 내용도 자동 허용됩니다

정상 get 조회는 yes/종료 코드 0이었지만 삭제 can-i 조회는 연결 오류, 빈 stdout, 종료 코드 1입니다. 보고서에는 어떻게 판단합니까?

• 종료 코드가 1이므로 정책이 삭제를 막았다고 no를 기록합니다
• 이전 get이 성공했으므로 현재 삭제도 허용으로 추정합니다
• 삭제 판정은 미확인입니다. 연결 문제를 확인하고 다시 조회합니다
• AppClaim 개수만 2라면 삭제 권한은 보고서에서 생략해도 됩니다

CRD 직후 쿼터 spec.hard는 2인데 status.used가 비었습니다. 아직 원인을 조사하지 않았을 때 올바른 다음 행동은?

• Established·discovery·실제 개수·status를 확인하고 반영과 컨트롤러를 진단합니다
• 사용량이 없다는 것은 0이므로 세 번째 요청을 정상 신청으로 계속 보냅니다
• 쿼터 재생성만이 유일한 복구이므로 상한을 먼저 삭제해 둡니다
• 저장 버전이 틀렸다는 뜻이므로 CRD와 네임스페이스부터 재생성합니다

이 실습은 테넌트 delete를 막습니다. 다른 플랫폼의 삭제 설계에 대한 올바른 설명은?

• Kubernetes는 모든 커스텀 리소스에서 사용자 delete를 금지합니다
• finalizer 키만 추가하면 외부 자원 삭제 코드가 자동 생성됩니다
• 객체 개수 쿼터가 외부 자원 비용과 정리 완료까지 보장합니다
• 사용자 삭제와 finalizer 기반 정리를 허용하는 설계도 가능하며 컨트롤러가 필요합니다