NS0-304 common mistakes
NS0-304 · Understand the traps and how to avoid them.
Assuming a newly added disk is immediately usable by an existing aggregate without checking aggregate state, ownership, and spare status, then answering that the aggregate automatically grows.
Candidates memorize 'add disk to aggregate to grow it' but skip the preconditions: the disk must be a visible spare, owned by the same node, of a compatible type, and the aggregate must not be in a restricted or degraded state. Exam items often describe an add-disk attempt that silently fails.
What to do instead
Before adding, verify the disk appears as a spare with the correct owner, confirm the aggregate is online and not restricted, and check that disk type/class matches the aggregate. Recall that growth is not automatic on assignment alone: the aggregate must incorporate the disk, and RAID group constraints (e.g., raidtype, max RAID group size) can block or reshape the layout. Practice the sequence: show spares, check aggregate status, add, then confirm new size.
Confusing the roles of SnapMirror policy, relationship, and destination volume when predicting whether a scheduled transfer will run or whether a snapshot will be replicated.
The policy defines what gets mirrored (all snapshots vs. a labelled set) and the schedule; the relationship binds source and destination; the destination volume holds the replicated data. Candidates conflate 'policy' with 'schedule' and assume every snapshot is transferred by default.
What to do instead
Map each object to its job: policy = which snapshots and transfer rules; relationship = source/destination pairing and state (snapmirrored, broken-off, transferring); destination volume = target storage. For questions about 'which snapshots replicate', inspect the policy's rules and labels, not the volume's snapshot list. For 'why did nothing transfer', check relationship health and lag before touching policy.
Treating export policy rules as ordered top-down by specificity, or assuming a client denied by one rule can still match a later permit rule.
Candidates carry over firewall-style 'most specific wins' intuition. In ONTAP, export policy rules are evaluated in order and the first matching rule decides, so a broad deny placed early blocks a later specific allow.
What to do instead
Read rules top to bottom and stop at the first match on client match, protocol, and access. When a client is unexpectedly denied, list the rules in order and find the first one whose clientmatch covers it. Fix by reordering so the intended allow precedes broader denies, or by narrowing the earlier rule's clientmatch. Verify with the effective-policy view for that client address.
Answering that a Snapshot copy protects against volume or aggregate loss, or that deleting a file inside a volume is recoverable from a Snapshot without restoring it to a location.
Snapshots are commonly described as 'backups' in casual material. Candidates then overstate their scope and forget that snapshots live inside the same volume (and aggregate) they protect, and that recovery means restoring or cloning data back, not 'undoing' the delete in place.
What to do instead
State the boundary explicitly: snapshots are point-in-time, space-efficient copies within the volume; they do not survive volume deletion and do not protect against aggregate failure. For a deleted file, the recovery path is restore from the snapshot (to original or alternate path) or clone the snapshot and copy out. Reserve SnapMirror/SnapVault for site or node loss, and note SnapLock/cloud for retention and archive needs.
Misjudging LUN provisioning: assuming a LUN is directly mountable by a host, or that creating a LUN alone makes it visible over SAN.
In ONTAP, a LUN is a block object inside a volume and must be presented through an igroup and a LUN mapping before a host sees it. Candidates who come from file protocols expect a path-based share and skip the mapping step, or confuse the LUN's path with its WWID/serial.
What to do instead
Recall the SAN chain: volume (with space guarantees appropriate for block) → LUN → igroup containing the host initiator (IQN/WWPN) → LUN map binding LUN to igroup. Host visibility depends on all four. When a host cannot see a LUN, check initiator registration, igroup membership, and the map, in that order, before suspecting the LUN itself.
Assuming a volume's reported size equals the space it consumes, or that thin-provisioned volumes cannot fail writes.
ONTAP separates nominal size from used space, and guarantees (volume-level or file/LUN-level) determine whether writes can fail. Candidates answer 'the volume has free space' based on nominal size while the containing aggregate is full, or ignore that a volume without a guarantee can run out under aggregate pressure.
What to do instead
Distinguish three layers: nominal volume size, space actually used, and aggregate free space. For block workloads and critical data, confirm the guarantee type (volume or none) and that the aggregate has headroom. When writes fail despite apparent volume free space, check aggregate available space and the volume's guarantee/overcommit settings. Practice reading the space breakdown rather than a single size number.
Diagnosing performance complaints by looking only at average latency or node CPU, ignoring per-volume, per-LUN, and per-client breakdowns and the difference between latency and throughput bottlenecks.
Dashboard-level averages hide hot spots. A single volume, LUN, or client can saturate a resource while node-wide averages look fine, so candidates pick the wrong culprit or the wrong fix (adding bandwidth where latency is the issue).
What to do instead
Work top-down: identify the affected workload (volume/LUN/client), then check its IOPS, latency, and throughput separately, and correlate with resource utilization (CPU, disk, network) at the same time window. Separate latency-bound symptoms (queueing, high response time at low throughput) from throughput-bound ones (link or disk saturation). Use historical/statistical views to catch intermittent spikes rather than a single instantaneous sample.
Choosing a role-based access control answer without distinguishing ONTAP administrative roles from file-level permissions (NTFS ACLs, NFSv4 ACLs, or mode bits).
Both are 'permissions', so candidates apply an admin-role fix to a file-access problem or vice versa. The two layers govern different things: who can administer the cluster vs. who can read/write a file or share.
What to do instead
Classify the symptom first. Cannot run a CLI/API command or see an object in System Manager → administrative role and scope. Can log in but cannot open/modify a file or mount a share → export policy, share ACL, or file ACL (and possibly mapping of the user). Fix at the layer that matches the symptom, and remember that a user can have full admin rights and still be denied file access.
Assuming a scripted or automated change (via CLI, API, or orchestration) is atomic, or that re-running it is harmless, without checking idempotency and partial-failure behavior.
Automation questions reward understanding that multi-step operations can fail midway, leaving objects in an intermediate state, and that naive re-runs can duplicate objects (volumes, LUNs, relationships) or fail on 'already exists'. Candidates answer as if the API call either fully succeeds or changes nothing.
What to do instead
Design and reason in terms of check-then-act: query current state, create only if absent, and make each step idempotent. On failure, inspect what was created before retrying, and clean up or resume rather than blindly re-running. Prefer declarative desired-state tooling or workflows with error handling over long imperative scripts, and validate in a non-production context before broad rollout.
Overlooking that a cluster or SVM change requires the right scope (cluster vs. SVM) and that some settings are inherited or must be set at the SVM level for clients to see them.
Many objects exist at both cluster and SVM scope (e.g., policies, services, namespaces). Candidates apply a setting at the wrong scope, then conclude the feature is broken because clients do not see the change.
What to do instead
For each task, state the scope first: is this a cluster-wide resource (aggregates, nodes, cluster peering) or an SVM-scoped one (volumes, LUNs, shares, export policies, SVM-scoped services)? Apply the change at the SVM that serves the client, and check whether a cluster-level default is being inherited. When a client cannot reach a service, confirm the service is enabled on that SVM and that the SVM's interfaces and policies are in place.