Free NCP-BC Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

When using Nearsync replication (1-minute RPO), the system prioritizes the performance of the primary workload. If the network bandwidth is insufficient to sustain the data change rate, the system will not pause or degrade production I/O. Instead, it automatically and temporarily switches the replication schedule to a 60-minute RPO (Asynchronous mode) to alleviate network congestion. Once the network can support the required rate again, it will attempt to resume the 1-minute RPO schedule. This ensures business continuity without impacting the source application's performance.

A. The system prioritizes write I/O performance on the primary cluster; it will not degrade it. Instead, it adjusts the replication schedule.

C. A failover is a manual or automated disaster recovery invocation, not a response to network bandwidth limitations for replication.

D. Pausing all write I/O would halt the protected application, which is a more severe impact than a temporarily increased RPO.

1. Nutanix University. (2023). Nutanix Business Continuity and Disaster Recovery (BCDR) 7 Courseware. Section: Nearsync Replication. "If the available network bandwidth is not sufficient for the current change rate, the RPO automatically increases to 60 minutes to allow the replication to catch up."

2. Nutanix. (2023). Prism Central Guide v2023.3. Section: Data Protection with Nearsync Replication. "If the network bandwidth is insufficient to meet the 1-minute RPO, Nutanix Disaster Recovery automatically switches to the next-best RPO (one hour) and alerts the administrator."

After a synchronous replication failover, VMs may be running on one site while their storage container remains active on the original site. This forces I/O traffic to traverse the inter-site link, causing high latency. Manually promoting the storage container on the new active site realigns the storage location with the compute (VM) location. This re-establishes data locality, ensuring I/O operations are served locally and restoring optimal performance.

A. Snapshot retention periods are related to data protection schedules and space consumption, not real-time I/O performance or data locality.

C. Reconfiguring the replication schedule affects how often data is synchronized, not the performance of I/O for already-failed-over VMs.

D. Acropolis Dynamic Scheduler (ADS) balances workloads within a cluster. It does not manage data locality across different sites in a metro configuration.

1. Nutanix Prism Element Data Protection and Recovery Guide (AOS 6.7), Chapter: Metro Availability for AHV and ESXi, Section: Planned Failover Scenario for Metro Availability. The documentation states: "To re-enable the protection domain on the promoted site... This step ensures that the writes are local to the site." This action realigns storage and compute.

For a Nutanix Metro Availability configuration, the Witness VM is a crucial component that acts as a tie-breaker during failure scenarios to prevent a split-brain condition. While the round-trip time (RTT) between the two data sites must be less than 5ms, the latency requirement for communication between the data sites and the Witness VM is less stringent. The maximum supported RTT between a Metro Availability Protection Domain (PD) and the Witness VM must be less than 200ms.

A. 5ms is the maximum RTT allowed between the two data sites in a Metro Availability cluster, not to the Witness VM.

B. 100ms is a possible latency but is not the maximum supported limit; the configuration is supported up to 200ms.

D. 500ms exceeds the maximum supported latency, which would cause instability and potential failure of the Witness mechanism.

1. Nutanix. (2023, December 14). Metro Availability Witness Guide v6.8. Section: Witness VM Requirements and Recommendations. "The round-trip latency between a Metro Availability cluster and the Witness VM must be less than 200 ms."

2. Nutanix University. (2023). Nutanix Business Continuity and Disaster Recovery (NCP-BC) 6.5. Module: Metro Availability. "The Witness VM can be located at a third site, with a maximum RTT of 200 ms from the primary and secondary sites."

3. Nutanix. (2023, December 14). Data Protection and Recovery with Prism Element v6.8. Section: Metro Availability Requirements. "Round-trip latency between a metro cluster and the witness VM must be less than 200 ms."

Self-Service Restore is provided through Nutanix Guest Tools; the NGT agent inside the VM exposes snapshot file catalogs and mounts them for end-user recovery. Prism disables the Self-Service Restore toggle until NGT has been installed and enabled, so no other component (drivers or VSS scripts) is sufficient.

A. PostThaw Scripts – Only optional VSS scripts; not a prerequisite for enabling SSR.

C. PreFreeze Scripts – Same as above; unrelated to the SSR toggle.

D. VirtIO – Paravirtualized drivers for disks/network, does not activate SSR.

1. Nutanix Guest Tools Guide v6.5, “Enable Self-Service Restore”, p. 8.

2. Prism Central Admin Guide 2023.9, §“NGT-based Self-Service Restore”, para 1.

For an on-premises Nutanix cluster to establish a connection and replicate data to a Nutanix Cloud AZ, it must be able to communicate with the public endpoints of the cloud service over the internet. This requires the on-premises cluster's Controller VMs (CVMs) to have a configured external IP address or be behind a Network Address Translation (NAT) gateway that provides outbound internet access. Without this external connectivity, the initial pairing and subsequent replication traffic from the on-prem AZ to the cloud AZ cannot be established, leading to an immediate failure.

A. Nutanix DR supports cross-hypervisor replication (e.g., ESXi on-prem to AHV in the cloud), so identical hypervisors are not a prerequisite.

C. Data efficiency settings like deduplication are generally compatible with replication and would not cause a fundamental connection failure.

D. Synchronous replication is not supported for DR to a geographically distant cloud AZ due to its strict low-latency requirements. Asynchronous replication is used instead.

- Nutanix Disaster Recovery Guide v6.0, Chapter: "Availability Zone and Network Connection Setup", Section: "Setting Up a Nutanix Cloud AZ as a Recovery AZ". The guide explicitly lists as a prerequisite: "Configure an external IP address for the on-prem cluster."

- Nutanix Cloud Services - Disaster Recovery Onboarding and User Guide, Section: "Prerequisites". This document outlines the networking requirements, including the need for the on-prem cluster to have internet access to communicate with the Nutanix Cloud control plane.

The error message "Failed to connect to remote Anduril" indicates a failure in the communication path between the Nutanix Controller VMs (CVMs) on the primary and remote clusters. Anduril is a core component of the Nutanix Distributed Storage Fabric (DSF). For synchronous replication to establish and maintain a "Sync" state, CVMs across both sites must communicate directly. In modern Nutanix AOS versions (5.11 and later), this CVM-to-CVM synchronous replication traffic uses TCP port 2036. This port must be open in any firewalls between the two clusters.

A. Port 2009 is used for iSCSI traffic within the Nutanix cluster and is not the primary port for inter-cluster synchronous replication data.

B. Port 2010 is not a standard port used for Nutanix synchronous replication communication between CVMs.

C. Port 2020 was used for synchronous replication in older Metro Availability configurations that included a witness, but it has been superseded by port 2036.

1. Nutanix Security Guide (release-security-guide-2023.3), Section: Port Reference, Subsection: Nutanix Disaster Recovery Ports. The table explicitly lists TCP Port 2036 for "Synchronous Replication" with the source being a CVM and the destination being a CVM on the remote cluster.

Port 2020 is essential for inter-cluster replication in Nutanix environments as it facilitates Stargate-to-Stargate communication. When this port is blocked, the replication process can initiate (showing as "ongoing") but cannot transfer data, resulting in stuck replication with unchanging byte counts. This matches the exact symptoms described where other connectivity appears normal but data transfer is frozen.

A: Acropolis down would prevent replication from showing as ongoing and VIP wouldn't be reachable.

B: Policy misconfigurations typically cause immediate failures or prevent replication start, not stuck transfers.

D: Port 2030 blockage wouldn't affect core replication data transfer between Stargate services.

1. Nutanix Bible - Replication Architecture, Section 4.3, describes Stargate-to-Stargate communication using port 2020

2. Nutanix Port Reference Guide v6.5, Page 12-13, lists port 2020 as required for inter-cluster replication

3. Nutanix AOS Security Guide, Section 3.2, details firewall requirements for cluster replication

4. Nutanix Best Practices Guide - Disaster Recovery, Chapter 5, outlines network requirements for replication

5. Nutanix Troubleshooting Guide v6.x, Section 8.4, covers replication issues related to network connectivity

Nearsync replication, which provides a Recovery Point Objective (RPO) between one and fifteen minutes, has a minimum cluster size requirement. To enable and successfully configure a Nearsync schedule, the source Nutanix cluster must consist of at least three nodes. This requirement is based on the architectural design of how Nearsync manages and drains the oplog across the cluster nodes to achieve low RPOs reliably. A two-node cluster does not meet this minimum node count prerequisite, and therefore, the option to configure a Nearsync schedule will be unavailable or fail.

B. The minimum supported RPO for asynchronous replication on a two-node cluster is 60 minutes, not 15 minutes.

C. Nearsync replication is fully supported on both All-Flash and hybrid (SSD+HDD) Nutanix clusters, although performance is best on All-Flash.

D. A Witness VM is required for quorum and metadata management in a two-node cluster, but it does not enable Nearsync replication capabilities.

1. Nutanix Disaster Recovery Guide v6.8, "Data Protection with Nearsync Replication", Section: "Nearsync Requirements and Limitations". This section explicitly states, "The source cluster must have at least three nodes."

2. Nutanix University, "Nutanix Data Protection and Disaster Recovery (DPDR) 6.5", Module: "Asynchronous, Nearsync, and Synchronous Replication". The courseware lists the prerequisites for Nearsync, including the three-node minimum for the source cluster.

The Activate operation makes the DR copy of the Protection Domain the active copy.

To return service to the production cluster you must:

1) De-activate the PD on the DR cluster (this unlocks the source PD and stops replication from the DR side) and

2) Destroy the test VMs that were brought online on the DR cluster.

These steps clean up the DR site and re-establish normal protection flow to production.

A. Re-activating on production does not release the active PD on DR or remove test VMs, leaving both sites in conflict.

B. De-activating on production removes protection from the source and deletes production workloads—opposite of requirement.

C. Deleting VMs alone leaves the PD active on DR, so replication cannot resume to production.

1. Nutanix Data Protection & Disaster Recovery Guide, AOS 6.5, “Activating and De-activating Protection Domains”, p. 140-142.

2. Nutanix University – NCP-BC Courseware, Module 6 “Test/Cleanup Failover”, slide 17.

A test failover is a non-disruptive operation designed to validate a recovery plan's configuration. It brings up copies of the protected VMs in a sandboxed network at the recovery site using existing replicated snapshots. This process verifies that VMs can be recovered and that network mappings are correct without affecting the running production workloads at the primary site. The primary goal is to ensure recoverability and readiness for a real disaster scenario.

A. Copying data is part of the ongoing replication process defined by the protection policy, not the primary goal of the test failover action itself, which uses already-replicated data.

B. This describes a planned or unplanned failover, which is a production-impacting event that moves workloads, not a non-disruptive test.

D. Disabling replication is a separate administrative task, typically done for maintenance, and is not a goal or part of a test failover.

1. Nutanix University, Nutanix Certified Professional - Business Continuity (NCP-BC) 6.5, Module 4: Disaster Recovery Runbooks, Lesson: Recovery Plan Workflows.

2. Nutanix Disaster Recovery Guide v6.0, Chapter: Recovery Plan Management, Section: Performing a Test Failover. "You can perform a test failover to validate a recovery plan. A test failover is a non-disruptive test. It does not impact the primary site."

When a Recovery Plan orchestrates a failover of VMs using Volume Groups (VGs) with in-guest iSCSI attachments, the plan ensures the VG data is replicated and made available on the recovery site. However, the DR orchestration does not automatically re-establish the iSCSI session inside the guest operating system. After the failover, the VM powers on, but the iSCSI initiator within the guest OS is still configured with the old site's iSCSI target information. An administrator must manually or via script re-scan and reconnect the iSCSI initiator to the new target IP at the recovery site to bring the database volumes online.

A. The failover task completed successfully, which indicates that replication was configured and working correctly.

C. Volume Groups are fully supported entities for protection and recovery within Nutanix Recovery Plans.

D. A missing storage network mapping would likely cause the failover orchestration itself to fail, not succeed with an offline database.

- Nutanix Disaster Recovery Guide v6.0, Chapter: "Recovery Plan Management", Section: "Volume Group Recovery". The guide notes that for VGs attached using in-guest iSCSI, you must manually re-establish the connection from within the guest OS after a failover.

SR-IOV provides VMs with direct access to physical NIC hardware, a configuration that is specific to the host. During a failover to a recovery site, the specific physical hardware cannot be guaranteed to be present or available. To ensure the VM can successfully start and have network connectivity, Nutanix Disaster Recovery automatically replaces the SR-IOV virtual NIC with a standard, hypervisor-based virtio-net adapter. As part of a planned failover, the VM is then powered on to restore service, albeit without the performance benefits of SR-IOV.

A. In a planned failover, the goal is to resume operations, so VMs are powered on. Leaving them powered off would defeat the purpose of the recovery plan.

B. The SR-IOV configuration is tied to the source host's physical hardware and is not transferred or guaranteed to exist on the recovery cluster hosts.

D. Nutanix DR is designed to handle VMs with SR-IOV. It does not fail the recovery process but instead gracefully reverts the NIC to a compatible virtual adapter.

1. Nutanix Prism Central Disaster Recovery Guide (pc.2023.4), "Entity Support and Limitations" section, subsection "VMs with SR-IOV". The documentation states: "You can protect the VMs with SR-IOV enabled. At the recovery AZ, the recovered VMs have the SR-IOV NICs replaced by standard NICs."

Planned Failover performs a controlled, graceful migration that fully synchronizes protected VMs, powers them on at the recovery cluster, and optionally shuts them down on the source. Because the target VMs are already running before the maintenance begins, no downtime is seen when the primary network is taken offline.

A. Unplanned Failover starts immediately without final sync and is intended for unexpected outages, risking data loss and VM pause.

C. Validate Recovery Plan only checks configuration; it does not power on VMs at the target.

D. Test Failover isolates recovery VMs in a fenced network for validation, not for production continuity.

1. Nutanix Data Protection & Disaster Recovery Guide v6.5, “Performing a Planned Failover”, p. 132–134.

2. Nutanix University NCP-BC Courseware Module 5, “Failover Types and Use-Cases”, slide 18.

3. Nutanix Leap Admin Guide v6.5, section 6.3.1 “Planned vs. Unplanned Failover”.

In a Nutanix multisite DR configuration, a Protection Policy defines what VMs are protected and where their snapshots are replicated (e.g., to AZ1 and AZ2). However, a Recovery Plan defines the orchestration, boot order, and network mappings for failing over a specific set of VMs to a single, specific recovery AZ. To be able to fail over to the second recovery AZ, a separate and distinct Recovery Plan targeting that second AZ must be created. The inability to select the second AZ as a target indicates that no Recovery Plan has been configured for it.

A. Missing IP mapping would cause networking issues after failover is initiated but would not prevent the selection of a correctly configured Recovery Plan.

C. The snapshot retention count determines how many recovery points are available, not whether a site can be selected as a failover target.

D. The replication type (synchronous, asynchronous, etc.) does not restrict the creation of a Recovery Plan for a valid replication target.

1. Nutanix Prism Central Disaster Recovery Guide (pc.2023.4), "Recovery Plan Management". The documentation states: "A recovery plan orchestrates the recovery of protected VMs at a recovery AZ... A recovery plan specifies the recovery AZ." This implies a one-to-one mapping between a recovery plan and a target AZ. To target a second AZ, a second plan is needed.

Nutanix Disaster Recovery allows for failing over virtual machines between sites with different network configurations. The Recovery Plan is the orchestration entity where you define how VMs are recovered. A key feature within the Recovery Plan is Network Mapping, which allows an administrator to map a source network (at the production AZ) to a different target network (at the recovery AZ). During failover, the recovered VMs' network interface cards (NICs) are automatically connected to the specified target network.

A. A local-only schedule in the protection policy: Local schedules are for creating snapshots that remain at the primary site and are not replicated; they are irrelevant to failover networking at a remote site.

B. A new protection policy with synchronous replication: The replication type (synchronous, nearsync, or async) determines the RPO but does not solve the issue of mismatched network subnets between sites.

D. A required matching subnet name at the recovery AZ: While possible, it is not a requirement. The system is designed to handle dissimilar network configurations through explicit network mapping in the recovery plan.

1. Nutanix Disaster Recovery Guide v6.8, "Creating a Recovery Plan" section. The guide details the steps for configuring a recovery plan, including "Specify Network Mappings for Recovery AZ". It states: "You can create new mappings or use existing network mappings for the source and recovery AZs."

2. Nutanix University, "Nutanix Business Continuity and Disaster Recovery (NCP-BC) 6.5" courseware, Module 4: Nutanix Disaster Recovery. The module explains that network mappings in a recovery plan are used to connect VMs to appropriate networks at the recovery site, which may be different from the source site.

Nutanix VM replication requires every source storage container to be mapped to a destination container. The Linux VMs succeed because their source container has an existing mapping on the remote cluster, whereas the Windows-based Marketing VMs reside in a container that has no mapping. In that circumstance, Prism blocks replication even though network connectivity, free capacity, and scheduling parameters are all valid.

B. Replication mode (Async vs NearSync) does not influence whether a container is addressable on the target; mode changes merely affect RPO.

C. Cluster capacity is reported healthy; a missing mapping—not lack of space—prevents the transfer.

D. Linux VMs replicate successfully, proving that the replication mode in use is not the root cause.

1. Nutanix Data Protection & Disaster Recovery Guide v6.5, “Container Mapping Requirements,” p. 37-38.

2. Nutanix Prism Web Console Help, “Create Storage Container Mapping,” Section 8.3: “Replication fails if the source container is not mapped.”

3. B. Selvaraj & G. Subramanian, “Advanced DR with Nutanix,” Proc. VMworld 2022, slide 16.

Nutanix backup tools connect to each new node’s CVM via iSCSI. Discovery occurs on TCP 3205 (Stargate discovery) and data transfer on the standard iSCSI port 3260. If these two ports are blocked to the newly added nodes, iscsiadm discovery times out and every backup that mounts the vDisk fails.

A. 3502/3620 are used by Nutanix Files, unrelated to image-level backups.

B. 3202/3206 are internal replication/control channels, not iSCSI.

C. 3302/3360 are support and LCM ports, not used for backup disk export.

1. Nutanix Port Usage Reference Guide v6.5, Table 2-7 “Stargate iSCSI,” p.18.

2. Nutanix AHV Backup Facilities Guide v6.5, §4.2 “iSCSI Export Workflow,” p.37.

After an unplanned failover, replication is automatically reversed so AZ2 now protects AZ1. Failback therefore requires that recovery points exist on AZ1—either newly replicated ones (C) or any snapshots that still reside locally from before the outage (B). If either set is available, the same recovery plan can be used to return workloads.

A. Failback is initiated from the current recovery site (AZ2), not from AZ1.

D. New recovery points coming from AZ2 are sufficient; pre-outage snapshots on AZ1 are not strictly required.

1. Nutanix Data Protection & Disaster Recovery Guide v6.5, §9.4 “Unplanned Failover Workflow,” p.298-301.

2. Same guide, §9.6 “Failback Requirements and Reverse Replication,” p.305-307.

For Nutanix Disaster Recovery, paired Prism Central instances manage the disaster recovery configuration, including protection policies and recovery plans. This management communication between the two Prism Central availability zones (AZs) occurs over TCP port 9440. This port must be open bidirectionally to allow for initial pairing, subsequent configuration synchronization, and orchestration of failover and failback operations.

A. 2009: This port is used for communication between Controller VMs (CVMs) within a cluster for data replication, not for Prism Central to Prism Central management.

B. 2020: This port is used for communication between CVMs for configuration tasks, not for inter-Prism Central communication.

C. 2074: This port is used specifically for the Nutanix DRaaS (Xi Leap) VPN gateway connection and is not required for DR between two on-premises Prism Central instances.

1. Nutanix Port and Protocol Reference v2.6, "Prism Central Based Disaster Recovery (DR)" section, Page 11. The table specifies that for communication between a source Prism Central and a remote Prism Central, TCP port 9440 is required.

2. Nutanix Disaster Recovery Guide v6.8, "Prerequisites for Disaster Recovery Between On-Prem AZs" section. It states, "Ensure that the Prism Central instances at both the primary and recovery AZs can communicate with each other over the port 9440."

Nutanix Self-Service Restore (SSR) enables end-users to recover their own files from VM snapshots. For the SSR tool to successfully mount a snapshot disk inside the guest OS, the VM's virtual disks must be attached to a supported controller. SSR supports virtual disks attached to either a SCSI or an IDE controller. The SSR agent attaches a clone of the vDisk from the snapshot to the VM, and these are the only two controller types supported for this operation.

C. PCI: PCI is a peripheral component interconnect bus standard, not a virtual disk controller type like SCSI or IDE in the context of VM disk configuration.

D. VGs: Volume Groups (VGs) are a Nutanix Volumes feature for providing block storage to external clients or in-guest iSCSI and are not used for standard VM disks that SSR manages.

1. Nutanix University - Nutanix Data Protection and Recovery (NDPR) 6.5 courseware, Module 4: Self-Service Restore. The courseware specifies the prerequisites for SSR, including supported disk types.

2. Nutanix Data Protection and Recovery Guide v6.5, "Self-Service Restore (SSR)" section, under "Prerequisites and Limitations". It states: "SSR supports virtual machines with IDE and SCSI disks."