[Golden Kubestronaut] ICA 실전 연습 문제 80제 - Istio Certified Associate

• A) minimal
• B) default
• C) demo
• D) preview

정답: B) default

default 프로필은 프로덕션 배포에 권장되는 프로필입니다. istiod와 Ingress Gateway를 포함합니다. demo 프로필은 모든 컴포넌트를 포함하지만 리소스 요구사항이 낮아 학습/테스트용입니다. minimal은 istiod만 포함하고, preview는 실험적 기능을 포함합니다.

• A) istioctl apply --set profile=default
• B) istioctl install --set profile=default
• C) istioctl setup --profile=default
• D) istioctl init --set profile=default

정답: B) istioctl install --set profile=default

istioctl install 명령어가 Istio를 클러스터에 설치하는 표준 방법입니다. --set profile= 플래그로 설치 프로필을 지정할 수 있습니다. apply, setup, init은 유효한 istioctl 하위 명령이 아닙니다.

• A) spec.components.NAME.disabled: true
• B) spec.components.NAME.enabled: false
• C) spec.components.NAME.install: false
• D) spec.values.NAME.enabled: false

정답: B) spec.components.NAME.enabled: false

IstioOperator CRD에서 각 컴포넌트는 spec.components 하위에 위치하며, enabled: false로 설정하여 비활성화할 수 있습니다. 예를 들어 Ingress Gateway를 비활성화하려면 spec.components.ingressGateways[0].enabled: false로 설정합니다.

• A) istioctl install --set revision=canary
• B) istioctl upgrade --canary
• C) istioctl install --set tag=canary
• D) istioctl canary install

정답: A) istioctl install --set revision=canary

revision 기반 카나리 업그레이드는 --set revision= 플래그를 사용하여 새로운 컨트롤 플레인 인스턴스를 기존 것과 나란히 설치합니다. 이후 네임스페이스 라벨을 istio.io/rev=canary로 변경하여 워크로드를 점진적으로 마이그레이션합니다.

• A) sidecar.istio.io/inject: "true"
• B) istio-injection: enabled
• C) istio.io/sidecar: "true"
• D) inject.istio.io: "true"

정답: B) istio-injection: enabled

네임스페이스에 istio-injection: enabled 라벨을 설정하면 해당 네임스페이스의 모든 파드에 Envoy 사이드카가 자동으로 주입됩니다. revision 기반 설치에서는 istio.io/rev=REVISION_NAME 라벨을 사용합니다.

• A) 클러스터의 네트워크 성능 분석
• B) Istio 구성의 잠재적 문제점 검출
• C) Envoy 프록시의 메모리 사용량 분석
• D) 서비스 간 트래픽 패턴 분석

정답: B) Istio 구성의 잠재적 문제점 검출

istioctl analyze는 Istio 구성을 정적으로 분석하여 잠재적 문제점, 잘못된 구성, 베스트 프랙티스 위반 등을 검출합니다. 라이브 클러스터 또는 로컬 파일 세트에 대해 실행할 수 있습니다.

• A) Pilot, Mixer, Galley
• B) Pilot, Citadel, Galley
• C) Pilot, Citadel, Mixer
• D) Envoy, Pilot, Citadel

정답: B) Pilot, Citadel, Galley

istiod는 Istio 1.5부터 Pilot(트래픽 관리/xDS), Citadel(인증서 관리/CA), Galley(구성 검증)를 단일 바이너리로 통합했습니다. Mixer는 Istio 1.8에서 제거되었고, Envoy는 데이터 플레인 프록시입니다.

• A) 프록시와 istiod 간의 동기화 상태
• B) 프록시가 수신한 xDS 구성 버전
• C) 프록시의 CPU/메모리 사용량
• D) 프록시의 CDS, LDS, EDS, RDS 상태

정답: C) 프록시의 CPU/메모리 사용량

istioctl proxy-status는 각 프록시의 xDS 동기화 상태(SYNCED, NOT SENT, STALE)를 보여줍니다. CDS, LDS, EDS, RDS 각각의 동기화 상태와 버전을 확인할 수 있지만, 리소스 사용량은 Prometheus 메트릭이나 kubectl top으로 확인해야 합니다.

• A) spec.http.route 에 여러 destination을 weight와 함께 정의
• B) spec.tcp.split 에 비율을 정의
• C) spec.http.mirror 에 두 대상을 정의
• D) spec.http.redirect 에 비율을 정의

정답: A) spec.http.route 에 여러 destination을 weight와 함께 정의

VirtualService의 spec.http[].route[]에 여러 destination을 정의하고 각각에 weight를 설정하여 트래픽을 분할합니다. 예를 들어 v1에 80%, v2에 20%를 보내는 카나리 배포가 가능합니다.

• A) spec.subsets[].labels
• B) spec.trafficPolicy.subsets
• C) spec.host.subsets
• D) spec.subsets[].name 과 spec.subsets[].labels

정답: D) spec.subsets[].name 과 spec.subsets[].labels

DestinationRule의 subset은 name으로 식별하고, labels로 해당 subset에 포함될 파드를 선택합니다. VirtualService에서는 이 subset name을 참조하여 트래픽을 라우팅합니다.

• A) 백엔드 서버의 주소를 정의
• B) 게이트웨이가 수신할 포트와 프로토콜을 정의
• C) 서비스 디스커버리에 사용할 서버 목록 정의
• D) Envoy 프록시 서버의 개수를 정의

정답: B) 게이트웨이가 수신할 포트와 프로토콜을 정의

Gateway 리소스의 spec.servers[]는 게이트웨이가 리슨할 포트, 프로토콜(HTTP/HTTPS/TCP 등), 호스트 이름을 정의합니다. TLS 설정도 여기에 포함됩니다. 실제 라우팅은 VirtualService에서 수행합니다.

• A) 메시 내부 서비스 등록
• B) 외부 서비스를 Istio 메시의 서비스 레지스트리에 추가
• C) Kubernetes Service 생성
• D) DNS 서버 구성 변경

정답: B) 외부 서비스를 Istio 메시의 서비스 레지스트리에 추가

ServiceEntry를 사용하면 메시 외부의 서비스(예: 외부 API, 데이터베이스)를 Istio의 서비스 레지스트리에 등록할 수 있습니다. 이를 통해 외부 서비스에도 트래픽 관리, mTLS, 모니터링 정책을 적용할 수 있습니다.

• A) spec.http[].match[].headers
• B) spec.http[].route[].headers
• C) spec.http[].filter.headers
• D) spec.http[].headerMatch

정답: A) spec.http[].match[].headers

VirtualService의 HTTP 매치 조건에서 headers 필드를 사용하여 특정 헤더 값에 따라 라우팅할 수 있습니다. exact, prefix, regex 매칭을 지원합니다.

• A) spec.trafficPolicy.connectionPool
• B) spec.connectionPool
• C) spec.policy.pool
• D) spec.trafficPolicy.connections

정답: A) spec.trafficPolicy.connectionPool

연결 풀 설정은 spec.trafficPolicy.connectionPool 아래에 tcp와 http 섹션으로 나뉩니다. TCP에서는 maxConnections, HTTP에서는 h2UpgradePolicy, maxRequestsPerConnection 등을 설정합니다.

• A) 밀리초만 지원
• B) 초 단위 (예: "10s")
• C) 분 단위만 지원
• D) 정수만 지원 (단위 없음)

정답: B) 초 단위 (예: "10s")

VirtualService의 spec.http[].timeout은 Duration 형식으로 지정하며, "10s", "0.5s" 등으로 표현합니다. 기본값은 타임아웃 없음(0s)이며, 이 설정은 Envoy의 route timeout으로 변환됩니다.

• A) spec.http[].rewrite.uri
• B) spec.http[].route[].rewrite
• C) spec.http[].redirect.uri
• D) spec.http[].transform.uri

정답: A) spec.http[].rewrite.uri

spec.http[].rewrite 필드에서 uri와 authority를 재작성할 수 있습니다. rewrite는 요청을 프록시하면서 URI를 변경하고, redirect는 클라이언트에게 3xx 응답을 반환합니다.

• A) 서비스 이름만 (예: "reviews")
• B) namespace/hostname 형식 (예: "./", "istio-system/")
• C) IP 주소만
• D) URL 형식 (예: "http://reviews:9080")

정답: B) namespace/hostname 형식 (예: "./", "istio-system/")

Sidecar 리소스의 egress.hosts는 "namespace/dnsName" 형식을 사용합니다. "./"는 같은 네임스페이스의 모든 서비스, "istio-system/"는 istio-system의 모든 서비스를 의미합니다. 이를 통해 사이드카가 알아야 할 서비스 범위를 제한하여 메모리를 절약합니다.

• A) spec.http[].mirror
• B) spec.http[].shadow
• C) spec.http[].duplicate
• D) spec.http[].copy

정답: A) spec.http[].mirror

spec.http[].mirror는 트래픽을 다른 서비스로 미러링(복제)합니다. 미러링된 요청은 "fire and forget" 방식으로 전송되며, 응답은 무시됩니다. mirrorPercentage로 미러링 비율을 조절할 수 있습니다.

• A) 클라이언트 인증서만
• B) 서버 인증서와 개인 키
• C) CA 인증서만
• D) 인증서 없이 가능

정답: B) 서버 인증서와 개인 키

SIMPLE TLS 모드는 단방향 TLS로, 서버 인증서(credentialName으로 참조되는 Secret)가 필요합니다. MUTUAL 모드는 클라이언트 인증서도 요구하고, PASSTHROUGH는 TLS 종료 없이 통과시킵니다.

• A) spec.http[].match[].uri.regex
• B) spec.http[].match[].uri.pattern
• C) spec.http[].match[].uri.regexp
• D) spec.http[].match[].uri.match

정답: A) spec.http[].match[].uri.regex

URI 매칭에서 regex 필드는 RE2 정규식 문법을 사용합니다. exact(정확한 매칭), prefix(접두사 매칭), regex(정규식 매칭) 세 가지 방식을 지원합니다.

• A) ROUND_ROBIN
• B) LEAST_CONN
• C) RANDOM
• D) WEIGHTED_RESPONSE_TIME

정답: D) WEIGHTED_RESPONSE_TIME

Istio DestinationRule은 ROUND_ROBIN(기본값), LEAST_CONN, RANDOM, PASSTHROUGH를 지원합니다. 또한 consistentHash를 사용한 세션 어피니티도 지원합니다. WEIGHTED_RESPONSE_TIME은 Istio에서 지원하지 않는 알고리즘입니다.

• A) httpHeaderName
• B) httpCookie
• C) useSourceIp
• D) httpMethod

정답: D) httpMethod

consistentHash는 httpHeaderName, httpCookie, useSourceIp, httpQueryParameterName을 해시 키로 지원합니다. HTTP 메서드(GET, POST 등)는 해시 키로 사용할 수 없습니다.

• A) spec.hosts와 spec.gateways 모두 설정
• B) spec.hosts만 설정
• C) spec.gateway 단수형으로 설정
• D) spec.bind로 Gateway 참조

정답: A) spec.hosts와 spec.gateways 모두 설정

VirtualService를 Gateway에 바인딩하려면 spec.gateways[]에 Gateway 이름을 지정하고, spec.hosts[]에 Gateway의 server host와 일치하는 호스트를 설정해야 합니다. 메시 내부 트래픽에도 적용하려면 "mesh"를 gateways에 추가합니다.

• A) spec.http[].match[].sourceLabels
• B) spec.http[].match[].source
• C) spec.http[].from
• D) spec.http[].match[].sourceNamespace 와 spec.http[].match[].sourceLabels

정답: D) spec.http[].match[].sourceNamespace 와 spec.http[].match[].sourceLabels

match 조건에서 sourceLabels로 소스 워크로드의 라벨을 매칭하고, sourceNamespace로 소스 네임스페이스를 제한할 수 있습니다. 이를 통해 특정 서비스에서 오는 요청에만 다른 라우팅 규칙을 적용할 수 있습니다.

• A) spec.http[].headers.request.set
• B) spec.http[].route[].headers.request
• C) spec.http[].addHeaders
• D) spec.http[].requestHeaders

정답: A) spec.http[].headers.request.set

VirtualService의 headers 필드에서 request와 response 각각에 대해 set(설정/덮어쓰기), add(추가), remove(제거) 작업을 수행할 수 있습니다. route 수준에서도 헤더 조작이 가능합니다.

• A) DNS를 통해 엔드포인트를 해석
• B) endpoints 필드에 지정된 IP를 직접 사용
• C) 서비스 메시 내부의 Kubernetes Service를 참조
• D) mTLS를 비활성화하고 평문 통신

정답: B) endpoints 필드에 지정된 IP를 직접 사용

resolution이 STATIC이면 endpoints 필드에 명시된 IP 주소를 직접 사용합니다. DNS는 DNS 서버를 통해 해석하고, NONE은 연결 시 원래 요청 주소를 사용합니다.

• A) 301 (Moved Permanently)
• B) 302 (Found)
• C) 307 (Temporary Redirect)
• D) 308 (Permanent Redirect)

정답: A) 301 (Moved Permanently)

VirtualService의 spec.http[].redirect에서 redirectCode를 지정하지 않으면 기본값은 301입니다. redirectCode 필드로 301, 302, 303, 307, 308 등을 명시적으로 설정할 수 있습니다.

• A) 수동으로 인증서를 지정한 mTLS
• B) Istio가 자동으로 관리하는 mTLS
• C) TLS 없이 평문 통신
• D) 단방향 TLS만 사용

정답: B) Istio가 자동으로 관리하는 mTLS

ISTIO_MUTUAL은 Istio의 CA(Citadel)가 자동으로 프로비저닝한 인증서를 사용하는 mTLS입니다. MUTUAL은 사용자가 직접 인증서를 지정하는 방식이고, SIMPLE은 단방향 TLS, DISABLE은 TLS 비활성화입니다.

• A) spec.workloadSelector
• B) spec.selector
• C) spec.podSelector
• D) spec.targetRef

정답: B) spec.selector

Gateway의 spec.selector는 matchLabels를 사용하여 이 Gateway 구성을 적용할 Istio Ingress/Egress Gateway 파드를 선택합니다. 일반적으로 istio: ingressgateway 라벨을 사용합니다.

• A) 다른 VirtualService에 라우팅 규칙을 위임
• B) 서비스 계정 권한을 위임
• C) TLS 인증서 관리를 위임
• D) 메트릭 수집을 다른 컴포넌트에 위임

정답: A) 다른 VirtualService에 라우팅 규칙을 위임

delegate를 사용하면 특정 경로 접두사에 대한 라우팅 규칙을 다른 VirtualService로 위임할 수 있습니다. 이를 통해 대규모 환경에서 라우팅 구성을 분산 관리할 수 있습니다.

• A) "." (현재 네임스페이스만)
• B) "*" (모든 네임스페이스)
• C) "~" (아무 곳에도 노출하지 않음)
• D) 기본값 없음 (필수 필드)

정답: B) "*" (모든 네임스페이스)

exportTo의 기본값은 "*"로 모든 네임스페이스에 노출됩니다. "."은 현재 네임스페이스만, "~"는 노출하지 않음을 의미합니다. 특정 네임스페이스를 지정할 수도 있습니다.

• A) TLS를 종료하고 평문으로 백엔드에 전달
• B) TLS 연결을 종료하지 않고 그대로 백엔드에 전달
• C) mTLS로 업그레이드하여 백엔드에 전달
• D) TLS를 종료하고 새로운 TLS로 재암호화

정답: B) TLS 연결을 종료하지 않고 그대로 백엔드에 전달

PASSTHROUGH 모드에서는 게이트웨이가 TLS 연결을 종료하지 않고 SNI 헤더를 기반으로 라우팅합니다. 이는 백엔드 서비스가 직접 TLS를 처리하는 경우에 사용됩니다.

• A) 오류 발생
• B) 모든 요청에 해당 라우팅 규칙이 적용
• C) 어떤 요청에도 적용되지 않음
• D) 기본 라우팅만 적용

정답: B) 모든 요청에 해당 라우팅 규칙이 적용

match 조건이 없는 HTTP 라우트는 모든 요청에 매칭됩니다. 이는 "catch-all" 규칙으로 사용되며, 보통 VirtualService의 마지막 규칙으로 배치합니다.

• A) 사이드카의 인바운드/아웃바운드 트래픽 범위 제한
• B) Envoy의 메모리 사용량 최적화
• C) 특정 포트의 프로토콜 명시
• D) 워크로드 간 mTLS 모드 설정

정답: D) 워크로드 간 mTLS 모드 설정

Sidecar 리소스는 사이드카 프록시의 가시성 범위를 제한하여 메모리를 절약하고, 인바운드/아웃바운드 리스너를 세밀하게 구성합니다. mTLS 모드 설정은 PeerAuthentication과 DestinationRule에서 수행합니다.

• A) 모든 조건이 AND로 결합
• B) 모든 조건이 OR로 결합
• C) 같은 match 내 조건은 AND, 다른 match 블록은 OR
• D) 우선순위에 따라 하나만 평가

정답: C) 같은 match 내 조건은 AND, 다른 match 블록은 OR

하나의 match 블록 내의 조건들(headers, uri, method 등)은 AND로 결합됩니다. 여러 match 블록은 OR로 평가되어 하나라도 매칭되면 해당 route가 적용됩니다.

• A) 서비스가 메시 외부에 있음
• B) 서비스가 메시 내부에 있지만 Kubernetes Service가 아님
• C) 서비스가 로컬 프록시에서만 접근 가능
• D) 서비스가 같은 네임스페이스에만 노출

정답: B) 서비스가 메시 내부에 있지만 Kubernetes Service가 아님

MESH_INTERNAL은 해당 서비스가 메시의 일부이지만 Kubernetes Service로 등록되지 않은 경우입니다(예: VM 워크로드). MESH_EXTERNAL은 메시 외부 서비스(외부 API 등)를 의미합니다.

• A) 총 요청 시도 횟수 (원래 요청 포함)
• B) 원래 요청 실패 후 재시도 횟수
• C) 동시 재시도 횟수
• D) 초당 최대 재시도 횟수

정답: B) 원래 요청 실패 후 재시도 횟수

retries.attempts는 원래 요청 실패 후 추가로 재시도하는 횟수입니다. 예를 들어 attempts가 3이면 최대 4번(원래 1번 + 재시도 3번)의 요청이 발생할 수 있습니다. retryOn으로 재시도 조건을 설정합니다.

• A) CLUSTER
• B) LISTENER
• C) ROUTE_CONFIGURATION
• D) SERVICE

정답: D) SERVICE

EnvoyFilter의 applyTo는 CLUSTER, LISTENER, ROUTE_CONFIGURATION, NETWORK_FILTER, HTTP_FILTER, HTTP_ROUTE, VIRTUAL_HOST 등을 지원합니다. SERVICE는 유효한 값이 아닙니다.

• A) spec.http[].corsPolicy
• B) spec.corsPolicy
• C) spec.http[].route[].corsPolicy
• D) spec.http[].headers.cors

정답: A) spec.http[].corsPolicy

CORS 정책은 spec.http[].corsPolicy에서 설정합니다. allowOrigins, allowMethods, allowHeaders, exposeHeaders, maxAge 등을 구성할 수 있습니다.

• A) 알파벳 순서
• B) 생성 시간 순서
• C) 정의된 순서 (위에서 아래로, 첫 번째 매칭 적용)
• D) weight 값 기준 내림차순

정답: C) 정의된 순서 (위에서 아래로, 첫 번째 매칭 적용)

VirtualService의 HTTP 규칙은 정의된 순서대로 평가되며, 첫 번째로 매칭되는 규칙이 적용됩니다. 따라서 더 구체적인 규칙을 먼저 배치해야 합니다.

• A) 5xx 에러 비율 임계값
• B) 연속 5xx 에러 횟수 임계값
• C) 5xx 에러 총 누적 수
• D) 5초 동안의 에러 수

정답: B) 연속 5xx 에러 횟수 임계값

consecutive5xxErrors는 엔드포인트가 연속으로 5xx 에러를 반환하는 횟수의 임계값입니다. 이 임계값을 초과하면 해당 엔드포인트는 로드밸런싱 풀에서 일시적으로 제거(ejection)됩니다.

• A) 서킷 브레이커가 활성화되기까지의 대기 시간
• B) 엔드포인트가 풀에서 제거되는 최소 시간
• C) 에러 감지 간격
• D) 전체 서킷이 열리는 시간

정답: B) 엔드포인트가 풀에서 제거되는 최소 시간

baseEjectionTime은 엔드포인트가 로드밸런싱 풀에서 제거되는 기본 시간입니다. 실제 제거 시간은 baseEjectionTime * ejection 횟수로 계산되어 반복 실패 시 점점 길어집니다.

• A) spec.http[].fault.delay.fixedDelay와 spec.http[].fault.delay.percentage
• B) spec.http[].delay.time
• C) spec.http[].fault.latency
• D) spec.http[].inject.delay

정답: A) spec.http[].fault.delay.fixedDelay와 spec.http[].fault.delay.percentage

fault injection의 delay는 fixedDelay로 지연 시간을, percentage.value로 지연이 적용되는 요청 비율을 설정합니다. 예를 들어 fixedDelay: 5s, percentage.value: 10으로 설정하면 10%의 요청에 5초 지연이 추가됩니다.

• A) abort가 트리거되는 조건의 상태 코드
• B) 클라이언트에게 반환할 HTTP 상태 코드
• C) 백엔드 서비스의 건강 상태 코드
• D) 프록시 내부 상태 코드

정답: B) 클라이언트에게 반환할 HTTP 상태 코드

fault.abort.httpStatus는 요청을 중단하고 클라이언트에게 반환할 HTTP 상태 코드(예: 500, 503)를 지정합니다. percentage.value와 함께 사용하여 일정 비율의 요청을 의도적으로 실패시킵니다.

• A) HTTP/1.1 최대 연결 수
• B) 연결 대기 중인 최대 요청 수
• C) 초당 최대 요청 수
• D) 최대 유휴 연결 수

정답: B) 연결 대기 중인 최대 요청 수

http1MaxPendingRequests는 연결 풀의 연결을 기다리는 대기 큐의 최대 크기입니다. 이 값을 초과하면 서킷 브레이커가 작동하여 503을 반환합니다. 기본값은 2^32-1(사실상 무제한)입니다.

• A) ejection 후 다시 확인하는 간격
• B) 에러 통계를 분석하는 주기
• C) 프록시가 헬스 체크를 수행하는 간격
• D) 로드밸런서가 엔드포인트를 갱신하는 간격

정답: B) 에러 통계를 분석하는 주기

interval은 outlier detection 분석을 수행하는 시간 간격입니다. 기본값은 10초입니다. 매 interval마다 각 엔드포인트의 에러 통계를 확인하고 ejection 여부를 결정합니다.

• A) 5xx
• B) gateway-error
• C) connect-failure
• D) client-error

정답: D) client-error

retryOn에는 5xx, gateway-error, connect-failure, retriable-4xx, refused-stream, retriable-status-codes, reset, retriable-headers 등을 설정할 수 있습니다. client-error는 유효한 retryOn 조건이 아닙니다.

• A) 클러스터 전체의 최대 요청 수
• B) 하나의 연결에서 처리할 최대 요청 수 (이후 연결 종료)
• C) 초당 연결당 최대 요청 수
• D) 동시 연결당 최대 요청 수

정답: B) 하나의 연결에서 처리할 최대 요청 수 (이후 연결 종료)

maxRequestsPerConnection은 단일 연결에서 처리할 수 있는 최대 요청 수입니다. 이 값에 도달하면 연결이 닫히고 새 연결이 생성됩니다. 1로 설정하면 Keep-Alive를 비활성화하는 효과가 있습니다.

• A) mTLS를 완전히 비활성화
• B) mTLS 연결만 허용, 평문 거부
• C) mTLS와 평문 모두 허용
• D) 선택적으로 mTLS 적용

정답: B) mTLS 연결만 허용, 평문 거부

STRICT 모드에서는 오직 mTLS 연결만 허용됩니다. 사이드카가 없는 서비스로부터의 평문 요청은 거부됩니다. PERMISSIVE는 mTLS와 평문 모두 허용, DISABLE은 mTLS를 비활성화합니다.

• A) 보안이 최우선인 프로덕션 환경
• B) 사이드카가 있는 서비스와 없는 서비스가 혼재할 때
• C) 외부 API와 통신할 때
• D) 인증서를 수동으로 관리할 때

정답: B) 사이드카가 있는 서비스와 없는 서비스가 혼재할 때

PERMISSIVE 모드는 mTLS와 평문 트래픽 모두를 수용합니다. 사이드카 주입을 점진적으로 적용하는 마이그레이션 과정에서 특히 유용합니다. 모든 서비스에 사이드카가 주입된 후 STRICT로 전환합니다.

• A) ALLOW 먼저 평가, 그 다음 DENY
• B) DENY 먼저 평가, 그 다음 ALLOW
• C) CUSTOM 먼저, 그 다음 DENY, 마지막 ALLOW
• D) 모든 정책을 동시에 평가

정답: C) CUSTOM 먼저, 그 다음 DENY, 마지막 ALLOW

AuthorizationPolicy의 평가 순서는 CUSTOM -> DENY -> ALLOW입니다. CUSTOM 액션이 거부하면 요청이 거부됩니다. DENY 정책에 매칭되면 거부됩니다. 마지막으로 ALLOW 정책에 매칭되면 허용됩니다. 어떤 ALLOW 정책에도 매칭되지 않으면 거부됩니다.

• A) spec.jwtRules[].issuer와 spec.jwtRules[].jwksUri
• B) spec.jwt.secret
• C) spec.authentication.token
• D) spec.rules[].jwt.key

정답: A) spec.jwtRules[].issuer와 spec.jwtRules[].jwksUri

RequestAuthentication의 jwtRules에서 issuer(토큰 발급자)와 jwksUri(공개 키 세트 URL)를 설정하여 JWT 토큰을 검증합니다. jwks(인라인 키)를 직접 제공할 수도 있습니다.

• A) 모든 요청을 허용
• B) 모든 요청을 거부
• C) 정책이 무시됨
• D) 오류 발생

정답: B) 모든 요청을 거부

action이 ALLOW인 AuthorizationPolicy에서 rules가 비어있으면 어떤 요청도 매칭되지 않으므로 모든 요청이 거부됩니다. 반대로 rules 없이 빈 spec으로 DENY를 사용하면 어떤 것도 거부되지 않습니다.

• A) Kubernetes ServiceAccount 이름
• B) SPIFFE ID 형식 (예: "cluster.local/ns/NAMESPACE/sa/SERVICE_ACCOUNT")
• C) Pod IP 주소
• D) 사용자 이름

정답: B) SPIFFE ID 형식 (예: "cluster.local/ns/NAMESPACE/sa/SERVICE_ACCOUNT")

source.principals는 SPIFFE 형식의 피어 ID를 사용합니다. Istio에서 각 워크로드는 Kubernetes ServiceAccount를 기반으로 SPIFFE ID를 부여받습니다. 와일드카드(*)도 사용 가능합니다.

• A) 1시간
• B) 12시간
• C) 24시간
• D) 7일

정답: C) 24시간

Istio에서 워크로드에 발급되는 X.509 인증서의 기본 유효 기간은 24시간입니다. 인증서는 만료 전에 자동으로 로테이션됩니다. 이 값은 istiod 환경변수로 조정할 수 있습니다.

• A) default
• B) kube-system
• C) istio-system
• D) 모든 네임스페이스에 개별 생성

정답: C) istio-system

istio-system 네임스페이스(또는 Istio 루트 네임스페이스)에 PeerAuthentication을 생성하면 메시 전체에 적용됩니다. 네임스페이스 수준 정책은 해당 네임스페이스의 모든 워크로드에 적용되며, 워크로드 수준이 가장 높은 우선순위를 가집니다.

• A) Kubernetes API 메서드
• B) HTTP 메서드 (GET, POST 등)
• C) gRPC 메서드
• D) Envoy 내부 메서드

정답: B) HTTP 메서드 (GET, POST 등)

operation.methods는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 기준으로 접근을 제어합니다. operation.paths로 경로, operation.ports로 포트를 추가로 제한할 수 있습니다.

• A) 소스 파드의 네임스페이스를 기준으로 필터링
• B) 대상 파드의 네임스페이스를 기준으로 필터링
• C) 서비스 레지스트리의 네임스페이스를 참조
• D) Kubernetes Namespace 리소스의 라벨을 확인

정답: A) 소스 파드의 네임스페이스를 기준으로 필터링

source.namespaces는 요청을 보내는 소스 워크로드의 네임스페이스를 기반으로 접근을 제어합니다. mTLS를 통해 소스의 ID가 확인되므로 mTLS가 활성화되어 있어야 합니다.

• A) spec.portLevelMtls에 포트 번호와 모드를 매핑
• B) spec.mtls.ports에 포트 목록 지정
• C) spec.selector.ports로 포트 선택
• D) 포트별 설정은 지원되지 않음

정답: A) spec.portLevelMtls에 포트 번호와 모드를 매핑

spec.portLevelMtls는 특정 포트에 대해 개별 mTLS 모드를 설정할 수 있습니다. 예를 들어 헬스 체크 포트만 DISABLE하고 나머지는 STRICT로 설정할 수 있습니다.

• A) 사용자 정의 HTTP 상태 코드 반환
• B) 외부 인가 서비스(예: OPA)에 인가 결정을 위임
• C) 사용자 정의 로깅
• D) 사용자 정의 메트릭 생성

정답: B) 외부 인가 서비스(예: OPA)에 인가 결정을 위임

CUSTOM action은 spec.provider.name에 지정된 외부 인가 제공자에게 인가 결정을 위임합니다. OPA(Open Policy Agent), OAuth2 Proxy 등을 외부 인가 서비스로 사용할 수 있습니다.

• A) 항상 거부
• B) 항상 허용
• C) 요청을 수락하지만 인증되지 않은 것으로 처리
• D) 500 에러 반환

정답: C) 요청을 수락하지만 인증되지 않은 것으로 처리

RequestAuthentication은 JWT가 있으면 유효성을 검증하고, 유효하지 않으면 거부합니다. 하지만 JWT가 없는 요청은 수락하되 인증되지 않은 것으로 처리합니다. JWT가 없는 요청도 거부하려면 AuthorizationPolicy를 함께 사용해야 합니다.

• A) Pilot
• B) Galley
• C) istiod (Citadel 기능)
• D) Envoy

정답: C) istiod (Citadel 기능)

istiod에 통합된 Citadel 기능이 워크로드 인증서를 발급합니다. istio-agent(파드 내)가 CSR을 생성하고 istiod에 전송하면, istiod가 서명하여 인증서를 반환합니다. SDS(Secret Discovery Service)를 통해 Envoy에 전달됩니다.

• A) request.headers[x-custom-header]
• B) source.ip
• C) request.auth.claims[groups]
• D) destination.labels[app]

정답: D) destination.labels[app]

when 조건의 key로 request.headers, source.ip, source.namespace, request.auth.claims, request.auth.presenter 등을 사용할 수 있습니다. destination.labels는 지원되지 않으며, 대상 워크로드 선택은 selector를 사용합니다.

• A) spiffe://cluster.local/httpbin/default
• B) spiffe://cluster.local/ns/default/sa/httpbin
• C) cluster.local/default/httpbin
• D) spiffe://default/sa/httpbin

정답: B) spiffe://cluster.local/ns/default/sa/httpbin

SPIFFE ID 형식은 spiffe://TRUST_DOMAIN/ns/NAMESPACE/sa/SERVICE_ACCOUNT입니다. trust domain이 cluster.local이고, 네임스페이스가 default, ServiceAccount가 httpbin이면 위와 같습니다.

• A) istio_requests_total
• B) istio_request_duration_milliseconds
• C) istio_tcp_sent_bytes_total
• D) istio_request_messages_total

정답: D) istio_request_messages_total

Istio는 기본적으로 istio_requests_total(요청 수), istio_request_duration_milliseconds(요청 지연), istio_request_bytes(요청 크기), istio_response_bytes(응답 크기), istio_tcp_sent_bytes_total, istio_tcp_received_bytes_total 등을 생성합니다.

• A) 서비스 메시 토폴로지 그래프 시각화
• B) Istio 구성 검증
• C) 자동 카나리 배포 실행
• D) 워크로드 건강 상태 모니터링

정답: C) 자동 카나리 배포 실행

Kiali는 서비스 메시의 시각화, 구성 검증, 건강 상태 모니터링, 트래픽 흐름 확인 도구입니다. 카나리 배포 자동화는 Flagger 같은 프로그레시브 딜리버리 도구의 역할입니다. Kiali에서 트래픽 분할을 시각적으로 확인할 수는 있습니다.

• A) X-Request-ID만
• B) B3 헤더와 W3C TraceContext
• C) OpenTelemetry 헤더만
• D) 커스텀 Istio 헤더

정답: B) B3 헤더와 W3C TraceContext

Istio는 B3 헤더(x-b3-traceid, x-b3-spanid, x-b3-parentspanid, x-b3-sampled)와 W3C TraceContext(traceparent, tracestate)를 지원합니다. 애플리케이션은 이 헤더들을 전파해야 end-to-end 트레이싱이 가능합니다.

• A) 0.1% (1000분의 1)
• B) 1% (100분의 1)
• C) 10% (10분의 1)
• D) 100% (모든 요청)

정답: B) 1% (100분의 1)

Istio의 기본 트레이스 샘플링 비율은 1%입니다. 이는 MeshConfig의 defaultConfig.tracing.sampling으로 조정할 수 있습니다. 프로덕션에서는 낮은 비율을, 디버깅 시에는 높은 비율을 사용합니다.

• A) spec.metrics[].providers[].name을 "none"으로 설정
• B) spec.metrics[].disabled: true
• C) spec.metrics[].overrides[].disabled: true
• D) spec.metrics: [] 빈 배열로 설정

정답: C) spec.metrics[].overrides[].disabled: true

Telemetry API에서 spec.metrics[].overrides[]를 사용하여 특정 메트릭을 비활성화하거나 태그를 추가/제거할 수 있습니다. match 조건으로 특정 메트릭만 선택적으로 비활성화할 수 있습니다.

• A) MeshConfig의 accessLogFile 설정
• B) Telemetry API의 accessLogging 설정
• C) EnvoyFilter로 액세스 로그 필터 추가
• D) 위 모두 가능

정답: D) 위 모두 가능

Envoy 액세스 로그는 MeshConfig의 accessLogFile("/dev/stdout"), Telemetry API의 accessLogging, 또는 EnvoyFilter로 활성화할 수 있습니다. Telemetry API가 가장 권장되는 방법입니다.

• A) response_code
• B) source_workload
• C) destination_service
• D) request_path

정답: D) request_path

istio_requests_total에는 response_code, source_workload, source_workload_namespace, destination_service, destination_workload, request_protocol, connection_security_policy 등이 포함됩니다. request_path는 기본 라벨이 아니며, 카디널리티가 높아 기본적으로 제외됩니다.

• A) 각 요청에 대해 새로운 스팬을 생성
• B) 인바운드 요청의 트레이스 헤더를 아웃바운드 요청에 전파
• C) 트레이스 데이터를 직접 수집 시스템에 전송
• D) Envoy 프록시에 트레이스 완료를 알림

정답: B) 인바운드 요청의 트레이스 헤더를 아웃바운드 요청에 전파

Istio/Envoy는 자동으로 스팬을 생성하지만, 트레이스 컨텍스트가 연결되려면 애플리케이션이 인바운드 요청의 트레이스 헤더(B3, W3C TraceContext 등)를 아웃바운드 요청에 전파해야 합니다.

• A) L7 트래픽 처리 및 라우팅
• B) 노드 수준의 L4 프록시, mTLS 및 L4 인가 처리
• C) Istio 컨트롤 플레인 컴포넌트
• D) 인증서 발급 및 관리

정답: B) 노드 수준의 L4 프록시, mTLS 및 L4 인가 처리

ztunnel(Zero Trust Tunnel)은 각 노드에 DaemonSet으로 배포되는 L4 프록시입니다. mTLS 암호화/복호화, L4 인가, HBONE 터널링을 처리합니다. L7 기능은 waypoint proxy가 담당합니다.

• A) 파드마다 하나씩
• B) 노드마다 하나씩
• C) 네임스페이스마다 (또는 서비스 계정마다)
• D) 클러스터에 하나만

정답: C) 네임스페이스마다 (또는 서비스 계정마다)

waypoint proxy는 네임스페이스 또는 서비스 계정 단위로 배포됩니다. Kubernetes Gateway API를 사용하여 생성하며, L7 트래픽 관리, L7 인가 정책 등을 처리합니다.

• A) 파드에 sidecar.istio.io/inject: "true" 어노테이션 추가
• B) 네임스페이스에 istio.io/dataplane-mode: ambient 라벨 추가
• C) IstioOperator에서 ambient 프로필 선택
• D) 파드에 ambient-mesh: enabled 라벨 추가

정답: B) 네임스페이스에 istio.io/dataplane-mode: ambient 라벨 추가

네임스페이스에 istio.io/dataplane-mode=ambient 라벨을 추가하면 해당 네임스페이스의 워크로드가 Ambient Mesh에 등록됩니다. 이 방식은 사이드카 주입 없이 메시 기능을 활성화합니다.

• A) gRPC 기반 터널링 프로토콜
• B) HTTP/2 CONNECT 기반 터널링으로 mTLS 트래픽 전달
• C) UDP 기반의 경량 터널링
• D) IPsec 기반 네트워크 암호화

정답: B) HTTP/2 CONNECT 기반 터널링으로 mTLS 트래픽 전달

HBONE은 HTTP/2 CONNECT를 사용하여 포트 15008에서 mTLS 터널을 생성합니다. ztunnel 간 또는 ztunnel과 waypoint proxy 간 통신에 사용되며, 기존 네트워크 인프라와 호환됩니다.

• A) 두 클러스터 모두 독립적인 컨트롤 플레인을 실행
• B) 하나의 클러스터가 컨트롤 플레인을 호스팅하고 다른 클러스터는 원격으로 연결
• C) 외부 컨트롤 플레인을 사용
• D) 각 클러스터가 서로 다른 Istio 버전을 실행

정답: B) 하나의 클러스터가 컨트롤 플레인을 호스팅하고 다른 클러스터는 원격으로 연결

primary-remote 모델에서 primary 클러스터는 istiod를 실행하고, remote 클러스터는 primary의 istiod에 연결하여 구성을 받습니다. primary-primary 모델에서는 양쪽 모두 istiod를 실행합니다.

• A) Envoy 프록시에 WebAssembly 확장을 배포
• B) 워크로드를 WebAssembly 런타임에서 실행
• C) Istio 컨트롤 플레인의 플러그인 관리
• D) 서비스 메시의 자동 스케일링

정답: A) Envoy 프록시에 WebAssembly 확장을 배포

WasmPlugin은 Envoy 프록시에 WebAssembly 모듈을 배포하여 커스텀 로직을 추가합니다. 인증, 변환, 메트릭 수집 등 다양한 기능을 확장할 수 있으며, EnvoyFilter보다 안전하고 관리하기 쉽습니다.

• A) 모든 외부 트래픽이 허용됨
• B) ServiceEntry에 등록된 외부 서비스만 접근 가능
• C) 외부 트래픽이 Egress Gateway를 통해서만 나감
• D) DNS 기반 외부 서비스만 허용

정답: B) ServiceEntry에 등록된 외부 서비스만 접근 가능

REGISTRY_ONLY 모드에서는 Istio 서비스 레지스트리에 등록된 서비스만 접근할 수 있습니다. 등록되지 않은 외부 서비스로의 요청은 502 에러를 반환합니다. ALLOW_ANY(기본값)는 모든 외부 트래픽을 허용합니다.

• A) istioctl uninstall --revision old
• B) istioctl x uninstall --revision old
• C) istioctl install --set revision=old --purge
• D) kubectl delete istiooperator old -n istio-system

정답: A) istioctl uninstall --revision old

이전 revision의 컨트롤 플레인을 제거하려면 istioctl uninstall --revision OLD_REVISION을 사용합니다. 모든 워크로드가 새 revision으로 마이그레이션된 후에 실행해야 합니다. --purge 플래그는 모든 Istio 리소스를 제거할 때 사용합니다.