퀴즈: 열린 문의 조건을 추적하기

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

1. orders를 허용하던 정책에 JWT 주체를 허용하는 별도 ALLOW를 추가하자 낯선 워크로드도 통과했습니다. 가장 직접적인 설명은?

   1. 모든 허용 정책이 교집합으로 처리됐지만 신원 캐시가 갱신되지 않았다
   2. 허용 정책 중 하나라도 일치하는 경로가 생겨 JWT만으로도 허용됐다
   3. JWT 검증이 성공하면 어떤 DENY 정책도 자동으로 비활성화된다
   4. 정책을 추가한 네임스페이스에서 mTLS가 자동으로 평문으로 바뀌었다

2. 같은 from.source에 principals와 requestPrincipals를 함께 둔 이유는?

   1. 두 필드 중 문자열이 더 긴 신원을 선택하기 위해
   2. 토큰이 없으면 워크로드 신원을 대신 넣기 위해
   3. 검증된 워크로드와 검증된 JWT 주체를 함께 요구하기 위해
   4. 워크로드 신원 대신 JWT 서명 키를 저장하기 위해

3. scoped에서 토큰 없는 8080은 403, 8081은 200입니다. 가장 정확한 완료 보고는?

   1. JWT 없음 DENY가 지정한 8080 범위에 작동했고 8081까지 보호한 것은 아니다
   2. 동일 파드의 모든 포트가 JWT 검증을 강제하므로 8081도 안전하다
   3. 8081은 HTTP가 아니므로 이 실습의 응답 코드에는 의미가 없다
   4. 403이 한 번 나왔으므로 다른 출발지와 경로의 시험은 생략해도 된다

4. 두 요청이 모두 403인데 하나는 audience 오류, 다른 하나는 RBAC 거부 본문을 냅니다. 다음 조사는?

   1. 모든 403은 동일한 인가 오류이므로 ALLOW 정책만 넓힌다
   2. JWT 서명 검사를 끄고 응답 코드가 바뀌는지만 확인한다
   3. 두 요청 모두 만료로 분류하고 토큰 유효기간만 늘린다
   4. 코드와 본문을 보존하고 JWT 검증 설정과 인가 조건을 나눠 대조한다

5. YAML은 정답인데 채점이 실제 적용 정책과 다르다고 합니다. 무엇을 먼저 확인해야 하나요?

   1. 파일 내용을 서버가 자동으로 읽을 때까지 브라우저만 새로 고친다
   2. 올바른 네임스페이스에 apply했는지 확인하고 실제 객체와 전파된 응답을 대조한다
   3. 채점에 성공하도록 저장된 JSON의 HTTP 코드만 200으로 바꾼다
   4. 다른 정책과 충돌하지 않도록 기존 ALLOW와 DENY를 전부 삭제한다

6. intersection이 payments-api와 other-api를 모두 허용하다 payments-api 하나로 좁혀졌습니다. 반드시 다시 볼 요청은?

   1. 정상 결제용 토큰 하나만 확인하고 다른 audience 요청은 생략한다
   2. 모든 JWT를 제거한 뒤 HTTP 포트가 열려 있는지만 확인한다
   3. 정상 결제용은 계속 성공하고 다른 API용은 실제로 거부되는지 함께 확인한다
   4. 정책 파일 이름이 길어졌는지 보고 검증 강화 여부를 판단한다