JNCDS-SEC common mistakes
JNCDS-SEC · Understand the traps and how to avoid them.
When a design scenario describes a new requirement, the candidate jumps straight to a Junos configuration snippet or product selection instead of first restating the business and technical requirements and constraints.
The candidate treats JNCDS-SEC as a configuration exam, but the design questions are scored on the requirements-to-design traceability. Candidates who are strong on CLI habits default to 'how do I configure it' rather than 'what does the customer need and what are the trade-offs' and then pick an answer that is technically valid but does not satisfy the stated constraint.
What to do instead
Before evaluating options, write down the customer's stated requirements and constraints (scale, budget, compliance, existing Junos estate, uptime target) and eliminate any option that violates one of them. Only then compare the surviving designs on operational cost, complexity, and security posture.
The candidate treats the security domain as a list of features (firewall filters, IPS, UTM, MACsec, 802.1X) and picks the option with the most security features enabled, rather than matching controls to the identified threat and the customer's operational maturity.
Feature lists are easy to memorise and feel like the 'secure' answer, but design questions reward proportionate, enforceable controls and penalise designs the customer cannot operate. Candidates also forget that enabling every control on every interface increases management burden and can break availability requirements.
What to do instead
For each scenario, identify the asset, the threat, and the enforcement point first, then select the minimum set of controls that addresses it. Prefer controls that can be centrally managed (e.g., Junos Space Security Director, policy pushed from a central point) and explicitly note where a control is not justified by the stated risk.
The candidate designs management and reliability as an afterthought, proposing in-band management only, a single management path, or no out-of-band access, and omitting a discussion of how the device is recovered when the data plane or routing is broken.
Management and reliability questions read like routine operations material, so candidates skim them and default to 'SSH is enabled, so management is covered'. They forget that in-band management depends on the very forwarding and routing that a failure may have removed, and they under-specify logging, NTP, and configuration backup.
What to do instead
For every design, explicitly state an out-of-band or dedicated management path (separate VRF or interface, console server), centralised authentication (RADIUS/TACACS+), syslog and NTP reachability, and configuration archival. When a reliability question appears, name the failure being survived and the recovery path, not just the redundant component.
The candidate specifies a campus LAN with a single distribution switch, or with redundant switches but no first-hop redundancy protocol, and then claims the design meets a high-availability requirement.
Candidates equate 'two links' or 'two access switches' with redundancy and forget the Layer 2/3 gateway is a single point of failure. They also overlook that spanning tree blocks one path, so the second uplink provides no additional bandwidth without a deliberate design choice.
What to do instead
Check every availability claim against the failure of each individual component. For campus designs, pair redundant distribution devices with a first-hop redundancy mechanism (VRRP or similar) and state how the blocked path is used (e.g., per-VLAN spanning tree load sharing or a routed access design).
The candidate designs a branch WAN without stating how the branch reaches the internet and the corporate network, and without addressing what happens when the primary WAN link fails, so the design silently depends on a single transport.
Branch questions often focus on the device model or the routing protocol, and candidates stop there. They also assume the branch has the same connectivity options as the campus, ignoring last-mile constraints, cost, and the need for local internet breakout versus centralised egress.
What to do instead
For each branch, explicitly map primary and secondary transports, the failover trigger and convergence behaviour, and the egress policy (local breakout with security enforcement versus backhaul to a central point). State the traffic path for both normal and failed states.
The candidate oversubscribes the data center fabric without stating the ratio, or designs a spine-leaf topology but then connects servers to a single leaf or a single uplink, contradicting the design's own redundancy goal.
Spine-leaf is a familiar pattern, so candidates reproduce the diagram without applying the design rules that make it useful: consistent leaf-to-spine links, server dual-homing, and a defined oversubscription target. The redundancy intent and the actual cabling often disagree.
What to do instead
State the intended oversubscription at each tier and confirm the topology matches it. Verify every server and every leaf has a stated redundant path, and check that the chosen protocol (e.g., EVPN-VXLAN) is justified by the mobility or scale requirement rather than chosen by default.
The candidate selects a product or platform before the requirements are fixed, then writes the design to justify the already-chosen hardware, ignoring scale, throughput, or licensing limits stated in the scenario.
Product familiarity drives answer selection, and candidates who know a particular platform gravitate toward it. Design scenarios usually include a number (users, sessions, throughput, sites) that rules out the familiar option, but candidates skip the arithmetic.
What to do instead
Extract every quantitative requirement from the scenario and compare it against the platform's stated capacity with headroom. If a platform cannot meet the number, eliminate it regardless of familiarity, and state the headroom assumption explicitly in the answer.
The candidate describes security policy in general terms ('apply a firewall filter', 'segment the network') without naming where the policy is enforced, what the default action is, and what traffic is explicitly permitted.
Design answers are graded on specificity, and general statements feel complete to the candidate. Candidates also avoid committing to a default-deny posture because they worry about breaking legitimate traffic, so they leave the policy ambiguous.
What to do instead
For every security control, state the enforcement point (interface, zone, or device), the default action, the explicitly permitted flows with their direction, and how the policy is logged and audited. If a flow is uncertain, name the assumption rather than leaving the policy open.
The candidate proposes a routing or switching protocol change to solve a problem that is actually a policy or requirements problem, adding complexity without addressing the stated need.
Protocol knowledge is the candidate's strongest area, so it becomes the default tool. When a scenario describes a security or management concern, the candidate reaches for OSPF areas, BGP policies, or a new overlay instead of asking whether the customer's requirement calls for segmentation, monitoring, or process change.
What to do instead
Classify the stated problem first: is it reachability, isolation, visibility, or operability? Match the tool to the class, and when proposing a protocol change, state the specific requirement it satisfies and the operational cost it introduces. Reject options that add complexity without a stated benefit.
The candidate ignores the existing environment described in the scenario (legacy Junos versions, mixed vendors, existing MPLS or VPN estate, staff skills) and designs a greenfield solution that cannot be deployed incrementally.
Candidates study the ideal design and answer from it, treating the scenario's existing estate as background rather than a constraint. Migration cost, interoperability, and staff capability are rarely top of mind, so the answer is technically correct but undeployable.
What to do instead
List the stated existing constraints before designing, and for each proposed change state the migration path and the coexistence mechanism with the current environment. Prefer designs that can be introduced incrementally, and flag any element that requires a forklift upgrade as a risk to be justified.