[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ラベルを設定すると、そのネームスペースのすべてのPodに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に2つの宛先を定義
• 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で含めるPodを選択します。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

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モードはクライアント証明書も要求し、PASSHTHROUGHは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（正規表現一致）の3つの方式をサポートします。

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

正解: D) WEIGHTED_RESPONSE_TIME

Istio DestinationRuleはROUND_ROBIN（デフォルト）、LEAST_CONN、RANDOM、PASSHTHROUGHをサポートします。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 Podを選択します。一般的に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接続を終端せずそのままバックエンドに転送

PASSHTHROUGHモードではゲートウェイが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) 優先順位に従って1つだけ評価

正解: C) 同じmatch内の条件はAND、異なるmatchブロックはOR

1つの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) 1秒あたりの最大リトライ回数

正解: 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 x 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) 1秒あたりの最大リクエスト数
• 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) 1つの接続で処理する最大リクエスト数（以降接続終了）
• C) 1秒あたり接続ごとの最大リクエスト数
• D) 同時接続ごとの最大リクエスト数

正解: B) 1つの接続で処理する最大リクエスト数（以降接続終了）

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) ソースPodのネームスペースを基準にフィルタリング
• B) 宛先Podのネームスペースを基準にフィルタリング
• C) サービスレジストリのネームスペースを参照
• D) Kubernetes Namespaceリソースのラベルを確認

正解: A) ソースPodのネームスペースを基準にフィルタリング

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アクションは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（Pod内）が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）をサポートします。エンドツーエンドトレーシングにはアプリケーションがこれらのヘッダーを伝播する必要があります。

• 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) Podごとに1つ
• B) ノードごとに1つ
• C) ネームスペースごと（またはサービスアカウントごと）
• D) クラスターに1つだけ

正解: C) ネームスペースごと（またはサービスアカウントごと）

waypoint proxyはネームスペースまたはサービスアカウント単位でデプロイされます。Kubernetes Gateway APIを使用して作成し、L7トラフィック管理、L7認可ポリシーなどを処理します。

• A) Podにsidecar.istio.io/inject: "true"アノテーションを追加
• B) ネームスペースにistio.io/dataplane-mode: ambientラベルを追加
• C) IstioOperatorでambientプロファイルを選択
• D) Podに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) 1つのクラスターがコントロールプレーンをホスティングし、もう1つはリモートで接続
• C) 外部コントロールプレーンを使用
• D) 各クラスターが異なるIstioバージョンを実行

正解: B) 1つのクラスターがコントロールプレーンをホスティングし、もう1つはリモートで接続

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リソースを削除する際に使用します。