Istio Certified Associate key terms

A cluster-scoped resource created by the Istio control plane operator that represents one installed version of the mesh; its name (such as default or canary) identifies the revision and lets multiple control planes coexist during canary or in-place upgrades.

A custom resource consumed by istioctl that declares the desired control plane configuration, including components, profiles, resource settings, and mesh options; it is used for declarative installs and updates instead of long command-line flag lists.

A named preset of IstioOperator values shipped with Istio, such as default, demo, minimal, remote, or empty, that turns components on or off; profiles are a starting point that you override rather than edit in place.

The command that applies an IstioOperator configuration to the cluster, creating or updating the istiod control plane and its supporting resources; flags such as --set and -f supply overrides and files.

A label value attached to an istiod deployment and its webhooks so that sidecars and gateways can be bound to a specific control plane instance; it enables side-by-side upgrades and staged migration of workloads.

A stable alias, stored as a mutating webhook tag, that points to a control plane revision; moving the tag to a new revision redirects newly injected pods without changing namespace labels.

An upgrade approach where the existing control plane is replaced by the new version in a single step; it is simpler than canary upgrades but offers no period in which old and new control planes run simultaneously.

An upgrade method that installs a new control plane revision alongside the current one, moves selected workloads to it, verifies behavior, then retires the old revision; it limits blast radius during version changes.

The process that adds an Envoy proxy container to a workload pod, driven by a namespace label or a pod annotation; it is performed by a mutating webhook served by istiod.

A Kubernetes MutatingAdmissionWebhook registered by Istio that intercepts pod creation and rewrites the pod spec to include the proxy; its failurePolicy and namespace selectors determine whether uninjected or blocked pods result.

A sidecar-less data plane architecture in which a per-node ztunnel handles L4 traffic and optional waypoint proxies handle L7 policy; it removes pod restarts from the injection path and reduces per-pod overhead.

The per-pod Envoy proxy that intercepts inbound and outbound traffic for a workload, applying routing, mTLS, and policy; its configuration comes from istiod over the xDS APIs.

A networking.istio.io resource that scopes which services and ports a proxy learns about, reducing configuration size and memory; it can be set per workload or per namespace.

A resource that defines how requests for a host are routed, including match conditions, destination subsets, weights, retries, timeouts, and fault injection; it binds to gateways or to the mesh itself.

A resource that configures traffic policy for a service after routing, covering subsets, load-balancing algorithms, connection pool limits, outlier detection, and TLS origination or mode settings.

A resource that configures a standalone Envoy listener at the edge of the mesh for inbound or outbound traffic, specifying ports, hosts, and TLS; it must be paired with a VirtualService to route requests.

The gateway deployment that accepts traffic from outside the mesh and forwards it to internal services; it is typically exposed through a Kubernetes Service of type LoadBalancer or NodePort.

A named group of pod endpoints within a DestinationRule, selected by labels such as version; VirtualServices route to subsets to implement weighted splits and canary releases.

Splitting requests across destinations by weight, usually between subsets of different versions; weights are relative integers, and a common pattern ramps a new version from a small percentage upward.

A VirtualService route setting that caps how long a request may take before the proxy returns an error; it must be coordinated with application timeouts and retries to avoid cascading failures.

A route-level policy that re-sends failed requests according to attempts, perTryTimeout, and retryOn conditions; retries can amplify load, so they are usually combined with timeouts and circuit breaking.

A DestinationRule feature that ejects endpoints returning consecutive errors from the load-balancing pool for a period, then probes them again; it is Istio's mechanism for circuit breaking at the endpoint level.

DestinationRule limits on TCP connections, pending requests, HTTP requests, and retries per endpoint; exceeding them fails fast rather than queueing indefinitely, which protects upstream services.

A VirtualService capability that delays or aborts a percentage of requests to test resilience; it is used in staging to validate timeouts and retry behavior without changing application code.

An advanced resource that patches Envoy configuration generated by istiod, such as adding HTTP filters or listeners; it is version-sensitive and can break the mesh if the patch is malformed.

A security policy that sets the mutual TLS mode for workloads in a namespace or for a specific selector, with values such as STRICT, PERMISSIVE, DISABLE, and UNSET; mesh-wide defaults live in the root namespace.

A mode in which both client and server present X.509 certificates and verify each other; Istio issues and rotates these identities automatically so service traffic is encrypted and authenticated.

A policy that allows or denies requests based on source identity, namespace, IP, method, path, or JWT claims; when any policy selects a workload, requests must match an ALLOW rule to pass.

A policy that declares how incoming JWTs are validated, including issuer, JWKS location, and audience; it authenticates tokens but does not by itself restrict access.

A signed token carrying claims about a caller, often issued by an identity provider; Istio validates it at the proxy and exposes claims to authorization rules via request.auth attributes.

The URI-form workload identity encoded in Istio-issued certificates, such as spiffe://cluster.local/ns/foo/sa/bar; authorization rules and telemetry use it to identify callers independent of network location.

The certificate authority that signs intermediate certificates for each cluster's istiod; in multi-cluster or multi-mesh deployments all participants must share the same root for mTLS to succeed across clusters.

A command that inspects live or file-based configuration for common errors, such as conflicting routes, missing gateways, or mislabeled namespaces, and reports them with suggested fixes.

A command that retrieves the Envoy configuration actually programmed for a pod, in summary, cluster, listener, route, or bootstrap form; it is the primary tool for verifying that policy reached the proxy.

The output of istioctl proxy-config or the proxy's admin endpoint showing clusters, listeners, routes, and endpoints; comparing it against intended policy reveals whether istiod pushed updates.

The family of discovery APIs, including LDS, RDS, CDS, and EDS, through which istiod pushes listener, route, cluster, and endpoint configuration to Envoy proxies over a streaming connection.

The istioctl proxy-status command output listing each proxy, the control plane it syncs with, and whether it is in sync or stale; it quickly shows which pods have not received the latest configuration.

The istiod container logs, read with kubectl logs, that record push decisions, certificate signing, and webhook errors; increasing log level is a standard first step when debugging mesh behavior.