NCP-BC Practice Questions

The Zero Compute configuration in NC2 DR maintains only storage resources without active compute, requiring manual intervention to restore workloads during failover. MST (Migrate, Synchronize, and Transform) is specifically designed for AHV-based workloads and doesn't support ESXi VMs, creating a significant workload compatibility limitation when designing DR strategies for heterogeneous environments.

B. MST DR and Cluster Protect are independent features that don't require simultaneous configuration.

C. Zero Compute by definition cannot support automated failover due to lack of compute resources.

D. Protection policies typically establish one-to-one relationships between source and target clusters.

- Nutanix NC2 on AWS Administration Guide, Chapter 7: Disaster Recovery, Section "Zero Compute DR Configuration," pp. 142-145

- Nutanix MST Technical Reference Guide v6.5, Section 3.2: "Supported Workload Types," p. 28

- Nutanix Cloud Clusters Best Practices Guide, Section 4.3: "DR Configuration Options," pp. 67-71

Nutanix DRaaS (formerly Xi Leap) is designed for operational efficiency and cost-effectiveness. When a failback operation from the Nutanix Cloud AZ to the on-premises site is completed, the temporary resources created in the cloud for the failover, such as virtual networks, are no longer needed. The service automatically de-provisions and cleans up these resources. This automated cleanup prevents unnecessary resource consumption and associated costs in the cloud environment, ensuring the tenant only pays for what is actively in use.

A. The networks are temporary for failover/testing purposes and are not intended to be converted into permanent production networks.

C. The process is automated to reduce administrative overhead; manual deletion is not the standard behavior for these dynamically created resources.

D. Billing is based on resource consumption; resources are removed when no longer required, not kept active for an entire billing cycle.

1. Nutanix DRaaS Administration Guide, "Failback", Section: "Failback Cleanup". The documentation states that after a successful failback, the Nutanix Cloud Services portal automatically cleans up the VMs and associated network configurations that were provisioned during the failover.

2. Nutanix University, "Nutanix Business Continuity and Disaster Recovery (NCP-BC) 6.5", Module 5: Disaster Recovery with Nutanix Cloud Services, Lesson: Failover and Failback. The course material describes the lifecycle of resources in a DRaaS failover, highlighting the automatic cleanup post-failback.

Nutanix Volume Groups provide block storage to VMs and external clients using the iSCSI protocol. For the iSCSI service to function, a Data Services IP address must be configured on the cluster. This IP address serves as the discovery portal and data endpoint for iSCSI initiators. In a disaster recovery scenario, if the destination cluster lacks a configured Data Services IP, the iSCSI targets for the replicated volume groups cannot be brought online. Consequently, the VMs will failover, but the iSCSI initiators within them cannot connect to their VGs, leaving them unattached.

A. Nearsync replication does not support volume groups: This is incorrect. Nearsync, Asynchronous, and Synchronous replication all support the protection of Volume Groups.

C. The recovery plan has not been validated: The scenario explicitly states that the "Recovery plan validation completes successfully," ruling this out as the cause of the issue.

D. The hypervisor management interfaces are not on the same subnet: This is not a prerequisite for DR or Volume Group functionality. Clusters in different sites are expected to be on different subnets.

1. Nutanix Volumes Guide, Version 6.8, "Prerequisites and Limitations", Section "Cluster-Level Prerequisites". This section explicitly states, "Configure a Data Services IP address in the cluster."

2. Nutanix Data Protection and Recovery with Prism Element Guide, Version 6.8, "Protection of Volume Groups". This section outlines the requirements for protecting VGs, which implicitly relies on the underlying Volumes service being correctly configured with a Data Services IP on both source and target clusters.

After a recovery-plan test or failover, Prism Central automatically generates an Execution Report that lists every step, its start/end timestamps, and status. This built-in report can be viewed or exported, providing leadership with the required timing details without additional tooling.

A. Events log holds only high-level events, lacks per-step timing granularity.

C. Intelligent Operations reporting focuses on capacity/performance, not DR workflows.

D. ncli shows summary state; it does not format a step-by-step timed report.

1. Prism Central Guide 2023.9, §“Viewing Recovery Plan Execution Reports”, p. 58-59.

2. Nutanix Data Protection & DR Guide v6.0, “Test a Recovery Plan” step 7 – “Review Execution Report”.

When VMs are removed from a protection policy after failover, their recovery points (snapshots) remain in storage, consuming space unnecessarily. These orphaned recovery points must be manually deleted to reclaim storage. Simply removing VMs from the protection policy doesn't automatically delete their associated recovery points, which continue to consume storage on both local and remote sites until explicitly removed.

A. Recreating the recovery plan doesn't address existing recovery points consuming storage.

B. Reconfiguring replication schedule only affects future replications, not existing recovery points.

D. Disabling Nearsync affects replication frequency but doesn't remove existing recovery points.

1. Nutanix Bible - Data Protection Section: Details recovery point management and storage implications (https://nutanixbible.com)

2. Nutanix AOS 5.20 Administration Guide - Chapter 12: Protection Domains and Disaster Recovery, pp. 234-237

3. Nutanix Best Practices Guide for DR - Section 4.3: Post-Failover Operations and Cleanup Procedures

4. Nutanix University Course Material - NCM Professional Certification: Module 8 - Data Protection and Recovery

5. Nutanix KB-7854: Managing Recovery Points After VM Removal from Protection Policies

When workloads fail over to NC2 on AWS, external traffic must reach them through AWS Elastic IPs that NC2 exposes as “Floating IPs.” Leap recovery plans can automatically assign the predefined Floating IPs; without them, VMs keep only their private subnet addresses and are unreachable from the Internet.

A. NC2 vSwitches already allow required traffic; promiscuous mode is unnecessary.

C. VPN is optional for private access; public reachability relies on Floating IPs instead.

D. A stretched L2 only maintains internal addressing; it does not provide public ingress.

1. Nutanix Cloud Clusters (NC2) on AWS Networking Guide v2.0, §5.1 “Using Floating IPs,” p.32-34.

2. Nutanix Leap for NC2 Administration Guide v1.1, “Creating Floating IP mappings,” p.15-17.

A schedule is the primary trigger for automated data protection within a Nutanix Protection Domain. It defines the Recovery Point Objective (RPO) and dictates when snapshots of the protected entities are taken. If a Protection Domain is created but no schedule is configured, the system will not automatically create new snapshots. Since replication is the process of sending these snapshots to a remote site, the absence of new snapshots means the replication process will never be initiated. This directly accounts for both symptoms described in the question.

A. The Protection Domain has no entities that are protected

The question explicitly states that the Protection Domain exists "with a VM," meaning it does contain a protected entity.

C. The remote site has no vStore mapping

A missing container (vStore) mapping would cause the replication job to fail, but it would not prevent the local snapshot from being created by its schedule.

D. Bandwidth throttling is set too low

Low bandwidth would slow down or cause replication to time out, but it would not stop the scheduled creation of the local snapshot.

1. Nutanix Data Protection and Recovery with Prism Element Guide (for AOS 6.5): In the "Asynchronous Replication" chapter, section "Configuring a Protection Domain (Async DR)", the procedure explicitly includes the step "To create a schedule for this protection domain to take snapshots, click New Schedule." This highlights that a schedule is a necessary component to initiate the snapshot and replication process.

2. Nutanix University - Nutanix Certified Professional - Business Continuity (NCP-BC) 6.5 Study Guide: In the section "Module 2: Data Protection," it details the configuration of Protection Domains. The guide emphasizes that a schedule must be created to define the RPO and trigger snapshots automatically. Without a schedule, only manual snapshots are possible, and no automated replication will occur.

3. Nutanix Bible by Steven Poitras: In the "Data Protection" section, under "Protection Domains," it is explained that "Protection Domains are configured with a schedule which defines the RPO." This confirms the schedule's role as the trigger for the entire data protection workflow, including snapshot creation and subsequent replication.

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 Nutanix AHV, data-at-rest encryption is applied to VMs through storage policies that are linked to categories. When a VM is failed over to a recovery AZ, its association with the original category might be lost, or the corresponding encryption policy may not be correctly applied at the destination. To ensure newly written data is encrypted, the administrator must perform the post-failover task of reassigning the VM to the correct category that is linked to an active encryption policy on the recovery cluster.

A. Replication traffic encryption protects data in-flight between clusters. The issue described is with data at-rest on the storage of the recovery cluster after failover.

C. The replication schedule (RPO) determines how frequently data is replicated. It has no control over the data-at-rest encryption status of a VM post-failover.

D. Recreating the entire recovery plan and categories is an unnecessarily disruptive and drastic step. The issue can be resolved by simply re-associating the existing VM with the correct policy.

1. Nutanix Disaster Recovery Guide v6.8, "Failing Over Encrypted VMs." This section details the process and notes that for encryption to be active post-failover, the VM must be associated with a category linked to an encryption policy at the recovery AZ.

2. Prism Central Guide v2023.4, "Data-at-Rest Encryption for a VM (AHV)." The documentation specifies, "You can enable encryption for a VM by attaching the VM to a category. The category must be associated with an encryption-enabled protection policy."

During a planned failover, the system's objective is to achieve zero data loss (RPO=0). To accomplish this, Nutanix Disaster Recovery first gracefully powers off the guest VM at the source location. After the VM is powered off, it takes one final, consistent recovery point (snapshot), replicates it to the recovery location, and then powers on the VM at the recovery site using this newly replicated data. This ensures all in-flight data is captured.

A. This is incorrect. A new recovery point is always created during a planned failover to ensure zero data loss. Using the last replicated point is characteristic of an unplanned failover.

B. The recovery point is taken after the VM is powered off to ensure a consistent state, not while it is powered on.

C. The process is optimized to take only one final, consistent recovery point after the VM is powered off, not two separate ones.

1. Nutanix Disaster Recovery Guide v6.0, Chapter: Protection and Recovery with Nutanix Disaster Recovery, Section: Planned Failover. "When you initiate a planned failover... The system powers off the guest VMs gracefully at the source location... The system takes a new recovery point of the entities, replicates it to the recovery location..."

2. Nutanix University, Nutanix Certified Professional - Business Continuity (NCP-BC) 6.5, Module 4: Disaster Recovery Runbooks, Lesson: Recovery Plan Workflows. The courseware describes the planned failover process as shutting down the source VM before taking and replicating a final snapshot.