ICA Istio Installation Upgrade And Configuration — Timed 15 Questions

Question 1

You are performing a canary upgrade of the Istio control plane using the revision-based approach. After deploying the new revision, how do you verify which pods are currently pointing to the new control plane?

15 minute time limit — choose an answer to begin.

Accepted Answer

kubectl get pods -l istio.io/rev. To verify which pods are pointing to the new Istio control plane revision, you can use kubectl get pods -l istio.io/rev to list pods with the revision label. This label is added to pods that are injected with a specific revision's sidecar. By checking the label value, you can confirm which revision the pods are using.

Answer

istioctl upgrade status

Answer

istioctl proxy-config endpoint

Answer

kubectl describe svc istiod

Question 2

You need to add a custom CA certificate to the Istio control plane during installation. How do you pass this using IstioOperator?

Accepted Answer

spec.values.global.certificates.caCertificates. In IstioOperator, custom CA certificates are configured under spec.values.global.certificates.caCertificates, which accepts a list of PEM-encoded CA certs used by the control plane to sign workload certificates (via Citadel/istiod). This is the documented path for injecting a custom root CA during installation.

Answer

spec.meshConfig.caCertificates

Answer

spec.components.pilot.k8s.env

Answer

spec.security.ca.path

Question 3

You need to configure the IstioOperator CR to disable mTLS globally for a legacy migration. Which field correctly sets the global peer authentication policy?

Accepted Answer

spec.values.global.mtls.enabled: false. In the IstioOperator CR, global mTLS is configured under spec.values.global.mtls.enabled, which maps to the Helm values structure that IstioOperator uses. Setting it to false disables the global peer authentication policy that enforces mTLS mesh-wide. This is the correct field path for the legacy migration scenario.

Answer

spec.components.pilot.mtls: false

Answer

spec.meshConfig.mtls: false

Answer

spec.security.globalMtls: false

Question 4

You are performing an in-place upgrade of Istio. You have updated the control plane, but your data plane proxies are still running the old image. What is the standard process to upgrade the proxies?

Accepted Answer

kubectl rollout restart deployment. In-place Istio upgrades require restarting the data plane workloads so the sidecar injector can inject the new proxy version. The standard method is kubectl rollout restart deployment, which triggers a rolling restart and re-injects the updated sidecar. This is the documented approach in Istio's upgrade guide for refreshing proxies after the control plane is upgraded.

Answer

istioctl upgrade --data-plane

Answer

kubectl patch deployment -p '{"spec":{"template":{"metadata":{"annotations":{"sidecar.istio.io/status":"update"}}}}}'

Answer

istioctl proxy-status --upgrade

Question 5

You want to exclude a specific container in a pod from being injected with the Istio proxy. How is this achieved?

Accepted Answer

Add annotation 'sidecar.istio.io/inject: "false"' to the pod. The correct method to exclude a specific container from Istio sidecar injection is to add the annotation 'sidecar.istio.io/inject: "false"' to the pod. This annotation is read by the Istio mutating webhook, which then skips injection for that pod. It is the standard, documented approach for per-pod exclusion.

Answer

Modify the IstioOperator to exclude the container

Answer

Add label 'sidecar.istio.io/skip'

Answer

Add environment variable 'ISTIO_PROXY_IGNORE=true'

Question 6

You are debugging an Istio installation issue. Which command allows you to view the currently applied IstioOperator configuration in the cluster?

Accepted Answer

kubectl get istiooperator -n istio-system. The IstioOperator configuration is stored as a Kubernetes Custom Resource (CR) of kind IstioOperator, typically named 'installed-state' or 'istio-controlplane' in the istio-system namespace. Using kubectl get istiooperator -n istio-system retrieves the applied configuration directly from the cluster's API server, showing the exact spec that was used during installation. This is the authoritative source for the currently applied manifest, not a local file.

Answer

istioctl manifest get

Answer

helm get values istio

Answer

istioctl config dump

Question 7

Which THREE commands can be used to manage or inspect the Istio mesh configuration?

Accepted Answer

istioctl version. The 'istioctl' tool provides 'analyze', 'proxy-config', and 'version' commands for mesh inspection and management.

Answer

istioctl deploy

Answer

istioctl upgrade

Question 8

Which THREE actions occur when you label a namespace with 'istio-injection=enabled'?

Accepted Answer

New pods created in the namespace are injected with a sidecar. Labeling a namespace with 'istio-injection=enabled' causes Istio's mutating admission webhook to act on that namespace: option B is correct because the sidecar injector's MutatingWebhookConfiguration is configured (via its namespaceSelector) to watch namespaces carrying this label, so the webhook is triggered for matching namespaces. Option D is correct because when a new pod is created in that namespace, the sidecar injector webhook mutates the pod spec to add the istio-proxy (Envoy) container along with its init container and volumes. Option A is correct because the practical result of this injection is that new pods created in the labeled namespace receive the sidecar proxy. Option C is wrong because labeling a namespace does not scale the istiod deployment; istiod scaling is a separate operational action. Option E is wrong because injection only applies to newly created pods, so existing pods are not immediately restarted and must be manually recreated to get the sidecar.

Answer

The istiod deployment is scaled up

Answer

All existing pods are immediately restarted

Question 9

You are installing Istio 1.20 on a cluster with a single Istiod replica. A colleague suggests enabling the `values.pilot.autoscaleEnabled` setting to improve availability during the initial rollout. You need to ensure the control plane can handle a sudden increase in sidecar connections without manual intervention. Which configuration should you apply in your IstioOperator resource?

Accepted Answer

Set `spec.components.pilot.k8s.hpaSpec.minReplicas` to 2 and `maxReplicas` to 5, and enable `autoscaleEnabled`.. The correct configuration directly enables and tunes the Horizontal Pod Autoscaler for the Istiod deployment. By specifying minReplicas and maxReplicas within the pilot component's k8s.hpaSpec, Istiod can automatically scale out when sidecar connections increase, ensuring availability without manual intervention. Other options either affect proxy behavior or set static resources, which do not provide dynamic scaling.

Answer

Set `spec.values.global.proxy.autoInject` to enabled and configure `spec.values.pilot.env.PILOT_AUTO_SCALE` to true.

Answer

Set `spec.meshConfig.defaultConfig.holdApplicationUntilProxyStarts` to true and increase `spec.values.global.proxy.concurrency`.

Answer

Set `spec.values.pilot.resources.requests.cpu` to 4 and `limits.cpu` to 8, and set `replicaCount` to 3.

Question 10

You are installing Istio 1.20 on a Kubernetes cluster using the istioctl command-line tool. You need to enable access logging for all sidecars and send logs to stdout in JSON format. You also want to ensure that the logging configuration is applied mesh-wide. Which istioctl command should you use?

Accepted Answer

istioctl install --set meshConfig.accessLogFile=/dev/stdout --set meshConfig.accessLogEncoding=JSON. Access logging is configured mesh-wide via the 'meshConfig' section. The fields 'accessLogFile' and 'accessLogEncoding' are the correct ones. Setting accessLogFile to '/dev/stdout' and accessLogEncoding to 'JSON' ensures all sidecars log accesses in JSON format to stdout. This is done during installation using istioctl with the appropriate --set flags.

Answer

istioctl install --set meshConfig.defaultConfig.accessLogFile=/dev/stdout --set meshConfig.defaultConfig.accessLogEncoding=JSON

Answer

istioctl install --set meshConfig.enableAccessLog=true --set meshConfig.accessLogFormat=json

Answer

istioctl install --set values.global.proxy.accessLogFile=/dev/stdout --set values.global.proxy.accessLogEncoding=JSON

Question 11

You are installing Istio on a Kubernetes cluster and want to verify that the control plane components are running correctly after installation. Which command should you use to check the status of the Istiod deployment and the Ingress Gateway?

Accepted Answer

`kubectl get pods -n istio-system`. The command `kubectl get pods -n istio-system` lists all pods in the Istio control plane namespace, including Istiod and the Ingress Gateway. It provides a quick overview of their status, readiness, and restart counts, making it the simplest way to verify that the control plane components are running correctly after installation.

Answer

`istioctl proxy-status`

Answer

`istioctl analyze -n istio-system`

Answer

`kubectl describe deployment istiod -n istio-system`

Question 12

You are upgrading Istio from 1.19 to 1.20 using the in-place upgrade method with `istioctl upgrade`. During the pre-upgrade check, you receive a warning that the `IstioOperator` configuration has a deprecated field `spec.values.global.oneNamespace`. What is the correct action to take before proceeding with the upgrade?

Accepted Answer

Remove the `oneNamespace` field from the IstioOperator configuration and re-run the upgrade.. The `oneNamespace` field was removed in Istio 1.20, so you must delete it from your IstioOperator configuration before upgrading. Deprecated fields are not automatically handled and can cause the upgrade to fail. Removing the field and re-running the upgrade ensures compatibility with the new version.

Answer

Replace `oneNamespace` with `spec.meshConfig.oneNamespace` and continue.

Answer

Ignore the warning because deprecated fields are automatically removed during upgrade.

Answer

Set `spec.values.global.oneNamespace` to false and proceed with the upgrade.

Question 13

Which 'istioctl' command is used to verify that the current Istio configuration in a cluster is valid and follows best practices?

Accepted Answer

istioctl analyze. istioctl analyze performs static analysis of the Istio configuration in a cluster (or from files) and reports validation errors, warnings, and best-practice violations, such as misconfigured VirtualServices, missing sidecars, or deprecated fields. It is the canonical command for verifying configuration correctness and adherence to Istio's recommended patterns.

Answer

istioctl check

Answer

istioctl diagnose

Answer

istioctl verify

Question 14

When using IstioOperator to customize the installation, you want to change the number of replicas for the Istiod control plane. Where should this be defined?

Accepted Answer

spec.components.pilot.k8s.replicaCount. The IstioOperator API defines component-level Kubernetes settings under spec.components.<component>.k8s, so the Istiod replica count is set at spec.components.pilot.k8s.replicaCount. This is the canonical location for overriding the pilot (Istiod) Deployment's replica count during installation. The value is merged into the generated Istiod Deployment manifest, allowing you to scale the control plane declaratively via the operator.

Answer

spec.values.pilot.scaling

Answer

spec.meshConfig.pilot.replicas

Answer

spec.pilot.replicas

Question 15

A team wants to enable sidecar injection for a specific namespace without modifying the deployment manifests. What is the most efficient way to achieve this?

Accepted Answer

kubectl label namespace <name> istio-injection=enabled. The most efficient way to enable sidecar injection for a namespace without modifying deployment manifests is to label the namespace with istio-injection=enabled. Istio's mutating webhook checks this label when pods are created and automatically injects the sidecar container. This is a namespace-level configuration that requires no changes to individual workloads.

Answer

istioctl inject -n <namespace>

Answer

kubectl apply -f sidecar-injector.yaml

Answer

kubectl annotate namespace <name> istio-injection=enabled