Free NS0-522 Practice Test Questions and Answers (2026)

In NetApp ONTAP, converting a Fibre Channel (FC) port from tape backup (initiator mode) to serve SAN host data (FCP target mode) requires modifying the port personality on the hardware adapter. Executing system node hardware unified-connect show allows administrators to view the status, mode, and personality configuration of the Unified Target Adapter (UTA2) or FC adapter ports across cluster nodes. This command verifies that the port personality switch from initiator to target was applied successfully, confirming that the physical port is configured in FC target mode, online, and fully operational for SAN LUN traffic.

Option A: network interface show displays logical interface (LIF) status and IP/FC address assignments, but does not show hardware adapter port personality or physical unified-connect operational modes.

Option B: lun persistent-reservation show checks SCSI-3 persistent reservations on existing LUNs, which is unrelated to hardware port personality changes and port usability verification.

Option D: vserver fcp initiator show displays logged-in host initiators connected to the Vserver, but cannot verify hardware adapter port modes or physical configuration changes.

1. NetApp Documentation, "ONTAP 9 System Administration Reference: system node hardware unified-connect commands," NetApp Docs.

2. NetApp SAN Configuration Guide, "Configuring FC Target Adapters and Port Personalities in ONTAP," Section: Adapter Management.

When configuring Jumbo frames for storage traffic such as NVMe over TCP on Cisco Nexus switches, proper MTU alignment across the physical and logical path is essential. NetApp ONTAP configures Jumbo frames by setting the MTU to 9000 at the broadcast domain level. Cisco Nexus switches require the global system jumbo MTU or interface MTU to be configured to 9216. This higher MTU on the switch accommodates the payload along with additional protocol headers, VLAN tags, and encapsulation overhead without fragmenting frames. Configuring ONTAP to MTU 9000 and Cisco Nexus switches to MTU 9216 ensures uninterrupted, high-throughput NVMe/TCP performance without frame drops.

Option C: ONTAP uses standard MTU 9000 for jumbo frames; setting it to 9216 is not supported on ONTAP storage interfaces.

Option D: Setting Cisco Nexus switches to 9000 can cause frame drops for tagged VLAN traffic due to encapsulation header overhead exceeding MTU limits.

1. NetApp Technical Report TR-4886: "NVMe over TCP Implementation Guide ONTAP 9", Section 3.1 "Switch Configuration and MTU Settings".

2. NetApp Documentation: ONTAP 9 Network Management Guide, "Configuring broadcast domains for MTU 9000".

3. Cisco Nexus 9000 Series NX-OS Interface Configuration Guide, Section "Configuring Jumbo Bytes".

When conducting a physical site survey for deploying a switchless HA pair with two NetApp DS224C disk shelves into an existing customer rack, physical infrastructure constraints must be carefully validated prior to installation. Validating Rack Units ensures adequate contiguous vertical space is available within the rack cabinet to house the controllers (2U) and storage shelves (2U each, totaling 6U). Validating Power Connections ensures sufficient power distribution unit (PDU) outlets, proper plug types, and adequate power delivery and thermal capacity exist to support redundant power supplies for all nodes and shelves. Together, these validations guarantee physical fit and power reliability during deployment.

A. Cluster switches are not required for a switchless HA deployment, making switch location verification unnecessary.

D. Crash cart location is an operational convenience, not a prerequisite physical requirement for rack space and power readiness.

- NetApp Hardware Installation and Setup Guides, Section: "Site preparation for AFF/FAS switchless HA pairs with DS224C shelves".

- NetApp ONTAP SAN Express Guide, Section: "Preparing for physical installation and rack layout".

Synchronous replication protocols, such as SnapMirror Synchronous or MetroCluster, require write operations to be acknowledged by the remote storage array before completing at the primary host. A WAN link latency of 500 ms introduces an unacceptable write latency penalty, directly conflicting with the customer's application requirement for sub-100 ms response times. Because high network latency makes synchronous mirroring technically unfeasible, the recommended architecture is asynchronous SnapMirror replication. Asynchronous replication decouples host write operations from remote transfer latencies, enabling local writes to complete immediately while replicating data according to a scheduled Recovery Point Objective (RPO) that aligns with business disaster recovery requirements.

A. 500 ms latency causes severe application performance degradation and timeouts because synchronous replication blocks write completions until remote acknowledgments are received.

C. Adding a third cluster does not resolve the physical 500 ms WAN propagation latency between the primary and secondary data centers.

D. MetroCluster strictly requires sub-10 ms round-trip latency and cannot compensate for a 500 ms WAN link delay.

- NetApp ONTAP 9 Data Protection Power Guide, Section "SnapMirror Synchronous Requirements and Limitations", page 87.

- NetApp Technical Report TR-4015: "SnapMirror Configuration and Best Practices for ONTAP 9", Section 2.2 "Latency Constraints in Remote Mirroring".

In ONTAP, Challenge-Handshake Authentication Protocol (CHAP) parameters for iSCSI sessions are managed at the Storage Virtual Machine (SVM) level using the CLI command vserver iscsi security create or vserver iscsi security modify. This command defines the initiator name, authentication type (such as bidirectional or unidirectional CHAP), user credentials, and security policies required for authenticating iSCSI hosts. By creating security entries per initiator, ONTAP enforces strict authentication prior to establishing session connections between host initiators and target LIFs. This ensures secure communication across IP SAN environments without altering physical network or host mapping configurations.

B. igroup initiator modify adds or removes initiator names within an initiator group but does not manage CHAP authentication passwords or security policies.

C. security certificate create generates digital certificates for SSL/TLS encrypted management, which is unrelated to iSCSI CHAP password settings.

D. security login create creates administrative login accounts for managing ONTAP, rather than storage access credentials for iSCSI CHAP hosts.

- NetApp ONTAP 9 Documentation: Command Reference - vserver iscsi security create

- NetApp SAN Configuration Guide: iSCSI Security and CHAP Authentication Configuration

In NetApp ONTAP, network port reachability show is the primary command used to diagnose IP network connectivity and reachability issues across broadcast domains and physical network ports. For IP-based SAN protocols such as NVMe/TCP and iSCSI, persistent LIF disconnections are commonly triggered by underlying physical port reachability failures, VLAN tagging errors, or MTU size mismatches across the network path. Running network port reachability show allows system administrators to verify whether the underlying network ports hosting the NVMe/TCP LIFs can properly reach their expected destination broadcast domain and identify misconfigurations across the network fabric that cause LIF instability.

Option A: ipspace show is incorrect because it only displays configured IPspaces and associated storage virtual machines without diagnosing lower-level port connectivity or reachability issues.

Option B: vserver nvme subsystem show is incorrect because it displays NVMe subsystem mappings and host initiators rather than troubleshooting underlying IP network reachability problems.

Option C: cluster ping-cluster is incorrect because it tests internal cluster interconnect node-to-node communication rather than host-to-LIF NVMe/TCP reachability across the SAN IP network.

- NetApp ONTAP 9 Documentation, "network port reachability show command reference", Network Management Guide, Section: Reachability Domain Repair.

- NetApp Technical Report TR-4880: "NVMe over TCP Deployment and Configuration Guide with NetApp ONTAP", Section 6: Network Troubleshooting.

To concurrently serve a namespace over NVMe/FC, a LUN over FCP, a LUN over iSCSI, and an NFS export, only

one data SVM (Storage Virtual Machine) is required. NetApp ONTAP allows a single SVM to support multiple SAN

and NAS protocols simultaneously, enabling efficient and consolidated management of storage resources.

For more information, refer to:

NetApp Documentation on SVM Configuration

NetApp SVM Best Practices

Active IQ Config Advisor is NetApp's configuration validation and health check tool that includes a difference report (diff report) capability. This feature allows a storage engineer to compare two separate data collections—for example, a baseline collection taken at the design/intended-state stage versus a collection taken after delivery/implementation. The tool automates the creation of this difference report, highlighting configuration deviations between the two points in time. This directly satisfies the requirement to demonstrate that the ONTAP SAN solution was delivered as intended, making it the most specific and directly applicable tool for validating delivery against site design documentation.

A. NetAppDocs — A PowerShell module that generates as-built documentation/reports, but does not automate configuration difference (diff) reporting between collections.

B. Active IQ OneCollect — A data/log collection utility for diagnostics and upgrades; it gathers data but does not generate automated difference reports.

D. Harvest — A performance metrics collection tool feeding Grafana/dashboards; it monitors performance telemetry, not configuration delivery validation.

1. NetApp Documentation — Active IQ Config Advisor Help / User Guide, "Comparing Collections / Difference Report" section (NetApp Support site, Tools > Config Advisor documentation).

2. NetApp Support — Config Advisor Downloads and Documentation page, "Features: Configuration validation and comparison" (mysupport.netapp.com, Tools section).

3. NetApp Documentation — Active IQ OneCollect Overview, describing data collection scope (NetApp Support, Tools > OneCollect), confirming diagnostic-only scope.

4. NetApp — Harvest Documentation (NetApp Harvest GitHub/Docs), describing performance telemetry collection scope.

5. NetApp — NetAppDocs PowerShell Toolkit Documentation, describing as-built report generation (NetApp Support, Tools section).

During the assessment and planning phase of a NetApp ONTAP SAN deployment, verifying hardware compatibility and capturing baseline performance metrics are essential prerequisites. Legacy SAN environments often contain older host Bus Adapters (HBAs) and switch models whose firmware, drivers, or topology may not be supported by the target ONTAP software version. By referencing the NetApp Interoperability Matrix Tool (IMT), validating switch zoning, and documenting current workload I/O patterns (such as IOPS, throughput, and latency), storage architects ensure seamless integration, prevent post-implementation operational outages, and correctly size target ONTAP storage system controllers and storage pools to meet customer requirements.

B: Installing software and provisioning storage prior to completing compatibility assessment risks severe system downtime and unsupported hardware configurations.

C: Blanket replacement of all existing switches is unnecessary and cost-prohibitive without first assessing compatibility and throughput requirements.

D: Skipping existing infrastructure inventory prevents identification of incompatible HBAs, firmware, and fabric switch topologies prior to deployment.

E: Configuring SAN ports without validating switch compatibility leads to fabric segmentation, unsupported configurations, and potential communication loss.

- NetApp Interoperability Matrix Tool (IMT): SAN Component Compatibility Verification.

- NetApp Technical Report TR-4682: NetApp ONTAP SAN Design and Implementation, Section: "Pre-deployment Assessment and Planning".

In NetApp ONTAP FC troubleshooting, the network fcp adapter show command provides critical details regarding node adapters, FC port addresses, connected switch ports, fabric names, and switch domain IDs. In Fibre Channel SAN topology troubleshooting, domain IDs identify individual switches within the fabric infrastructure. According to the CLI output provided in the scenario, port 2a on node n2 displays an FC address and switch connectivity corresponding to Domain ID 20 (Option A). Identifying this domain ID enables network engineers to detect potential cabling or zoning misconfigurations, such as an adapter port accidentally cabled to the wrong switch fabric domain during system deployment or hardware maintenance.

Option B: ID 1 is incorrect because the CLI output explicitly identifies the switch connected to port 2a of node n2 as Domain ID 20 rather than Domain ID 1.

Option C: ID 2 is incorrect because Domain ID 2 does not correspond to the switch domain connected to port 2a of node n2 in the provided output.

Option D: ID 10 is incorrect because Domain ID 10 represents a different switch fabric domain in the environment, not the domain attached to port 2a of node n2.

- NetApp ONTAP 9 Documentation, "network fcp adapter show command reference", Network Management Guide, Section: Fibre Channel Configuration.

- NetApp SAN Configuration Guide, "Troubleshooting FC Target Adapter Connectivity and Fabric Zoning", Section 4: SAN Fabric Diagnostics.