I85PREP
⌘ K
Istio Certified Associate study materials
Istio Certified Associate study resources

Istio Certified Associate practice questions

One question at a time. Build your Istio Certified Associate understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Installation, Upgrade & Configuration

Which command installs Istio into a Kubernetes cluster using the official Helm charts in the recommended multi-chart layout?

  1. helm install istio-base istio/base -n istio-system --create-namespace, then helm install istiod istio/istiod -n istio-system Correct answer.
  2. kubectl apply -f install/kubernetes/istio-demo.yaml
  3. istioctl install --set profile=demo
  4. helm install istio istio/istio-operator

Explanation

The supported Helm installation splits components into separate charts: istio/base installs the cluster-wide CRDs and roles, and istio/istiod installs the control plane. Both must target the same namespace, typically istio-system, created with --create-namespace on the first release. A single monolithic chart or operator chart is not the documented pattern for current releases.

Question 2Installation, Upgrade & Configuration

An operator wants the smallest Istio installation that provides only the control plane and the ingress gateway, without demo addons. Which istioctl profile should be used?

  1. empty
  2. minimal
  3. demo
  4. default Correct answer.

Explanation

The default profile installs istiod and the ingress gateway, which matches the requirement of control plane plus ingress with no addons. The minimal profile installs only istiod and no gateways, while demo adds telemetry and tracing components for evaluation. The empty profile installs nothing unless components are enabled explicitly.

Question 3Installation, Upgrade & Configuration

Which resource is the primary, cluster-scoped configuration object used by the Istio control plane to define mesh-wide behavior in current releases?

  1. MeshConfig, delivered through the istio ConfigMap in the control plane namespace Correct answer.
  2. ServiceMeshConfig
  3. IstioOperator
  4. MeshPolicy

Explanation

Mesh-wide settings such as access logging, default protocol detection, and trust domain live in the MeshConfig, which is stored in the istio ConfigMap in the control plane namespace. IstioOperator describes an installation, not runtime mesh behavior. MeshPolicy was a legacy authentication policy resource removed in earlier releases.

Question 4Installation, Upgrade & Configuration

A platform team wants to install Istio with a custom configuration file that pins the revision name and disables the egress gateway. Which istioctl invocation applies that file?

  1. istioctl manifest generate -f custom-config.yaml
  2. istioctl analyze -f custom-config.yaml
  3. istioctl install -f custom-config.yaml Correct answer.
  4. istioctl profile dump custom-config.yaml

Explanation

istioctl install with the -f flag reads an IstioOperator configuration file and applies it to the cluster, allowing overrides such as revision and component enablement. manifest generate only renders YAML without applying it, and profile dump prints a built-in profile rather than installing.

Question 5Installation, Upgrade & Configuration

What is the purpose of installing Istio with a revision label such as --set revision=canary?

  1. It restricts the control plane to the canary namespace only.
  2. It forces all sidecars to use the canary image regardless of namespace labels.
  3. It marks the installation as non-production and disables telemetry collection.
  4. It enables canary upgrades by running a second control plane that workloads opt into via the istio.io/rev label. Correct answer.

Explanation

Revision-based installation runs multiple control plane instances side by side, each identified by a revision. Workloads and namespaces select a revision with the istio.io/rev label, which enables canary and in-place upgrades without disrupting existing proxies. The revision name does not restrict namespaces or disable telemetry.

Question 6Installation, Upgrade & Configuration

During a canary upgrade from revision 1-18-0 to 1-19-0, which step moves existing workloads onto the new control plane in an in-place manner?

  1. Delete the old control plane first, then restart all pods.
  2. Apply a DestinationRule that points the sidecars at the new control plane.
  3. Run istioctl upgrade --force to rewrite all existing sidecar versions in place.
  4. Change the istio-injection label on the namespace to match the new revision and restart the pods so new sidecars are injected. Correct answer.

Explanation

Migrating workloads to a new revision is done by relabeling the namespace or pods with istio.io/rev set to the new revision and restarting the workloads so injection uses the new control plane. The old control plane stays running until all workloads have moved, which is what makes the canary upgrade safe. Sidecar versions are not rewritten in place by a single command.

Question 7Installation, Upgrade & Configuration

Which label on a namespace enables automatic sidecar injection for the default (non-revisioned) Istio installation?

  1. istio.io/inject=enabled
  2. istio-injection=enabled Correct answer.
  3. istio.io/rev=default
  4. sidecar.istio.io/inject=true

Explanation

For a default installation, the namespace label istio-injection=enabled causes the mutating webhook to inject sidecars into new pods. Revision-based installations instead use istio.io/rev with the revision name. The inject annotations on pods use sidecar.istio.io/inject, which is different from the namespace label.

Question 8Installation, Upgrade & Configuration

A pod in an injected namespace must remain without a sidecar. Which pod-level annotation achieves that?

  1. istio-injection: disabled
  2. sidecar.istio.io/status: disabled
  3. istio.io/rev: none
  4. sidecar.istio.io/inject: "false" Correct answer.

Explanation

The pod annotation sidecar.istio.io/inject set to the string "false" tells the injection webhook to skip that pod even when the namespace is labeled for injection. Values must be quoted strings because unquoted booleans are treated as YAML booleans and can be misinterpreted. The other keys are not recognized injection controls.

Question 9Installation, Upgrade & Configuration

Which istioctl command checks whether an installed Istio version can be upgraded to a newer supported version and reports version compatibility?

  1. istioctl x precheck Correct answer.
  2. istioctl proxy-status
  3. istioctl analyze
  4. istioctl verify-install

Explanation

istioctl x precheck runs pre-upgrade compatibility checks against the cluster, flagging issues that would block an upgrade such as unsupported versions or deprecated resources. analyze validates configuration, proxy-status reports proxy sync state, and verify-install confirms an installation matches its manifest.

Question 10Installation, Upgrade & Configuration

What does istioctl verify-install do after an installation?

  1. It validates that all VirtualService and Gateway resources conform to the schema.
  2. It checks that every pod has an Envoy sidecar and reports missing injections.
  3. It compares the deployed resources against a generated manifest for the installation and reports discrepancies. Correct answer.
  4. It confirms that the control plane can reach the Kubernetes API server.

Explanation

verify-install regenerates the manifest for the configured installation and compares it with what is deployed, reporting whether resources are present and matching. It focuses on installation completeness rather than traffic configuration or API connectivity. It can also run with a manifest file to compare against an expected state.

Question 11Installation, Upgrade & Configuration

Which IstioOperator field disables the egress gateway component during installation?

  1. spec.components.egressGateways[0].enabled: false Correct answer.
  2. spec.meshConfig.egressGateway.enabled: false
  3. spec.profile: minimal
  4. spec.values.gateways.istio-egressgateway.enabled: false

Explanation

The IstioOperator components section lists gateway components, and the egress gateway entry can be disabled by setting its enabled field to false. This is the documented way to omit the egress gateway from an installation. The other fields are not valid component toggles for the egress gateway.

Question 12Installation, Upgrade & Configuration

Which command removes an Istio installation created by istioctl while preserving the CRDs?

  1. istioctl uninstall --purge
  2. helm uninstall istiod
  3. kubectl delete namespace istio-system
  4. istioctl uninstall Correct answer.

Explanation

istioctl uninstall removes the Istio components but leaves the custom resource definitions in place, which is useful when preparing a fresh reinstall. The --purge flag additionally deletes the CRDs and all Istio custom resources, which is destructive. Deleting the namespace alone does not clean up cluster-scoped resources.

Question 13Installation, Upgrade & Configuration

An operator needs to change a MeshConfig setting such as accessLogFile on a running istioctl-based installation. What is the supported approach?

  1. Edit the istio ConfigMap directly with kubectl edit and restart istiod.
  2. Delete the istiod pod so it regenerates configuration from defaults.
  3. Patch the istiod Deployment environment variables.
  4. Apply an IstioOperator override with istioctl install -f and let the installer reconcile the change. Correct answer.

Explanation

The supported way to change mesh settings on an istioctl-managed installation is to supply an IstioOperator override file and rerun istioctl install, which reconciles the ConfigMap and restarts components as needed. Directly editing the ConfigMap bypasses the installer and can be overwritten on the next reconciliation. Patching the Deployment is not a supported configuration path.

Question 14Installation, Upgrade & Configuration

What is the recommended order when upgrading an Istio installation in place with istioctl?

  1. Upgrade the ingress gateway before the control plane.
  2. Upgrade the control plane first, then update sidecars by restarting workloads. Correct answer.
  3. Delete the old control plane, install the new one, then restart workloads.
  4. Restart all workloads first, then upgrade the control plane.

Explanation

The control plane is upgraded first so it can serve the newer configuration, and then workloads are restarted to pick up new sidecar versions. This ordering keeps the data plane compatible throughout the upgrade. Restarting workloads before the control plane upgrade can leave new sidecars talking to an older control plane.

Question 15Installation, Upgrade & Configuration

Which istioctl command lists the sidecar injection status and Istio version for each pod in a namespace?

  1. istioctl proxy-status
  2. istioctl experimental describe pod Correct answer.
  3. istioctl proxy-config cluster
  4. istioctl analyze

Explanation

istioctl experimental describe pod reports details about a pod's sidecar, including injection status, the control plane it connects to, and relevant configuration. It is useful for confirming that a workload is actually part of the mesh. proxy-status and proxy-config operate on Envoy configuration rather than reporting injection status.

Question 16Installation, Upgrade & Configuration

A namespace labeled istio-injection=enabled contains pods that were created before the label was added. Why do those pods lack sidecars?

  1. Injection only occurs when pods are created, so existing pods must be recreated to receive sidecars. Correct answer.
  2. The label must be applied to each pod individually.
  3. Pods created before labeling are permanently excluded by the webhook.
  4. The sidecar injector requires a pod restart annotation to function.

Explanation

Sidecar injection is performed by a mutating admission webhook at pod creation time, so pods that already exist are unaffected by a later namespace label change. Recreating the pods, for example with kubectl rollout restart on their controller, causes them to be admitted again and injected. The label is read from the namespace at admission time, not stored per pod.

Question 17Installation, Upgrade & Configuration

Which IstioOperator setting is used to pin the control plane to a specific Istio release tag when generating manifests?

  1. spec.version
  2. spec.hub
  3. spec.meshConfig.version
  4. spec.tag Correct answer.

Explanation

The tag field in the IstioOperator spec pins the image tag used for the components, which is how a specific release is selected when rendering manifests. The hub field selects the image registry, not the version. There is no spec.version field for this purpose in the IstioOperator schema.

Question 18Installation, Upgrade & Configuration

Which component must be present for the Istio mutating webhook to inject sidecars into pods?

  1. The istiod control plane, which serves the sidecar injector webhook Correct answer.
  2. The Kiali addon
  3. The egress gateway
  4. The Istio CNI plugin only

Explanation

The sidecar injection webhook is served by istiod, so the control plane must be running and its webhook configuration must be registered for injection to occur. The Istio CNI plugin can handle network setup for pods, but it does not perform injection. Gateways and addons are unrelated to the admission webhook.

Question 19Installation, Upgrade & Configuration

What does the istioctl analyze command do when run against a live cluster?

  1. It checks Istio configuration resources for common errors and reports them with suggested fixes. Correct answer.
  2. It renders the installation manifests for review.
  3. It verifies that all sidecars are running the latest image version.
  4. It upgrades the control plane to the newest available release.

Explanation

analyze inspects Istio resources in the cluster and flags misconfigurations such as references to missing services or conflicting gateways, often with suggested remediations. It does not render manifests, check image versions, or perform upgrades. It can also analyze files offline.

Question 20Installation, Upgrade & Configuration

A team installs Istio using Helm and later wants to change a value in the istiod chart. Which action is consistent with the Helm workflow?

  1. Edit the istiod Deployment directly and rely on Helm to preserve it.
  2. Run istioctl install to overwrite the Helm release.
  3. Run helm upgrade with the new values against the existing release. Correct answer.
  4. Delete the release and reinstall without preserving values.

Explanation

In a Helm-managed installation, configuration changes are applied through helm upgrade with updated values so the release state stays consistent. Mixing in istioctl install can create resources not tracked by Helm and cause conflicts. Direct edits to Deployments are overwritten on the next Helm operation.

Question 21Installation, Upgrade & Configuration

Which label key selects a revisioned control plane for a namespace?

  1. istio.io/rev Correct answer.
  2. istio.io/tag
  3. sidecar.istio.io/rev
  4. istio-injection

Explanation

Namespaces and pods select a revisioned control plane with the istio.io/rev label set to the revision name. The istio-injection label is used for the default, non-revisioned installation. The other keys are not recognized selectors for revisioned injection.

Question 22Installation, Upgrade & Configuration

What is the effect of setting the global.proxy.autoInject value to disabled in the installation configuration?

  1. It forces every namespace to require the istio-injection label.
  2. It disables automatic injection globally while still allowing per-pod opt-in annotations. Correct answer.
  3. It prevents the webhook from being registered at all.
  4. It removes all existing sidecars from running pods.

Explanation

The autoInject setting controls the default injection policy of the webhook; setting it to disabled means namespaces are not injected by default, but pods can still opt in with the inject annotation. It does not unregister the webhook or remove sidecars from running pods. Existing pods are unaffected until recreated.

Question 23Installation, Upgrade & Configuration

Which command displays the Istio configuration profile that would be used for an installation without applying it?

  1. istioctl verify-install
  2. istioctl profile dump default Correct answer.
  3. istioctl manifest generate
  4. istioctl install --dry-run

Explanation

istioctl profile dump prints the contents of a named profile, letting an operator inspect the default settings before customizing them. manifest generate renders the full Kubernetes manifests rather than the profile values. install --dry-run also renders manifests and does not print the profile itself.

Question 24Installation, Upgrade & Configuration

After installing Istio, an operator notices that the istio-ingressgateway Service has no external IP. Which configuration area is most relevant to investigate first?

  1. The MeshConfig accessLogFile setting
  2. The sidecar injector webhook policy
  3. The service type and any cloud load balancer annotations on the ingress gateway Service Correct answer.
  4. The IstioOperator components section for the ingress gateway

Explanation

The ingress gateway Service type determines how an external address is allocated; a ClusterIP or NodePort service will not receive an external IP, and cloud providers may need load balancer annotations. The gateway component itself is installed, so the issue is in service exposure rather than installation. MeshConfig and injection policy do not affect Service address allocation.

Question 25Installation, Upgrade & Configuration

Which statement correctly describes the relationship between istioctl and the IstioOperator resource during installation?

  1. istioctl reads the IstioOperator configuration and reconciles the cluster to match it. Correct answer.
  2. The IstioOperator resource is a runtime CRD that the control plane watches continuously.
  3. The IstioOperator resource replaces the need for a control plane deployment.
  4. istioctl requires a running IstioOperator controller to perform an installation.

Explanation

The IstioOperator is an input configuration consumed by istioctl, which generates and applies the corresponding resources to the cluster. It is not a continuously watched runtime resource in the standard installation flow, and no separate controller is required. It describes the installation, not the data plane itself.

Question 26Installation, Upgrade & Configuration

An operator installs Istio with istioctl using the default profile and wants to confirm which configuration profile values were actually applied to the cluster. Which approach reflects how istioctl-based installations store their configuration state?

  1. Inspect the istiod Deployment's pod template annotations, which embed the full profile YAML
  2. Read the IstioOperator CR named installed-state in the istio-system namespace, which istioctl writes to record the applied configuration Correct answer.
  3. Run istioctl proxy-config bootstrap against istiod to dump the applied Helm values
  4. Query the istio-system ConfigMap named istio, which stores the merged profile values

Explanation

istioctl install records the merged configuration in an IstioOperator resource named installed-state in the istio-system namespace, so later upgrades and manifest generation can reuse it. This is why operators can re-run istioctl install or istioctl upgrade without re-specifying every flag. The other locations hold runtime or proxy-level data, not the installation inputs.

Question 27Installation, Upgrade & Configuration

A platform team wants to install Istio with no ingress or egress gateways because gateways are managed by a separate team in a different namespace. Which istioctl invocation disables both gateway components and nothing else?

  1. istioctl install --set meshConfig.enableAutoMtls=false
  2. istioctl install --set profile=minimal
  3. istioctl install --set values.gateways.enabled=false
  4. istioctl install --set components.ingressGateways=[] --set components.egressGateways=[] Correct answer.

Explanation

The IstioOperator components field lists gateway instances, so assigning empty arrays to components.ingressGateways and components.egressGateways removes both while leaving istiod and other settings intact. The minimal profile also removes gateways but additionally trims other defaults such as the remote pilot settings, so it is broader than requested. Disabling gateways through values keys or toggling mTLS does not remove the gateway Deployments.

Question 28Installation, Upgrade & Configuration

An operator runs istioctl install with a custom IstioOperator file that sets meshConfig.accessLogFile to /dev/stdout, but the change does not appear in the proxies. Which explanation best accounts for this?

  1. The accessLogFile setting only takes effect when the sidecar injector is disabled
  2. Access logging requires enabling the telemetry addon before any meshConfig change takes effect
  3. meshConfig values are applied by istiod dynamically, so proxies must be restarted to pick up the new logging configuration Correct answer.
  4. The IstioOperator meshConfig field is ignored at install time and must be set with istioctl proxy-config

Explanation

meshConfig is delivered to sidecars through istiod's bootstrap configuration, so existing proxies keep their old bootstrap until they are restarted or recreated. Newly created pods pick up the change immediately. This is why operators typically roll workloads after changing mesh-wide proxy settings.

Question 29Installation, Upgrade & Configuration

Which IstioOperator field is used to install a control plane whose revision is named canary-2 so that it can run alongside an existing control plane?

  1. spec.profile
  2. spec.tag
  3. spec.revision Correct answer.
  4. spec.version

Explanation

The revision field sets the istio.io/rev value that namespaces use to select this control plane, enabling multiple control planes to coexist. It also becomes part of resource names such as istiod-canary-2. version and tag control which image release is used, while profile selects a preset of defaults.

Question 30Installation, Upgrade & Configuration

A cluster administrator must install Istio in a cluster where the default profile's istio-egressgateway would conflict with an existing Service named istio-egressgateway in another namespace. Which installation approach avoids deploying that gateway at all?

  1. Install with --set values.global.istioNamespace=other-namespace
  2. Install with an IstioOperator overlay that sets components.egressGateways to an empty list Correct answer.
  3. Install with --set meshConfig.defaultConfig.gatewayTopology.numTrustedProxies=0
  4. Install with the demo profile, which omits gateways

Explanation

Gateway workloads are declared through the components list in IstioOperator, so an overlay that empties components.egressGateways prevents the egress gateway from being created. Changing the control plane namespace or unrelated mesh defaults does not remove the conflicting Service. The demo profile actually includes gateways.

Question 31Installation, Upgrade & Configuration

Which command shows the default configuration profile values that istioctl would use for an installation, without contacting or modifying a cluster?

  1. istioctl manifest generate --dry-run
  2. istioctl experimental describe pod istiod
  3. istioctl profile dump default Correct answer.
  4. istioctl analyze --all-namespaces

Explanation

istioctl profile dump prints the contents of a named profile, which is the preset configuration istioctl merges before installation. It is a local operation and does not require cluster access. manifest generate renders full manifests but is aimed at producing YAML to apply, and analyze and describe inspect live resources.

Question 32Installation, Upgrade & Configuration

An operator wants to confirm that a freshly installed Istio control plane is healthy and that all expected components exist in the cluster. Which istioctl command is designed for this post-install check?

  1. istioctl verify-install Correct answer.
  2. istioctl manifest generate
  3. istioctl proxy-status
  4. istioctl analyze

Explanation

verify-install compares the cluster against the expected installation manifests and reports whether each component is present and healthy. It can also be pointed at a manifest file to validate a planned installation. analyze focuses on configuration issues in workloads, and proxy-status reports xDS sync state for connected proxies.

Question 33Installation, Upgrade & Configuration

A team installs Istio using Helm charts and later needs to change a mesh-wide setting in the istiod chart values. Which action is consistent with a Helm-managed installation?

  1. Delete the istiod Deployment and let the operator recreate it with new defaults
  2. Run helm upgrade with the updated values against the same release and namespace Correct answer.
  3. Run istioctl install --set meshConfig.accessLogFile=/dev/stdout, which updates the Helm release in place
  4. Edit the istio ConfigMap directly and restart istiod, since Helm will not detect drift

Explanation

Helm-managed installations should be modified through helm upgrade so the release state and rendered manifests stay consistent. Mixing in istioctl install creates a second source of truth and can conflict with Helm's ownership. Manually editing resources or deleting workloads bypasses release tracking and is not a supported change path.

Question 34Installation, Upgrade & Configuration

Which statement best describes how istioctl install uses an IstioOperator resource when both a profile and an overlay file are supplied?

  1. Profile defaults are merged first, then the overlay's fields take precedence over them Correct answer.
  2. The profile is applied only if the overlay does not specify a spec.profile field
  3. The overlay file replaces the profile entirely, so only the overlay's fields are applied
  4. The overlay and profile are applied as two separate installations in different namespaces

Explanation

istioctl builds the installation configuration by starting from the selected profile defaults and then merging the user-supplied IstioOperator overlay on top, with overlay values winning. This layering is why an overlay can be small and only list the fields being changed. It does not create separate installations or discard the profile.

Question 35Installation, Upgrade & Configuration

Which IstioOperator setting enables an operator to add a custom environment variable to the istiod container without replacing the rest of the istiod deployment configuration?

  1. spec.components.pilot.k8s.env Correct answer.
  2. spec.values.global.proxy.envoyStatsd.enabled
  3. spec.meshConfig.defaultConfig.proxyMetadata
  4. spec.meshConfig.extensionProviders

Explanation

Kubernetes-level customization for a component is expressed under components.<name>.k8s, and env there appends environment variables to the istiod container. proxyMetadata and envoyStatsd affect sidecar proxies, and extensionProviders configures external integrations such as telemetry backends.

Question 36Installation, Upgrade & Configuration

An operator runs istioctl install with --set values.global.logging.level=debug, then later runs istioctl install again with no flags. What happens to the debug logging setting?

  1. It is converted into a meshConfig field and retained automatically
  2. It persists because the installed-state resource is reused and merged with the new invocation
  3. It persists only if the istiod Deployment is deleted before the second install
  4. It is lost because the second install starts from profile defaults and overwrites the stored configuration Correct answer.

Explanation

A subsequent istioctl install without flags does not automatically reapply earlier --set values; the new configuration is generated from the selected profile and any flags given, and the stored installed-state is replaced. Operators who need to preserve customizations should keep them in an IstioOperator file and pass it with -f. Relying on the previous invocation's flags is not safe.

Question 37Installation, Upgrade & Configuration

A namespace must be enrolled in a specific revision of Istio without using the default injection label. Which label key does the namespace need?

  1. istio.io/rev Correct answer.
  2. sidecar.istio.io/inject
  3. istio-injection
  4. istio.io/tag

Explanation

Namespaces select a revisioned control plane with the istio.io/rev label whose value matches the revision name, such as canary-2. The istio-injection label targets the default, non-revisioned installation, and sidecar.istio.io/inject is a pod-level toggle rather than a revision selector.

Question 38Installation, Upgrade & Configuration

An operator needs to install Istio with the control plane in namespace istio-control and the ingress gateway in namespace ingress-gw. Which configuration accomplishes this?

  1. Set spec.namespace to istio-control and the ingress gateway component's k8s.namespace to ingress-gw Correct answer.
  2. Set spec.namespace to ingress-gw and spec.meshConfig.rootNamespace to istio-control
  3. Set spec.values.global.istioNamespace to ingress-gw and leave spec.namespace unset
  4. Set spec.revision to istio-control and spec.components.ingressGateways[0].k8s.namespace to ingress-gw

Explanation

The top-level namespace field determines where the control plane is installed, while each gateway component can be placed in its own namespace through k8s.namespace. This split is supported because gateway instances are independent components. The revision field names a control plane and does not set its namespace.

Question 39Installation, Upgrade & Configuration

Which statement correctly describes the relationship between the IstioOperator resource and the istioctl manifest generate command?

  1. manifest generate ignores the IstioOperator and renders only the built-in profile
  2. manifest generate applies the IstioOperator to the cluster and then renders it for inspection
  3. manifest generate renders Kubernetes manifests from the IstioOperator and profile without applying them Correct answer.
  4. manifest generate requires a running istiod to convert the IstioOperator into manifests

Explanation

manifest generate performs the same configuration layering as install but outputs the resulting Kubernetes YAML to stdout instead of applying it. This lets teams review or store manifests for GitOps workflows. It is a local rendering operation and does not need a cluster.

Question 40Installation, Upgrade & Configuration

An operator wants to change the default resource requests for the istiod container in an existing istioctl-based installation. Which approach applies the change while keeping the rest of the installation intact?

  1. Create a new IstioOperator file with the pilot container resource settings and run istioctl install -f on it Correct answer.
  2. Patch the istio ConfigMap with the new requests and restart istiod
  3. Edit the istiod Deployment's resource requests directly and scale the Deployment down and up
  4. Run istioctl proxy-config bootstrap on istiod to update its resources

Explanation

Control plane resources are configured through the IstioOperator component settings, so supplying an overlay file with the pilot container resources and running istioctl install applies the change through the supported path. Direct edits to the Deployment are not durable, and the istio ConfigMap does not carry container resource specifications.

Question 41Traffic Management

In Istio, which resource is used to route traffic to a specific subset of pods within a Kubernetes service?

  1. ServiceEntry
  2. Gateway
  3. DestinationRule Correct answer.
  4. VirtualService

Explanation

A DestinationRule defines subsets (groupings of pods by label, such as version) and traffic policies applied after routing decisions are made. VirtualServices route to a host, and the subset is selected via the DestinationRule. This separation lets routing rules reference named subsets like v1 or v2.

Question 42Traffic Management

Which Istio resource attaches to a host and defines how requests are matched and routed, including weighted splits between destinations?

  1. PeerAuthentication
  2. VirtualService Correct answer.
  3. AuthorizationPolicy
  4. Sidecar

Explanation

A VirtualService binds to one or more hosts and contains HTTP, TCP, or TLS route rules that match requests and forward them to destinations, optionally with weights. It is the primary resource for L7 routing decisions such as canary splits and header-based routing.

Question 43Traffic Management

A team wants 90% of traffic to reach the v1 subset and 10% to reach v2 for a canary release. Which configuration element accomplishes this?

  1. A VirtualService route with weighted destinations Correct answer.
  2. A Gateway with two servers
  3. A DestinationRule with a traffic policy
  4. A ServiceEntry with resolution NONE

Explanation

Weighted routing is expressed in a VirtualService HTTP route: each destination lists a host, a subset, and a weight, and the weights across the route should sum to 100. This lets you send a controlled fraction of requests to the canary subset without changing clients.

Question 44Traffic Management

Which Istio resource defines the ports, protocols, hosts, and TLS settings for traffic entering the mesh from outside?

  1. WorkloadEntry
  2. Gateway Correct answer.
  3. EnvoyFilter
  4. VirtualService

Explanation

A Gateway configures a load balancer operating at the edge of the mesh, specifying servers with port, protocol, hosts, and optional TLS. It does not route by itself; a VirtualService must be bound to the gateway to define the actual routing. This split separates listener configuration from routing rules.

Question 45Traffic Management

What is the purpose of a ServiceEntry in Istio traffic management?

  1. To split traffic between two versions of a deployment
  2. To add external or unregistered services to the mesh's service registry Correct answer.
  3. To define subsets of an internal Kubernetes service
  4. To enforce mTLS between sidecars

Explanation

A ServiceEntry adds entries to Istio's internal service registry so that mesh workloads can treat external APIs or legacy services as if they were part of the mesh. It specifies hosts, addresses, ports, and resolution, enabling routing and policy on those external destinations.

Question 46Traffic Management

Which load balancing algorithm is NOT one of the standard options available in an Istio DestinationRule traffic policy?

  1. LEAST_REQUEST
  2. PRIORITY_FAILOVER Correct answer.
  3. RANDOM
  4. ROUND_ROBIN

Explanation

Istio DestinationRule supports load balancer algorithms including ROUND_ROBIN, LEAST_REQUEST, RANDOM, and PASSTHROUGH. Priority-based failover is not an exposed load balancer algorithm in this API; failover behavior is achieved through outlier detection and locality settings instead.

Question 47Traffic Management

A VirtualService HTTP route matches requests with header `x-user: beta` and sends them to subset v2, with a default route to v1. Which match field is used to inspect the header value?

  1. uri
  2. method
  3. queryParams
  4. headers Correct answer.

Explanation

In an HTTPMatchRequest, the headers field is a map of header names to StringMatch conditions, allowing exact, prefix, or regex matching on header values. This is the standard mechanism for header-based routing such as beta-user targeting.

Question 48Traffic Management

In a VirtualService HTTP route, what happens if no match condition is specified on a route entry?

  1. The route is ignored by the proxy
  2. The route only matches requests to the root path
  3. The route matches all requests for the host Correct answer.
  4. The configuration is rejected as invalid

Explanation

A route without a match block acts as a catch-all for the host, matching every request. This is commonly used as the final default route after more specific match-based routes. Order matters, so catch-all routes are typically placed last.

Question 49Traffic Management

Which Istio feature removes unhealthy endpoints from a load balancing pool based on consecutive errors, improving resilience?

  1. Outlier detection Correct answer.
  2. Retry policy
  3. Circuit breaking via connectionPool
  4. Fault injection

Explanation

Outlier detection in a DestinationRule tracks endpoint health and ejects hosts that return consecutive errors for a configured interval. Ejected hosts are periodically re-tested and returned to the pool if healthy. This is distinct from circuit breaking, which limits connections and requests.

Question 50Traffic Management

A DestinationRule sets `maxConnections: 100` and `http1MaxPendingRequests: 10` under connectionPool. What behavior does this configure?

  1. Weighted traffic splitting
  2. Retry attempts for failed requests
  3. Outlier ejection of failing hosts
  4. Circuit breaking limits on connections and queued requests Correct answer.

Explanation

Connection pool settings implement circuit breaking by capping concurrent connections and pending requests to a destination. When limits are exceeded, requests fail fast rather than overwhelming the backend. These limits are enforced by the client sidecar.