ICA common mistakes
ICA · Understand the traps and how to avoid them.
Installing Istio with the demo profile in a cluster and then assuming the resulting behaviour (permissive mTLS, prometheus/grafana addons, ingress gateway) is what the exam's production-style scenario expects.
The demo profile bundles permissive mTLS, extra addons and a default ingress gateway, so candidates who install it casually see things 'working' and never learn which settings are actually being applied. They then misread questions about strict mTLS or sidecar injection because the defaults masked the underlying configuration.
What to do instead
Practise installing with istioctl install --set profile=default and separately with a minimal profile, then run istioctl profile diff default demo to see exactly what changes. Before answering any scenario question, state to yourself which profile and which mesh-wide settings (mtls mode, injection policy, mesh ID) are in effect.
Assuming pods in a namespace get sidecars automatically after enabling injection, and not verifying the actual revision label or inject annotation on the workload.
Injection is controlled by the namespace label istio-injection=enabled or istio.io/rev=, and pods created before the label change never get a sidecar. Revision-based installs also fail silently if the namespace label references a revision that does not exist in the cluster.
What to do instead
After labelling, restart the deployment and confirm with kubectl get pod -o jsonpath='{.spec.containers[*].name}' that istio-proxy is present, and check istioctl analyze for injection warnings. When the cluster uses revisions, confirm the label value matches an installed control plane revision via istioctl tag list.
Treating an in-place istioctl upgrade as if it also upgrades the data plane, and answering questions as though new proxy versions are already running.
istioctl upgrade updates the control plane; existing sidecars keep running the old proxy until the workload is restarted or the pod is recreated. Candidates conflate control plane and data plane versions and choose answers that assume the proxies are already on the new version.
What to do instead
Distinguish control plane upgrades (istioctl upgrade or a canary revision install) from data plane upgrades (restart or roll workloads so new sidecars are injected). Verify with istioctl proxy-status and istioctl version, which reports both control plane and data plane versions separately.
Writing a VirtualService route that matches on the wrong host or forgets that the route only applies when the host resolves through the mesh, then blaming the gateway or the proxy for traffic not shifting.
VirtualService hosts must match the host used by the client (service DNS name or gateway host), and a route attached to the wrong gateway or with an unmatched host is silently ignored. Candidates also forget that subset routing requires a matching DestinationRule subset.
What to do instead
Check the host field against the actual request host, confirm the VirtualService is bound to the correct gateway or sidecar scope, and verify that every subset referenced in the route exists in a DestinationRule. Use istioctl proxy-config routes to confirm the route is programmed in Envoy.
Applying a DestinationRule with a trafficPolicy that conflicts with or overrides the VirtualService-level settings, then mispredict timeouts, retries or load balancing.
Traffic policy can be set at the mesh, namespace, DestinationRule and VirtualService level, and more specific scopes override broader ones. Candidates set a timeout in one place and a conflicting value elsewhere, then reason from the wrong effective value.
What to do instead
Learn the precedence order (VirtualService route-level overrides DestinationRule, which overrides mesh defaults) and inspect the effective config with istioctl proxy-config cluster and listener output. When a scenario asks what happens, trace the setting from the most specific object outward.
Configuring a Gateway without a matching VirtualService, or binding the VirtualService to the wrong gateway name/namespace, and expecting external traffic to flow.
The Gateway only opens listeners; routing requires a VirtualService that references the gateway by name and namespace. A common trap is a VirtualService in namespace A referencing a gateway in namespace B without the namespace-qualified name.
What to do instead
Always pair the Gateway with a VirtualService whose gateways field lists the gateway (namespace/name when cross-namespace), and confirm the host matches the request. Validate with istioctl analyze and istioctl proxy-config listener/route on the ingress gateway pod.
Enabling STRICT mTLS mesh-wide without accounting for workloads that have no sidecar or for the ingress gateway, then concluding mTLS is broken when traffic fails.
STRICT mode rejects plaintext from any source, including pods without sidecars and some health probes. Candidates flip the mesh to STRICT to 'secure it' and then see failures they cannot explain, or they misattribute the failure to the application.
What to do instead
Before switching to STRICT, confirm all workloads in scope have sidecars, exclude or adapt non-mesh clients, and use PeerAuthentication at the narrowest scope possible. Test with istioctl authn tls-check and inspect destination rule TLS settings for external services.
Writing AuthorizationPolicy rules that deny more than intended because of how action, rules and empty rule lists interact, and then assuming the policy is not being enforced.
An ALLOW policy with no rules denies everything in its scope, and multiple ALLOW policies are OR-ed while DENY policies take precedence. Candidates write a single narrow ALLOW rule and accidentally lock out all other traffic, or add a DENY and expect an ALLOW to override it.
What to do instead
Remember that DENY is evaluated before ALLOW, ALLOW policies combine with OR, and a policy with an empty rules list matches nothing for ALLOW (deny-all) but is a common source of lockout. Test policies incrementally with a dry-run mindset, and use istioctl x authz check to see the effective policies for a workload.
Diagnosing a 503 from Envoy as a network problem instead of reading the response flags and the proxy config to find the real cause (no healthy upstream, cluster not found, mTLS mismatch).
Envoy returns 503 for many distinct causes, and candidates jump to checking pods and services rather than the proxy's own view. They miss that the endpoint list is empty, the subset does not exist, or the destination is rejecting the TLS handshake.
What to do instead
Start from istioctl proxy-status and the response flags (e.g. UF, NR, UH), then use istioctl proxy-config endpoints and clusters on the source pod to confirm the upstream exists and has healthy endpoints. Check the DestinationRule TLS mode against the destination's actual mTLS mode.
Ignoring istioctl analyze and the istiod logs, and instead changing configuration repeatedly until something appears to work, leaving a broken config behind.
istioctl analyze surfaces exactly the misconfigurations that cause most scenario failures (missing gateway binding, conflicting hosts, invalid subsets), and istiod logs show rejected config. Candidates skip these signals and lose time chasing symptoms.
What to do instead
Make istioctl analyze -A the first diagnostic step, then read istiod logs for config rejection and use istioctl proxy-status to confirm the proxy is synced (SYNCED vs STALE). Revert changes that did not help so the final config remains understandable.