NS0-701 common mistakes
NS0-701 · Understand the traps and how to avoid them.
Treating an SVM as a physical appliance and assuming each SVM needs its own dedicated aggregate, disks, or cluster, instead of recognizing it as a logical data server that shares cluster-wide physical resources.
Candidates carry over a one-server-one-storage mental model from older or non-clustered systems, so they misattribute aggregate ownership and resource sharing questions to SVMs.
What to do instead
Memorize the hierarchy: cluster > nodes > aggregates (physical disks) > SVMs (logical data servers) > volumes > LUNs/files. SVMs own volumes, LIFs, namespaces, and policies, not aggregates. Aggregates belong to the cluster and are assigned to nodes, and any SVM on that cluster can host volumes in them subject to rules.
Confusing intercluster LIFs with data LIFs when designing SnapMirror or cluster peering, and placing replication traffic on data LIFs or the cluster management network.
The LIF type names look interchangeable and candidates memorize ports without mapping each LIF role to its traffic class; peering setup screens also ask for IPs without labeling which LIF should answer.
What to do instead
Build a LIF role table: cluster LIFs carry intra-cluster traffic, intercluster LIFs carry peering and SnapMirror/SnapVault transfers between clusters, data LIFs carry client NFS/CIFS/iSCSI traffic, management LIFs carry admin access. Intercluster LIFs must be on a dedicated intercluster network reachable from the peer and are created per node. Verify with network interface show and cluster peer show before troubleshooting replication.
Assuming a Snapshot copy alone protects data, or that SnapMirror and SnapVault are the same relationship type, and answering protection-policy questions as if one mechanism covers both local recovery and long-term retention.
Both features are Snapshot-based and share terminology, so candidates collapse them; exam items deliberately test the difference between mirroring (async/sync replica of the active filesystem) and vaulting (independent, longer-retention backup copies).
What to do instead
Separate the purposes: Snapshot copies are point-in-time local copies for quick restore; SnapMirror replicates a writable source to a destination for disaster recovery and failover; SnapVault creates read-only backup copies with independent retention for compliance and long-term recovery. Learn that a mirror destination is a replica you can promote, while a vault destination is a backup you restore from, and that both are driven by protection policies with schedules and retention counts.
Believing that deleting a volume, LUN, or file immediately frees space, and failing to account for Snapshot copies, fractional reserve, or delayed free-block reclamation when sizing or troubleshooting capacity.
Space accounting in ONTAP is counterintuitive: deleted blocks remain referenced by Snapshot copies, and LUN space reservation and fractional reserve hold capacity that candidates assume is available.
What to do instead
Learn the capacity chain: volume used vs. available vs. Snapshot reserve; aggregate free space; LUN space reservation and fractional reserve behavior. When space does not free after deletion, check Snapshot copies (snapshot show, volume snapshot show), then volume show -fields space-* and aggregate show-space. To reclaim, remove or expire Snapshot copies and, if appropriate, disable space reservation or set fractional reserve to zero on volumes that do not need it.
Misreading role-based access control and export/share permissions, for example assuming an ONTAP admin role grants file-level access, or that an NFS export policy and a CIFS share ACL are interchangeable.
ONTAP layers authentication (who you are) and authorization (what you can do) at several independent levels: cluster/SVM admin roles, ONTAP file permissions, export policies, and share ACLs. Candidates conflate them.
What to do instead
Map each layer separately: ONTAP administrative RBAC (security login, roles such as admin, operator, readonly) governs CLI/API/System Manager access; export policies govern NFS client mount access by IP and protocol; CIFS share ACLs govern SMB share access; NTFS or UNIX file permissions govern file-level access. Troubleshoot from the outside in: network reachability, then export or share permission, then file permission, then authentication (Kerberos/LDAP/NIS).
Assuming ONTAP upgrades are transparent in-place operations with no planning, and ignoring upgrade methods, pre-upgrade validation, and the impact of an upgrade on SnapMirror and client sessions.
Candidates study features but skim the operational workflow; they do not know that upgrades are non-disruptive only under specific conditions and that different methods (automated upgrade, manual, or Ansible-based) apply to different topologies.
What to do instead
Learn the upgrade workflow: verify the target release and supported upgrade paths, run pre-upgrade checks, confirm aggregate and volume health, take a configuration backup and Snapshots, confirm SnapMirror relationships are healthy, and use the automated upgrade tool where supported. Know that non-disruptive upgrades require proper LIF failover configuration and that rolling upgrades move volumes and LIFs between nodes. After upgrade, verify with system node show and cluster image show.
Diagnosing performance problems by looking only at CPU or node utilization, and missing the workload-level metrics (latency, IOPS, throughput, and the bottleneck layer) that ONTAP performance tools expose.
Candidates default to host or hypervisor thinking; they do not know the ONTAP performance layers (node, aggregate, volume, LUN, SVM) or how to read latency breakdowns to locate the bottleneck.
What to do instead
Practice a layered method: use performance show and the performance statistics commands (or Active IQ Unified Manager) to check latency, IOPS, and throughput per object. Compare front-end client latency with back-end disk latency; high disk latency points to aggregate or disk contention, high front-end latency with low disk latency points to network or client issues. Check QoS policy groups, workload placement, and whether a volume has grown onto a busy aggregate.
Confusing cloud backup and tiering services, such as treating Cloud Volumes ONTAP, Cloud Backup, and FabricPool as interchangeable, or assuming SnapMirror to cloud is the same as a backup service.
The cloud portfolio names are similar and the exam tests which service does what; candidates memorize product names without mapping each to a function (primary storage, backup, tiering, replication).
What to do instead
Build a one-line definition for each: Cloud Volumes ONTAP is ONTAP running as cloud-native primary storage; Cloud Backup provides backup of on-premises ONTAP data to object storage with restore; FabricPool tiers cold blocks from aggregates to object storage while keeping metadata local; SnapMirror to cloud replicates to a cloud ONTAP or object target. Match each exam scenario to the function, not the brand name.
Assuming automation requires full custom scripting and ignoring ONTAP REST APIs, the ONTAP CLI, and Ansible modules; or using the legacy ZAPI interface without knowing its status relative to REST.
Candidates treat automation as a developer topic outside the exam, so they cannot answer which interface to use for a given task or how idempotent automation is structured.
What to do instead
Know the three automation surfaces: the ONTAP CLI for interactive and scripted commands, the REST API (preferred for new automation, with documented endpoints for volumes, SVMs, LIFs, and SnapMirror relationships), and Ansible modules for configuration management. Learn that REST is the strategic API and that automation should use idempotent operations and check current state before creating objects.
Assuming a SnapMirror relationship is healthy just because it exists, and not checking lag time, transfer status, or policy schedule when answering data-protection questions.
Candidates learn the commands to create relationships but not how to verify them, so they miss questions about lag, out-of-date mirrors, and failed transfers.
What to do instead
Memorize the verification commands and what each shows: snapmirror show for relationship state, health, lag time, and last transfer; snapmirror status for transfer progress; snapmirror policy show for schedule and retention. Know that a relationship in 'idle' with growing lag is unhealthy, that 'transferring' is normal, and that a broken relationship must be reinitialized with snapmirror resync before normal transfers resume.