소개
ICA(Istio Certified Associate) 시험은 Istio 서비스 메시의 핵심 개념과 실전 활용 능력을 검증하는 자격증입니다. 이 글에서는 시험 도메인별 80문제를 통해 실전 대비를 할 수 있도록 구성했습니다.
시험 도메인 구성
| 도메인 | 비중 | 문제 수 |
| ---------------------------------- | ---- | ------- |
| Istio Installation & Configuration | 10% | 8 |
| Traffic Management | 40% | 32 |
| Resilience & Fault Injection | 10% | 8 |
| Securing Workloads | 20% | 16 |
| Observability | 10% | 8 |
| Advanced Topics | 10% | 8 |
1. Istio Installation & Configuration (문제 1-8)
- 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으로 확인해야 합니다.
2. Traffic Management (문제 9-40)
- 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 규칙은 정의된 순서대로 평가되며, 첫 번째로 매칭되는 규칙이 적용됩니다. 따라서 더 구체적인 규칙을 먼저 배치해야 합니다.
3. Resilience & Fault Injection (문제 41-48)
- 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를 비활성화하는 효과가 있습니다.
4. Securing Workloads (문제 49-64)
- 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이면 위와 같습니다.
5. Observability (문제 65-72)
- 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 등)를 아웃바운드 요청에 전파해야 합니다.
6. Advanced Topics (문제 73-80)
- 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 리소스를 제거할 때 사용합니다.
마무리
80문제를 모두 풀어보셨다면, 아래 도메인별로 자신의 약점을 파악해보세요:
| 도메인 | 문제 범위 | 맞힌 수 |
| ---------------------------- | --------- | ------- |
| Installation & Configuration | 1-8 | /8 |
| Traffic Management | 9-40 | /32 |
| Resilience & Fault Injection | 41-48 | /8 |
| Securing Workloads | 49-64 | /16 |
| Observability | 65-72 | /8 |
| Advanced Topics | 73-80 | /8 |
| **합계** | **1-80** | **/80** |
ICA 시험에서는 특히 **Traffic Management**(40%)와 **Securing Workloads**(20%)의 비중이 높으므로, 이 영역의 문제를 반복적으로 학습하시기 바랍니다.
현재 단락 (1/500)
ICA(Istio Certified Associate) 시험은 Istio 서비스 메시의 핵심 개념과 실전 활용 능력을 검증하는 자격증입니다. 이 글에서는 시험 도메인별 80문제를 ...