JNCIE-Cloud common mistakes
JNCIE-Cloud · Understand the traps and how to avoid them.
When troubleshooting a broken overlay, the candidate starts by editing VTEP or EVPN configuration instead of first confirming underlay reachability and MTU end to end with ping and traceroute using large packet sizes.
Overlay symptoms such as intermittent flow loss, stuck ARP, or one-way traffic look like control-plane bugs, so candidates jump to the EVPN/VXLAN config. In practice most overlay failures in these labs trace back to an underlay routing gap or an MTU mismatch that silently drops encapsulated frames larger than the reduced payload.
What to do instead
Establish a fixed triage order: verify loopback-to-loopback reachability for every VTEP, confirm the underlay MTU supports the encapsulation overhead, then check the overlay control plane. Use DF-bit pings at the expected encapsulated size to prove MTU before touching overlay config.
The candidate configures a Kubernetes Service with type LoadBalancer or an Ingress and then tests only from inside the cluster, never validating that the external VIP is advertised and reachable from outside the fabric.
In-cluster tests pass because kube-proxy and CoreDNS resolve everything locally. The failure is in the integration layer: the load balancer, BGP advertisement of the service VIP, or the external network path. Candidates who stop at the in-cluster test declare success on a broken deployment.
What to do instead
Always run a two-sided test: a pod-to-pod/service test inside the cluster and a curl from an external host to the advertised VIP. If the external test fails, check the load balancer controller, the VIP advertisement, and the return path separately.
The candidate treats an OpenStack instance's inability to reach the network as a Nova problem and rebuilds or reschedules the instance, rather than tracing the path through Neutron: port binding, security groups, the OVS/OVN flows, and the router namespace.
Nova shows the instance as ACTIVE, so the instinct is that compute is fine or broken. The actual fault is usually a missing security group rule, a port not bound to a host, a stale flow in the virtual switch, or a router namespace that is not forwarding.
What to do instead
Follow the packet path in order: confirm the port is bound and has the expected IP/MAC, check security group and allowed address pairs, inspect the virtual switch flows for the tap interface, then test inside the router namespace. Only consider Nova after the Neutron path is proven.
When asked to demonstrate SDN or NFV behavior, the candidate writes static routes or manual flow entries on each device instead of using the controller or orchestrator to program the fabric, so the design does not survive a device reboot or a topology change.
Static configuration is faster to type under time pressure and produces an immediately working ping. Candidates optimize for the first successful test rather than for the intent of the task, which is to show that the control plane programs the data plane.
What to do instead
Read the task for verbs like provision, orchestrate, or program and satisfy them through the controller/API. Validate by rebooting a node or triggering a topology change and confirming the controller reconverges the fabric without manual intervention.
The candidate builds a virtualization host and guest but never verifies that the guest can use the offload and overlay features the design depends on, such as virtio multiqueue, SR-IOV VF passthrough, or hardware VTEP offload, assuming the default virtual NIC is sufficient.
Default emulated NICs work for basic pings, so the lab appears functional. Performance-dependent tasks and feature-dependent tasks (overlay offload, high throughput) then fail or time out, and the candidate cannot explain why the guest behaves differently from a physical host.
What to do instead
Explicitly check the virtual NIC model, queue count, and whether the feature is offloaded or emulated. Benchmark or verify with ethtool and traffic tests, and confirm the host driver and firmware support the feature before claiming the design works.
The candidate deploys OpenShift or Kubernetes workloads without pinning the pod network or storage to the intended provider, then cannot explain why pods land on the wrong subnet or PVCs stay Pending.
Default CNI and default StorageClass are chosen silently when not specified. The candidate tests a simple pod, sees it run, and never inspects which network or storage class was used, so the mismatch surfaces only in the multi-network or persistent-workload task.
What to do instead
After deployment, inspect the pod's assigned network and the PVC's bound storage class directly. If the wrong provider is in use, correct the NetworkAttachmentDefinition or storageClass in the manifest and re-verify with describe and get commands.
The candidate configures overlay networking between sites or tenants and forgets the control-plane or data-plane isolation boundary, so routes or tenant traffic leak across VRFs or namespaces and the isolation test fails.
Reachability tests pass and the candidate moves on. Isolation is a negative test that must be run deliberately, and candidates rarely run it because the positive path already looks correct.
What to do instead
For every tenant or VRF separation, run an explicit negative test: confirm the source cannot reach the other tenant's prefix and that the routing table contains no leaked routes. Verify route targets and import/export policy on both sides.
The candidate treats the orchestration layer as a black box: when a stack or heat deployment fails, they re-run it repeatedly instead of reading the deployment status, events, and logs to find the failing resource.
Re-running is quick and sometimes succeeds by luck, which reinforces the habit. The underlying failure, such as a quota limit, a missing image, a scheduling constraint, or a failed health check, remains and recurs under exam conditions.
What to do instead
On any failed deployment, stop and read the resource events and controller logs before retrying. Identify the specific failing resource and its reason string, fix the root cause, then redeploy once and confirm the status reaches the expected steady state.
The candidate answers cloud-fundamentals questions by describing product features of one vendor's platform rather than the underlying model, such as the difference between IaaS, PaaS, and a managed service, or between horizontal and vertical scaling, and misapplies the model in the design task.
Hands-on study focuses on a single platform's UI and CLI, so the candidate learns buttons rather than concepts. When a design question asks for a service model or scaling strategy, the candidate maps it to whatever the studied platform does.
What to do instead
Study the service and deployment models as abstractions and practice classifying each task by model before configuring it. In design answers, state the model explicitly and justify the choice against the requirement, not against a vendor default.
The candidate configures NFV service chains or VNF forwarding graphs but never validates the traffic path through each VNF in order, so a chain that drops traffic at the second hop is reported as working because the first hop responds.
A ping from the chain ingress to the first VNF succeeds and creates a false positive. The candidate does not trace the full path, so a misordered classifier, a missing route in a middle VNF, or a return-path asymmetry is missed.
What to do instead
Trace the chain hop by hop with per-hop counters or captures, confirming that traffic enters and exits each VNF in the intended order and that the return path is symmetric. Validate the classifier rules match the intended flow before declaring the chain functional.