Free Practice Questions for Nutanix NCP-BC-7.5 Exam

VM-VM Anti-Affinity rules are used in Nutanix to ensure that specific virtual machines (such as the nodes of a database cluster or redundant web servers) never run on the same physical host, thereby protecting the application from a single host failure. These rules are typically managed through Prism Central (PC) in a modern deployment.

However, in the context of Disaster Recovery (DR) between two different clusters or availability zones, there is a technical limitation regarding the replication of these affinity policies. While the virtual machine ' s data and primary metadata (CPU, RAM, Disks) are replicated by the Cerebro service, the affinity rules are often considered local cluster constraints. In many versions of Nutanix Disaster Recovery (specifically the initial iterations of Leap/Prism Central-based DR), these affinity policies are not natively " synchronized " or enforced at the recovery site during a failover. This means that when the VMs are recovered at the destination cluster, the hypervisor ' s dynamic scheduler (ADS) may place them on the same host if that host has the most available resources. To maintain anti-affinity at the recovery site, an administrator would typically need to manually recreate the affinity policies at the destination AZ or use specialized orchestration scripts. Understanding this limitation is vital for ensuring that high-availability requirements are still met after a disaster recovery event has occurred.

Volume Groups (VGs) are used in Nutanix to provide block storage to virtual machines, often for high-performance applications like SQL Server. VGs can be attached to VMs in two ways: " In-guest " (using iSCSI initiators) or " Hypervisor-attached " (where the hypervisor handles the connection).

In a disaster recovery scenario managed by Recovery Plans, there is a technical distinction in how these attachments are handled. While Nutanix Disaster Recovery can replicate the data in the Volume Groups and recover the VM itself, VGs that are " hypervisor-attached " do not currently support automatic reattachment as part of the orchestration workflow in all AOS versions. When the failover completes, the VM powers on at the recovery site, but the VGs are not connected to the VM at the hypervisor level. This causes the application (SQL) to find its data disks missing, resulting in the database staying offline. To resolve this, the administrator must manually reattach the Volume Groups to the VM at the recovery site using the Prism interface or a script. This limitation highlights the need to verify specific application storage configurations during DR testing. For automated recovery of VGs, using " In-guest " iSCSI attachments is often preferred because the iSCSI initiator within the guest OS can re-establish the connection to the new cluster ' s Data Services IP once the network is active.

Migrating from legacy Protection Domain (PD) based management to the modern Prism Central (PC) based Protection Policies is a recommended best practice for scaling Nutanix Disaster Recovery. This migration involves moving VMs from a " Prism Element " centric management model to a centralized, category-based model in Prism Central.

To ensure that no data is lost during this transition, the most critical prerequisite is to verify that a successful, full replication (backup) of the Protection Domain has recently completed. This ensures that the recovery site already possesses a complete and consistent set of data for the VMs before they are unlinked from the old policy and attached to the new one. While adding VMs to a category (Option A) is a step in the process, it is not the first verification step required for data safety. If an administrator attempts to migrate while a replication is incomplete or failing, the transition to the new policy might leave the VMs unprotected for an extended period, or recovery points might be missing if a disaster occurs mid-migration. By completing a full backup of the PD first, the administrator creates a " safety net " of recovery points that can be used if the migration itself encounters issues. This ensures that the transition to modern DR is performed with minimal risk to the business ' s data protection objectives.

Migrating from legacy Protection Domains to modern Prism Central Protection Policies is a recommended practice for scaling DR management. However, large environments must account for architectural limits during this transition. A Nutanix cluster has specific maximum thresholds for the number of entities (VMs) that can be contained within a single Protection Domain, and similar limits exist for the initial " handoff " to Prism Central.

If a single legacy Protection Domain contains more than 500 VMs, attempting to migrate it as a single unit can lead to timeouts, metadata synchronization failures, and potential gaps in protection. To ensure that all VMs remain consistently protected during the migration, the first step is to " split " the existing large Protection Domain into multiple smaller, more manageable ones. For example, an administrator might split a 600-VM domain into three 200-VM domains. This reduction in " entity density " allows the Nutanix Cerebro and Prism Central services to process the migration tasks more efficiently without hitting resource contention or task timeout limits. Once the VMs are organized into these smaller groups, they can be systematically unlinked from the legacy domains and added to the new PC-based Protection Policies. This phased and controlled approach minimizes risk and ensures that a valid recovery point always exists for every VM throughout the entire migration lifecycle.

The " Test Failover " feature in Nutanix Disaster Recovery is a critical tool for ensuring that a BCDR plan is actually functional before a real disaster occurs. The primary goal of a test failover is to validate the entire recovery orchestration—including power-on sequences, script execution, and network mappings—in a completely non-disruptive manner.

During a test failover, the virtual machines are recovered at the destination site using the most recent snapshots, but they are typically connected to an " Isolated " or " Test " network. This allows the administrator to log into the recovered VMs and verify that the application starts correctly without causing any IP address conflicts or interference with the live production systems at the primary site. Unlike a " Planned Failover " or " Unplanned Failover, " a test failover does not move the production workload (negating Option B) and does not stop ongoing replication (negating Option D). It is purely a validation task designed to identify gaps in the Recovery Plan, such as missing dependencies or incorrect network assignments, thereby providing confidence that the organization ' s RTO and RPO goals can be met during a real emergency.

Nutanix Disaster Recovery offers several replication tiers to meet varying business Recovery Point Objectives (RPOs). NearSync replication is a specific technology designed to fill the gap between traditional Asynchronous replication and zero-RPO Synchronous replication.

NearSync replication supports a minimum RPO of 1 minute. It achieves this by using Lightweight Snapshots (LWS), which are highly efficient and can be taken much more frequently than standard full snapshots without causing significant I/O overhead on the system. While some versions of Nutanix software allow NearSync to reach RPOs as low as 20 seconds, the standard minimum RPO recognized in the context of the NCP-BC 7.5 evaluation for minutes-based intervals is 1 minute. Option A (0 RPO) is only achievable through Synchronous replication. Option C (15 minutes) is the typical maximum RPO for NearSync before it transitions to Async, and Option D (60 minutes) is the standard interval for Asynchronous replication. Understanding these thresholds is essential for administrators when designing protection policies for mission-critical workloads.

In a Nutanix Synchronous Replication or Metro Availability setup, data is mirrored in real-time, but the " intelligence " required to automate a failover resides outside of the two primary clusters. Without a Witness VM (Option C), the secondary cluster cannot distinguish between a total primary site failure and a simple network partition between the two data centers. If the clusters lose communication but there is no Witness to act as an independent tie-breaker, the secondary cluster will stay in a " Standby " state and will not automatically " promote " its storage to " Active " or power on the VMs. This is a safety mechanism to prevent " split-brain " where two clusters might try to serve the same data, leading to corruption. To enable automatic failover, a Witness VM must be deployed at a third, independent site and registered to both clusters. The Witness allows the secondary site to verify that the primary site has indeed failed; once verified, the Witness grants the " lock " to the secondary site, allowing the automated failover process to begin. Thus, the lack of a Witness is the " most likely cause " for why a failover test would fail to trigger automatically during a storage or site outage.

In a complex BCDR environment, replication failures that affect only a specific subset of virtual machines—while others on the same cluster succeed—usually point to a configuration mismatch rather than a general network or storage issue. Since the ports (2009 and 2020) are confirmed open and storage is available, the transport layer is functional. The fact that Linux VMs are succeeding while Windows (Marketing) VMs are failing suggests that the two groups may be mapped to different destination storage containers. In Nutanix replication, if a container mapping is explicitly set for one set of entities (the Linux VMs) but not for another (the Marketing VMs), the second group might be defaulting to a destination container that is either missing, misconfigured, or has restricted permissions. This specific scenario implies that the successful Linux VMs are benefiting from a correctly configured container mapping on the remote site, whereas the Marketing VMs are likely attempting to replicate to a location where mapping is invalid or non-existent. Troubleshooting this requires an administrator to verify the Prism Central container mapping settings to ensure that the storage targets for all protected categories are reachable and correctly associated with the destination storage pool.

When designing disaster recovery to a cloud environment (such as NC2 on AWS or Azure), organizations must choose a compute model that aligns with their Recovery Time Objective (RTO). The " Zero Compute " model is the most cost-efficient because it stores only the data (snapshots) in low-cost Object Storage (S3 or Blob) and does not maintain a running cluster. However, the RTO for Zero Compute is high because, in a disaster, the organization must first deploy a new Nutanix cluster, configure it, and then begin the process of hydrating data from the Object Storage.

In contrast, the " Pilot Light " model involves keeping a minimal, active Nutanix cluster (e.g., 3 nodes) running at the recovery site. While this carries a moderate ongoing cost, it significantly reduces the RTO. Because the cluster already exists, the management plane (Prism Central), the storage containers, and all metadata are already active. When a failover is triggered, the system only needs to power on the VMs or perform a small amount of data hydration. This allows the organization to meet aggressive RTO targets of under 15 minutes, which is generally impossible with the Zero Compute model. Pilot Light provides the " ready-to-go " infrastructure needed for mission-critical applications that cannot afford the multiple hours required to provision a fresh cluster from scratch during an emergency.