Storage Admin HubConfiguration · Protection · Recovery
All guides/Interview Q&A
Interview Q&A · ONTAP 9

NetApp interview: expert architecture scenarios

Ten design and incident questions on multi-site DR, mixed protocols, cloud migration and automation.

Scenario

Expert answers should show tradeoffs, assumptions, failure domains and evidence. There is rarely a single correct command; explain how you would make the decision and prove the design in a rehearsal.

Before you change production

Commands and screens can differ by release and platform. Replace example names and documentation IP addresses. Check prerequisites, impact, current health and rollback with your change owner.

1. Design DR for an application with data and logs on separate volumes.

  1. Start with agreed RPO/RTO and application write-order requirements. Identify every dependency: data, logs, configuration, database services, identity, DNS, network, host mapping and startup order. An asynchronous volume relationship per component can have different last recovery points; coordinate application-consistent points through an appropriate backup or consistency mechanism.
  2. Place replicas in a separate failure domain with enough capacity. Rehearse source write freeze, final transfer when possible, destination activation, host presentation and application transaction. Test failback direction and document the risk of resync discarding writes from the wrong side.
Verify

A complete application transaction is recovered within measured RPO/RTO, not just several readable volumes.

2. Choose between volume SnapMirror, SVM DR and MetroCluster.

  1. Volume SnapMirror protects selected volumes and requires explicit destination SVM, protocol, share/export and client planning. SVM DR can replicate an SVM’s data and supported configuration under release and identity-preserve constraints. MetroCluster is a site availability architecture with its own hardware, network, switchover, healing and switchback procedures.
  2. Map each option to application scope, sites, distance/latency, consistency objective, operational skills and budget. A two-site design is not automatically zero RPO or zero downtime. Verify version compatibility and test the exact failure mode before stating an RTO.
Verify

The choice includes a tested failure-domain and failback story.

3. Plan a 100 TB multiprotocol NAS migration with 50 million files.

  1. Inventory namespaces, file count, change rate, source security styles, Windows/UNIX name mapping, link/ACL fidelity, snapshots and unusual paths. For an ONTAP-to-ONTAP target such as FSx for ONTAP, SnapMirror block replication can avoid file-by-file traversal during baseline; for a target with different semantics such as Azure Files, use file copy or Storage Mover and expect metadata compatibility checks.
  2. Pilot representative small-file and large-file trees, benchmark initial and final delta duration, and build a per-share cutover list. Preserve AD/LDAP identities, create target share/export policies and keep exactly one writable production namespace. Reconcile post-cutover changes before any rollback.
Verify

Pilot predicts the full timeline and explicitly lists any metadata or permission gap.

4. A two-node HA pair is healthy, yet an entire application fails when one switch dies.

  1. “HA healthy” only proves controller takeover readiness; it does not guarantee switch, VLAN or host redundancy. Map every application path: client NIC or HBA, switch fabric, target/data LIF, controller, aggregate, remote identity service and replication route. Identify both physical connections that secretly share the failed switch.
  2. Check surviving host paths and LIF location, switch VLANs or FC zones, SLM reporting nodes and client reconnection behavior. Correct the topology and rehearse single-component failures one at a time. Update operational diagrams and acceptance evidence.
Verify

The application continues transactions through each tested single-switch failure.

5. How would you secure administrator access and recovery points?

  1. Use named accounts, least-privilege RBAC, MFA or supported federated authentication, restricted management networks, audit logging and controlled break-glass access. Separate people who operate volumes from those who can delete recovery points. Use multi-admin verification for designated destructive operations where supported.
  2. Create recovery copies in distinct failure domains and use supported retention or snapshot-locking features after testing restore and key dependencies. A locked snapshot can still be useless if the application data is inconsistent, the offsite copy is absent or no one knows the restore procedure.
Verify

A drill proves recovery by a designated operator and logs the administrative approval path.

6. How do you automate provisioning without duplicating work?

  1. Treat an API response as the start of a workflow. Discover the existing SVM, volume or LUN by stable identifier; validate desired properties, capacity and policy; create only what is missing; then poll asynchronous job completion. A 202 Accepted or a CLI queued job is not proof that the object is ready.
  2. Use scoped API roles, secret storage and idempotent change logic. After the job succeeds, verify the service from a client or host and record the resulting UUID, path and request ID. If a step fails, leave a clear partial-state record rather than blindly retrying create.
Verify

A second run makes no duplicate object and reports the same verified desired state.

7. Explain a zero-downtime claim for a storage upgrade.

  1. Nondisruptive upgrade means the supported cluster and host protocol stack are designed to keep I/O running through sequential node work. It is conditional on healthy HA, supported paths, correct host timeout/multipath, capacity and application tolerance. It does not guarantee that every workload experiences zero pause.
  2. Run automated prechecks, record an application baseline, align host support and a change window, then monitor real client I/O during and after each node stage. State measurable success criteria and an escalation plan for a failed takeover or host-path issue.
Verify

The business owner accepts measured behavior rather than an unqualified promise.

8. Your DR destination is behind the RPO during a network outage. What do you do?

  1. Report the last complete recovery point and projected exposure immediately. Check all intercluster LIF connectivity, routes, firewall, available bandwidth, transfer errors and the change rate. Do not run repeated baseline initializations or delete common snapshots without understanding the relationship.
  2. After service returns, prioritize affected applications, possibly throttle lower-priority jobs and monitor catch-up time. If an emergency failover happens before catch-up, choose the last consistent point and record the known data-loss window. Update the network redundancy and alert threshold after incident review.
Read-only checks 
cluster peer show
network interface show -role intercluster
snapmirror show -fields health,lag-time,last-transfer-error
Verify

Stakeholders know actual recoverable time and the relationship later returns inside RPO.

9. An Azure or AWS migration is technically complete; what is missing?

  1. Confirm identity and client semantics, not only byte count. For FSx for ONTAP, recreate or verify SVM-level shares, exports, AD and client endpoint paths around SnapMirror. For Azure Files, verify RBAC share roles plus NTFS ACLs or NFS network/UID permissions; platform capabilities differ from ONTAP.
  2. Set backups, snapshots, DR, capacity and cost alerts, audit ownership, support escalation and application acceptance. Keep old source frozen until a stabilization period and a safe reversal decision have passed.
Verify

The target is operable and recoverable with named owners and accepted service levels.

10. How do you explain a dangerous change you would refuse?

  1. Example: an operator wants to delete all snapshots to free capacity during a production incident. First explain that snapshots may be shared with SnapMirror or retention, deletion may reclaim little space, and it removes recovery options. Gather volume/aggregate physical metrics and dependencies, then propose a measured capacity expansion or targeted approved cleanup.
  2. An expert answer is specific: identify the expected effect, the evidence that would justify it, the approval owner and a safer alternative that resolves the immediate user impact. Protect the rollback path until the application owner accepts recovery.
Verify

The corrective action restores service while preserving required recovery points.

NetApp references