CloudNetX common mistakes
CloudNetX · Understand the traps and how to avoid them.
Designing a hybrid-cloud topology by listing connectivity options (VPN, dedicated interconnect, SD-WAN) without first deriving the requirements (latency budget, throughput per site, RPO/RTO, compliance residency) that select between them.
Candidates pattern-match the diagram to a familiar reference architecture and jump to the 'right' answer, but scenario items are graded on whether the chosen option is justified by stated constraints; an option that is defensible in general can be wrong when the scenario specifies a hard latency or residency requirement.
What to do instead
Before choosing, write a one-line requirement table from the stem: per-site bandwidth, peak vs average, latency ceiling, data-residency constraint, budget cap, and availability target. Eliminate any option that violates a hard constraint first, then compare survivors on cost and operational complexity. If the stem gives no constraint that discriminates, the intended answer is usually the simplest option meeting all stated requirements.
Treating segmentation as a single choice (VLANs vs subnets vs security groups vs microsegmentation) rather than layering policy consistently across on-premises, cloud VPC/VNet, and the interconnection between them.
Study material tends to present each control in isolation, so candidates pick the control they know best and miss that east-west traffic between segments may bypass it; items about lateral movement after a compromise specifically test whether the candidate knows where enforcement actually happens.
What to do instead
For any segmentation item, trace one packet from source to destination and name every enforcement point it crosses: host firewall, hypervisor security group, network ACL, firewall appliance, cloud-native policy. Choose the design where the enforcement point sits closest to the workload and is consistent across environments, and be able to state which traffic path is not covered by a given control.
Selecting a monitoring or telemetry approach by tool name (NetFlow, SNMP, streaming telemetry, synthetic probes) without matching it to the question being asked: capacity planning, fault detection, or per-flow security forensics.
Candidates memorize tool capabilities but not the sampling and retention characteristics that determine fitness; flow sampling at low rates is fine for capacity trending and useless for proving a specific host contacted a specific external address.
What to do instead
For each monitoring item, identify the decision the data must support and the required granularity (per-interface counters, per-flow records, per-packet capture, active probe latency). Then check the option's sampling rate, collection interval, and retention against that granularity. Practice stating in one sentence what each telemetry type can and cannot prove.
Diagnosing a connectivity failure by starting at the application layer or by changing configuration before establishing where the path breaks.
Under time pressure, candidates recall a similar past incident and apply its fix; troubleshooting scenarios are built so the symptom is reachable by several causes, and only a layered, evidence-driven elimination reaches the intended root cause.
What to do instead
Use a fixed sequence and say it explicitly: confirm the source address and route, then test hop-by-hop reachability, then check transport (port, ACL, NAT, stateful firewall session), then name resolution, then application. At each layer, name the single command or data source that would confirm or refute the hypothesis before proposing a change.
Ignoring asymmetric routing and stateful-inspection interaction when designing multi-path or multi-region connectivity.
Diagrams show redundant paths as an unconditional improvement, so candidates add paths without checking that return traffic follows the same inspection device; stateful firewalls drop the return leg of a flow whose outbound half was seen on a different path.
What to do instead
For every redundant-path design, trace the forward and return path separately and confirm both traverse the same stateful device or that state is synchronized. When asymmetry is unavoidable, prefer stateless filtering at the asymmetric boundary and document which flows are affected.
Answering identity and access questions with network controls (ACLs, VPN, IP allowlists) when the scenario requires workload or user identity-based authorization, or the reverse.
Zero-trust framing in study material blurs the boundary between network reachability and authorization; candidates pick a control that reduces exposure but does not actually enforce the stated policy requirement.
What to do instead
Read the requirement as a sentence about who may do what to which resource. If the requirement names a user, role, device posture, or service identity, the answer must involve an identity-aware policy decision point; if it names only address ranges and protocols, network controls are appropriate. State the enforcement point explicitly in your reasoning.
Choosing a routing or overlay design without checking failure-domain and convergence behaviour: what happens to traffic during a single link, node, or region loss, and how long reconvergence takes relative to the application's tolerance.
Candidates evaluate designs in the steady state shown in the scenario and never simulate the failure; items often hinge on whether a design blackholes traffic or reconverges within a stated timer.
What to do instead
For each candidate design, write the failure matrix: single link, single device, single site, single region. For each cell, state the resulting path and the expected reconvergence time, then compare to the application's session timeout. Reject designs whose failure mode silently blackholes rather than reroutes.
Proposing a remediation in a troubleshooting item without stating how to verify it and how to roll it back.
Candidates treat the fix as the endpoint of the question, but operations items reward the full loop of hypothesis, change, verification, and containment; a change with no verification step cannot be distinguished from a guess.
What to do instead
End every remediation answer with two sentences: the specific metric or test that confirms the fix worked, and the rollback trigger and method. If the stem says the change is in production, prefer the least-blast-radius change first and say why.
Confusing policy intent with policy implementation when describing security architecture: stating 'traffic is inspected' or 'least privilege is applied' without naming the mechanism, scope, and logging that make it true.
Architecture answers that stay at the level of intent read as correct but cannot be graded as correct, because the scenario usually contains a constraint (encrypted traffic, unsupported protocol, scale limit) that breaks a specific mechanism.
What to do instead
For each security claim, attach mechanism, scope, and evidence: what enforces it, which traffic it covers, what it does not cover, and where the logs land. Practice rewriting vague statements into that four-part form until it is automatic.
Managing time by reading the scenario once and answering from memory of the topic rather than extracting the stated constraints, then failing to revisit flagged items with remaining time.
Scenario-based exams front-load detail that changes the correct answer; candidates who skim answer the generic version of the question, and candidates who never return to flagged items lose the easiest recoverable points.
What to do instead
Adopt a two-pass routine: first pass, extract constraints into a short list and answer only items where one option clearly satisfies all of them, flagging the rest; second pass, re-read only the flagged stems and eliminate against the constraint list. Budget the second pass explicitly before starting.