JNCIA-Cloud common mistakes
JNCIA-Cloud · Understand the traps and how to avoid them.
You treat 'cloud' as one deployment model and answer questions about private, public, and hybrid clouds with the same characteristics, instead of first identifying which model the scenario describes.
Everyday usage collapses public IaaS and on-premises virtualization into a single mental category, so you pattern-match on familiar virtualization features (fixed capacity, manual provisioning, capital expense) even when the stem clearly describes elastic, self-service public cloud.
What to do instead
Before answering, underline the deployment and service model cues in the stem (self-service, pay-as-you-go, multi-tenant, on-premises, provider-managed). Build a one-page comparison of public, private, and hybrid plus IaaS/PaaS/SaaS against attributes: who manages what, billing model, elasticity, tenancy, and typical use case. Practice classifying 20 short scenarios by model in under a minute each.
You pick the option that best describes the technology generally rather than the option that answers the specific question asked, for example choosing a correct definition of orchestration when the stem asks which layer performs a given task.
Cloud Fundamentals questions often present several true statements; the distractor is factually correct but does not fit the constraint in the stem (who does it, at which layer, in which model). Candidates read the options first and stop at the first true-sounding one.
What to do instead
Read the stem twice and rewrite the actual question in your own words before looking at the options. Eliminate options that are true but off-target, and justify the surviving answer by quoting the stem constraint it satisfies. Drill with questions that deliberately include true-but-irrelevant distractors.
You confuse the shared responsibility boundary, assuming the cloud provider secures customer data, identities, and configurations, or conversely that the customer patches the hypervisor and physical hosts.
Marketing language ('secure cloud') and the move from on-premises habits create a default assumption that the provider handles everything. The boundary also shifts between IaaS, PaaS, and SaaS, and candidates memorize one version of it.
What to do instead
Memorize the split as 'provider secures the cloud, customer secures what is in the cloud', then draw the boundary separately for IaaS, PaaS, and SaaS covering physical, hypervisor, OS, runtime, application, data, identity, and network configuration. For each practice question, name who owns each layer before choosing an answer.
You answer security questions by selecting the strongest-sounding control (encryption, MFA, WAF) instead of the control that addresses the risk described in the scenario, such as data in transit versus at rest or identity versus network perimeter.
Security terminology is emotionally weighted; 'encryption' feels like the safest answer. Without mapping the threat to the control category, candidates default to the most technical option.
What to do instead
Classify each scenario by asset and threat first (data at rest, data in transit, credential compromise, lateral movement, DDoS, misconfiguration), then recall which control class addresses it. Build a table pairing each threat with the primary and secondary controls and the layer where each is enforced.
You treat security groups and network security policies as interchangeable stateless filters, forgetting that typical cloud security groups are stateful and that return traffic is automatically permitted.
On-premises firewall experience with explicit bidirectional rules and ACLs carries over, and candidates apply the same mental model to cloud constructs without checking statefulness or default-deny behavior.
What to do instead
For each cloud firewall construct you study, record three properties: stateful or stateless, default allow or default deny, and where it is attached (instance, subnet, or policy). Work through a two-tier application and write the minimum rules for web-to-app and app-to-database traffic, including which direction needs an explicit rule.
You assume a workload in a private subnet can reach the internet for updates by default, or that placing a resource in a public subnet automatically gives it outbound internet access.
Subnets are often treated as a security label rather than a routing construct. Candidates forget that internet reachability depends on route table entries and, for private subnets, on a NAT device, not on the subnet name.
What to do instead
Trace the packet: source address, route table lookup, next hop, NAT translation if any, and return path. Draw a VPC or VNet with public and private subnets, an internet gateway, and a NAT gateway, and label which traffic flows where. Answer routing questions by following this path explicitly rather than by intuition.
You answer connectivity questions by choosing the option with the most bandwidth or the lowest latency claim, ignoring the requirement for private, non-internet transport, deterministic routing, or provider-independent addressing.
VPN, dedicated interconnect, and internet-based options are marketed on performance numbers, so candidates rank by speed instead of matching the transport requirement in the stem.
What to do instead
Build a decision table for site-to-site VPN, dedicated private interconnect, and public internet paths across attributes: transport medium, encryption, bandwidth guarantees, setup time, cost profile, and failure behavior. When reading a stem, extract the constraint keywords (private, encrypted, SLA-backed, rapid deployment) before comparing options.
You describe automation only in terms of scripting CLI commands in sequence, missing idempotency, declarative desired-state models, and the role of APIs and templates in repeatable provisioning.
Automation experience from traditional operations is imperative and script-based, so candidates map new terms onto old habits and select answers that describe scripts rather than infrastructure as code.
What to do instead
Learn the distinction between imperative scripts and declarative templates, and be able to explain idempotency with a concrete example (running the same template twice yields the same result). Study one template format conceptually: parameters, resources, dependencies, and outputs, and how a provider reconciles desired state.
You mix up orchestration with provisioning or configuration management, attributing workflow sequencing, dependency handling, and cross-service coordination to the wrong tool or layer.
The terms are used loosely in vendor documentation, and candidates memorize product names without the functional definition, so any option containing a familiar product name looks plausible.
What to do instead
Define each term in one sentence: provisioning creates resources, configuration management sets state inside a resource, orchestration coordinates multiple automated tasks and their dependencies into an end-to-end workflow. For practice stems, identify whether the described activity is single-resource, in-resource, or multi-service, and select accordingly.
You ignore operational and cost consequences in design questions, choosing the most feature-rich architecture even when the stem specifies a small workload, a tight budget, or minimal administrative overhead.
Candidates study features in isolation and are rewarded for recognizing capabilities, so they select maximum capability rather than fit. Requirements about elasticity, reserved capacity, and managed versus self-managed are treated as background.
What to do instead
Adopt a requirements-first habit: list the constraints in the stem (scale, budget, team size, compliance, availability target) and score each option against them. Practice comparing managed versus self-managed services and on-demand versus committed pricing, and state explicitly which constraint eliminates each distractor.