NCP-ADS common mistakes
NCP-ADS · Understand the traps and how to avoid them.
When asked which storage protocol or fabric a given workload requires, the candidate answers from the product name alone (for example, assuming any 'enterprise array' means Fibre Channel) instead of identifying whether the path is block over FC/iSCSI, file over NFS/SMB, or object over S3, and whether the interconnect is lossless Ethernet or FC.
Candidates memorise array model names and marketing tiers but never build a mapping from access pattern (block database, shared file, object archive) to protocol, transport, and required fabric features such as jumbo frames, flow control, or zoning. Exam items deliberately mix these layers so that a plausible-sounding product name is the wrong answer.
What to do instead
Build a one-page matrix before exam day: rows are workload types (OLTP database, shared home directories, backup target, container registry, archive), columns are protocol, transport, typical latency/throughput expectation, and the fabric prerequisite. For each practice item, first write down the access pattern and required semantics, then eliminate options that break the transport or fabric requirement.
The candidate computes usable capacity by multiplying raw disk capacity by a single RAID efficiency number and ignores rebuild reserves, hot spares, snapshot and clone overhead, metadata, and the difference between raw, formatted, and provisioned capacity.
Vendor datasheets and quick-reference tables present one headline efficiency figure, and candidates reuse it for every RAID level and every drive count. Items that include a hot spare or a snapshot policy then look ambiguous, and the candidate picks the number closest to the memorised percentage.
What to do instead
Practise deriving usable capacity from first principles for RAID 1, 5, 6, 10, and erasure coding at several drive counts, explicitly subtracting parity drives, spare drives, and a stated reserve. Track three separate numbers (raw, usable after protection, provisioned to hosts) in every practice problem and state which one the question asks for before computing.
When an item describes a protection scheme, the candidate confuses RPO with RTO, or assumes replication alone satisfies a backup requirement, and therefore selects a synchronous mirror as the answer to a ransomware-recovery scenario.
The acronyms are learned as a pair without attaching them to the direction of failure: RPO is how much data may be lost (backwards in time), RTO is how long recovery may take (forwards in time). Replication is also intuitively 'protection', which masks the fact that it propagates corruption and deletion.
What to do instead
For every practice scenario, write two sentences before looking at the options: 'The business can lose at most X of data' (RPO) and 'the service must be back within Y' (RTO). Then classify each candidate mechanism as replication (availability, copies corruption), snapshot (fast rollback, same failure domain), or independent backup (isolated copy, slower restore) and check it against both sentences.
The candidate treats a stretched cluster or metro replication design as automatically providing site-failure tolerance, without checking quorum and witness placement, inter-site latency budgets, or whether the surviving site can absorb the full workload.
Stretched-cluster diagrams look symmetric, so candidates assume either site can run alone. In practice a two-site cluster needs a third quorum element, and a witness placed at the primary site leaves the secondary without quorum after a primary loss.
What to do instead
For each HA or DR topology, explicitly answer three questions: where does the quorum or witness component live, what is the maximum round-trip latency the replication mode tolerates, and does the surviving site have enough compute and storage headroom for full load. Practise drawing the failure of each individual site and component and tracing which side retains quorum.
The candidate answers virtualisation questions by naming a feature (for example, 'live migration' or 'distributed resource scheduling') without verifying the prerequisites the scenario omits, such as shared storage, identical CPU feature sets, L2 adjacency for the guest, or cluster-level admission control headroom.
Feature names are memorable and appear in every overview deck, while prerequisites appear only in design guides. Items are written so that the feature is desirable but one prerequisite is missing, and the candidate selects it on desirability alone.
What to do instead
For each major virtualisation capability, keep a short prerequisites list (shared datastore, compatible CPU baseline or EVC mode, network stretched to both hosts, quorum, reserved capacity). When reading a scenario, tick off prerequisites one by one; if any is absent, the feature is the wrong answer regardless of how well it fits the intent.
The candidate selects a cloud storage or compute tier by matching the workload description to a tier name rather than to the access-frequency, durability, retrieval-latency, and egress-cost characteristics stated in the scenario, and ignores minimum storage duration and retrieval fees.
Tier names (hot, cool, archive, infrequent access) sound self-explanatory, so candidates skip the pricing mechanics. Exam items often hinge on a workload read once a year or deleted after 20 days, where the cheapest-looking tier is the most expensive option.
What to do instead
Maintain a comparison table of the tiers you are likely to be tested on with four columns: access frequency, retrieval latency, minimum retention period, and retrieval or egress charge. For each practice item, extract the stated access pattern and retention period first, then eliminate tiers whose minimum duration or retrieval cost contradicts them.
When an item shows a declarative configuration or pipeline, the candidate predicts the result by reading the intent of the code rather than tracing the actual order of operations, variable precedence, and idempotency of each step, and assumes a re-run will converge when it will in fact fail or duplicate resources.
Infrastructure-as-code items reward mental execution, but candidates read them like documentation. Provider defaults, variable precedence rules, and resources that are not idempotent (for example, a script step that appends rather than ensures) are the usual traps.
What to do instead
Practise dry-running snippets on paper: number each line, write the resulting state after it, and note where a second execution would differ from the first. Specifically check variable precedence order, default values, count or for-each expansion, and any provisioner or script that is not idempotent. Read the question for 'second run' or 'already exists' wording, which signals this trap.
The candidate treats state and secrets as incidental: assuming state is shared automatically between operators or CI runners, that a plan can be applied safely from a laptop, or that secrets written into configuration are protected by the repository's access controls.
Tutorials run everything locally with a single operator, so state locking, remote backends, and secret injection never appear. Candidates transfer that single-user mental model to team and pipeline scenarios where concurrency and secret exposure are exactly what is being tested.
What to do instead
For every automation scenario, ask three questions: where does state live, who can lock it, and where do credentials come from at runtime. Learn to recognise correct answers that use a remote backend with locking, plan artefacts reviewed before apply, and secret references resolved from a vault or environment at deploy time rather than committed values.
Presented with a performance complaint, the candidate jumps to the storage tier or the array as the bottleneck and selects a remediation (add SSD, add cache, rebalance) without first using the utilisation, saturation, and error signals given in the scenario to locate the constrained resource.
Storage is the exam's subject, so it attracts blame. Candidates also conflate high utilisation with saturation, and latency reported by an application with latency measured at the device, so a saturated network link or an overloaded host queue is misread as slow disks.
What to do instead
Adopt a fixed triage order for every performance item: identify the reported symptom and its measurement point, then check utilisation, saturation, and errors at each layer from guest to host to fabric to array, and only then choose a remedy. Practise distinguishing queue-depth growth with flat throughput (saturation) from high utilisation with stable latency (healthy).
The candidate answers monitoring and troubleshooting items by choosing the tool or dashboard that would display the symptom, rather than the diagnostic step that would discriminate between competing causes, and skips checking whether the alert threshold or metric definition matches what the scenario describes.
Candidates equate observability with tooling knowledge and pick the most feature-rich platform. Items are usually testing method: which single check separates a path failure from a performance regression, or why an alert fired when the service was fine (a threshold or aggregation problem).
What to do instead
For each practice scenario, state the two most likely causes and then name the one measurement that distinguishes them (for example, host-side versus array-side latency, or per-path error counters versus aggregate throughput). Separately revise how counters are aggregated and how thresholds are set, so you can recognise alert-fatigue and false-positive explanations.