Nutanix NCP-BC-7.5問題集で必ず試験合格させる [Q66-Q87]

Nutanix NCP-BC-7.5問題集で必ず試験合格させる

NCP-BC-7.5試験問題（更新されたのは2026年）100%リアル問題解答

質問 # 66
An administrator has received the following alert:

Replication was skipped for protection domain < Protection Domain Name > of the latest snapshot < Snapshot ID > to remote site < Remote Cluster Name > . Replication was skipped as a newer Recovery Point was available snapshots that may have been skipped.
The administrator begins gathering troubleshooting information and determines the following:
* The VM has been replicating to this cluster successfully for at least 6 months
* The bandwidth has been sufficient to this point and hasn ' t caused an issue before
* Network connectivity is good and all necessary ports remain open and reachable
* There aren ' t hardware issues, and software is up to date
What else could have caused this alert?

• A. A new Availability Zone was paired to Prism Central.
• B. Protection Policy schedule was temporarily paused.
• C. The VM had a significant one-time surge in change rate.
• D. This was a first seed replication without a reference snapshot.

正解：C

解説：
The Nutanix Cerebro service manages replication by scheduling snapshots and transferring the delta changes to the remote site. In an asynchronous replication schedule, if a new snapshot is taken before the previous one has finished replicating, the system faces a choice. To ensure that the most current data is available at the recovery site as quickly as possible, Nutanix may " skip " the replication of an older pending snapshot in favor of starting the replication of the newest one.
In this scenario, all infrastructure components (bandwidth, ports, hardware) are verified as healthy and have supported successful replication for months. This points toward a data-level issue rather than a connectivity issue. A " significant one-time surge in change rate " (Option D) means the VM generated a massive amount of new data blocks (churn) in a short period. Because the " Snapshot-on-wire " transfer size is directly tied to the number of changed blocks, this specific snapshot would take much longer than usual to replicate. If the transfer time exceeds the RPO interval, the next scheduled snapshot will trigger. The Cerebro service will see that it has a newer recovery point ready to go and will skip the " stuck " or slow-moving older snapshot to maintain the most recent RPO possible at the target. This behavior generates the " Replication was skipped " warning to notify the administrator that the historical sequence was interrupted due to a temporary imbalance between data churn and available throughput.

質問 # 67
An administrator performs these steps while configuring Nutanix Disaster Recovery:
* Create VMs on Site A in a container named SalesA
* Create a new container on Site B named SalesB
* Create new Protection Policy name Async
* Place all the new Sales VMs in the Protection Policy named Async
* Set a schedule to begin taking hourly snapshots immediately
After performing the steps, replications begin without any errors. After two hours, the administrator checks on the progress on the remote site and finds that the SalesB container is showing 0 bytes.
What went wrong?

• A. The same name must be used at both sites.
• B. The schedule is a Nearsync schedule.
• C. The Sales VMs are unsupported for replications.
• D. Advanced Replication add-on license isn ' t applied.

正解：A

解説：
In a Nutanix Disaster Recovery environment using Protection Policies (Prism Central-based), the system needs to know which storage container at the recovery site should receive the replicated data from the primary site. This is known as " Container Mapping. " By default, Nutanix uses an " Automatic Container Mapping " feature to simplify administration.
The automatic mapping logic relies on matching names. If a VM is in a container named SalesA at Site A, the system will look for a container named SalesA at Site B to land the data. If the administrator manually created a container at the recovery site but named it SalesB (as in this scenario), the automatic mapping will fail because the names do not match. The system will instead attempt to find a container with the same name, and if it fails to find one, it may create a new one automatically or replication might fail. The fact that SalesB shows 0 bytes confirms that no data was ever sent to that specific container. To fix this, the administrator should either rename the destination container to match the source (SalesA) or manually configure a " Storage Container Mapping " in Prism Central that explicitly links the SalesA container on Cluster A to the SalesB container on Cluster B.

質問 # 68
An administrator at a retail company is preparing to apply a critical OS security patch to a production SQL Server VM. Before starting, the administrator ensures the VM is part of a Protection Domain and manually creates a local snapshot (Recovery Point). Ten minutes after the patch is applied, the SQL service fails to start, and the database logs indicate corruption in the system registry. The administrator needs to return the VM to its functional state from ten minutes ago as quickly as possible. The administrator decides to perform a Restore from the local snapshot. Under which condition would an In-place Restore (Revert) fail, forcing the administrator to use the Clone (Out-of-place) option instead?

• A. A new 50GB data disk was added to the VM configuration after the snapshot was taken.
• B. The VM is currently powered on and cannot be shut down.
• C. NGT (Nutanix Guest Tools) version was updated immediately after the snapshot.
• D. The VM ' s memory was increased from 16GB to 32GB to accommodate the patch installation.

正解：A

解説：
An In-place Restore (Revert) is the fastest way to roll back a VM because it overwrites the current vDisks with the data from the snapshot. However, this operation has strict requirements regarding the consistency of the VM ' s hardware configuration. The most common technical blocker for an in-place revert is a change in the disk topology between the time the snapshot was taken and the time of the restore.
If the administrator added a new 50GB data disk (Option D) after taking the snapshot, the VM ' s current configuration now includes a vDisk that does not exist in the snapshot ' s metadata. Nutanix AOS cannot " revert " a disk that has no point-in-time reference in the recovery point. In this situation, the " In-place Restore
" button is typically disabled or will throw an error, forcing the administrator to use the " Clone " (Out-of- place) option. Cloning creates a new VM based exactly on the snapshot ' s metadata, effectively ignoring the newly added disk. While changing memory (Option B) or NGT versions (Option A) might affect performance or guest features, they do not usually prevent the storage-level revert operation. Being forced into a " Clone " restore increases the RTO slightly, as the administrator must then delete the corrupted VM and ensure the new clone has the correct network settings.

質問 # 69
An administrator is migrating from a Protection Domain-based deployment to a Prism Central (PC)-based deployment. What occurs if a snapshot is deleted before the protection policy is applied to the migrated entities?

• A. PC pauses the migration until the snapshot is manually restored from a backup.
• B. PC automatically recreates the deleted snapshot using the new configuration.
• C. The migration will automatically fail and will revert all entities to the original Protection Domain.
• D. The recovery points associated with that snapshot won ' t be available for the deployment.

正解：D

解説：
Migrating from legacy Protection Domains to modern Prism Central Protection Policies involves transitioning the management of virtual machine snapshots. During this process, the historical snapshots created by the Protection Domain are often intended to be " claimed " or utilized by the new PC-based system as valid recovery points.
Snapshots are point-in-time references to data on the storage tier. If a snapshot is deleted from the cluster before the migration to Protection Policies is finalized, the underlying data blocks associated with that specific point in time may be reclaimed by the system ' s garbage collection process. Consequently, the recovery points that were associated with that deleted snapshot will no longer be available for use within the new deployment. The system cannot " automatically recreate " (Option A) a deleted snapshot because the exact historical state of the data is lost once the snapshot is purged. The migration itself typically continues for the remaining valid data, but the loss of historical recovery points could impact the business ' s ability to restore to specific past dates. This highlights the importance of data retention awareness during management-plane migrations.

質問 # 70
Which statement describes the automatic detachment timeout period for a snapshot disk mounted to a VM using the Nutanix Guest Tools (NGT) Self-Service Restore (SSR) feature?

• A. The disk will be automatically detached during the next scheduled Stargate background scan or Curator full scan (typically within 6 hours).
• B. The system enforces a built-in timeout; if the user does not manually detach the disk from the VM, it is detached automatically by the system after 24 hours.
• C. The snapshot disk will remain attached in read-only mode until the VM is rebooted.
• D. The disk remains permanently attached to the VM until an administrator manually detaches it via Prism.

正解：B

解説：
Self-Service Restore (SSR) is designed to be a temporary recovery operation. When a user uses the SSR agent to mount a historical snapshot disk, that disk is attached to the VM via the hypervisor ' s virtual controller.
While it is a best practice for the user to " unmount " and " detach " the disk once they have recovered their files, the Nutanix system includes a safety mechanism to prevent these temporary disks from being left attached indefinitely.
Nutanix enforces a built-in automatic detachment timeout of 24 hours. If a disk remains attached via the SSR workflow for longer than 24 hours, the Nutanix orchestration engine will automatically trigger a detachment task to clean up the VM ' s configuration. This is essential for maintaining cluster " hygiene, " as stale snapshots attached to VMs can interfere with future backup operations, prevent VM migrations (vMotion), or lead to unnecessary storage overhead if the snapshots are kept " locked " by the attachment. Understanding this 24-hour timeout helps administrators reassure users that they have a full day to perform their recovery tasks while ensuring the infrastructure team that the environment will automatically revert to a clean state without manual intervention. This balance of user flexibility and system automation is a hallmark of the Nutanix BCDR design.
Here are questions 81 through 100 from the Nutanix Certified Professional - Business Continuity (NCP-BC)
7.5 exam set, formatted strictly as requested with detailed technical explanations for each.

質問 # 71
An administrator recently expanded a Nutanix cluster by adding several new nodes. Shortly after, multiple backup jobs began failing. The following error is consistently reported: " Failed to perform backup: Cannot complete process ' iscsiadm --mode discovery --type sendtargets --portal X.X.X.X ' within timeout " . What is the most likely cause of the failure?

• A. Firewall ports 3502 and 3620 are missing to the new nodes.
• B. Firewall ports 3202 and 3206 are missing to the new nodes.
• C. Firewall ports 3302 and 3360 are missing to the new nodes.
• D. Firewall ports 3205 and 3260 are missing to the new nodes.

正解：D

解説：
Nutanix storage is often accessed by external backup solutions (like Veeam, Commvault, or HYCU) using the iSCSI protocol. This allows the backup server to mount snapshots and read data directly from the storage tier.
The error message " iscsiadm... discovery... timeout " specifically indicates that the backup server ' s iSCSI initiator is unable to communicate with the Nutanix Data Services IP or the Controller VMs (CVMs) over the network.
When a Nutanix cluster is expanded, it is essential that all networking and firewall configurations applied to the existing nodes are also applied to the new nodes. The iSCSI protocol relies on specific TCP ports: port
3260 is the standard port for iSCSI traffic, and port 3205 is often used for iSCSI discovery and metadata operations within Nutanix. If these ports are not open in the physical firewall or the host-based security rules for the newly added nodes, the backup server will be unable to discover the targets on those specific nodes, leading to the timeout errors . This highlights a common " Day 2 " operational trap: cluster expansion requires careful auditing of network security groups and firewall whitelists to ensure that external integrations- especially BCDR and backup services-continue to have uninterrupted access to the expanded storage fabric.
Verifying and opening ports 3205 and 3260 for the new node IPs is the first step to resolving this timeout issue.

質問 # 72
An administrator is concerned about the operational overhead of manually creating and managing categories across both the primary and recovery sites to ensure Recovery Plans function correctly during failover and failback. What Nutanix Disaster Recovery behavior minimizes this concern?

• A. Categories are automatically synchronized to the recovery site AZ when they are specified in a Recovery Plan.
• B. Categories only need to be configured at the recovery site since that is where failover operations are executed.
• C. Recovery Plans replicate categories only during an active failover event to minimize replication traffic.
• D. Categories must be manually replicated using the Prism Central API between sites to ensure consistency.

正解：A

解説：
Nutanix Disaster Recovery (formerly known as Leap) utilizes Prism Central-based " Categories " to group virtual machines for protection. These categories are used within Protection Policies to determine replication schedules and within Recovery Plans to determine power-on sequences and network mappings. A common operational concern is the need to manually replicate these category definitions across different availability zones (AZs).
To reduce this operational overhead, Nutanix has implemented an automatic synchronization mechanism.
When an administrator creates a Recovery Plan in Prism Central and specifies certain categories for failover, the system automatically synchronizes the definition and metadata of those categories to the paired recovery AZ. This ensures that if the primary Prism Central instance becomes unavailable, the recovery site already possesses the necessary grouping logic to identify and recover the correct virtual machines . This " policy- driven " approach ensures consistency across sites and eliminates the risk of human error associated with manual configuration (Option B). By automating the lifecycle of categories between paired sites, Nutanix ensures that the disaster recovery environment is always aligned with the production environment, allowing for seamless failover and failback operations without the need for repetitive administrative tasks.

質問 # 73
Refer to Exhibit:

An administrator is configuring Metro Availability in their environment, as shown in the diagram. What issue in the configuration will prevent Metro from working correctly?

• A. Each site should have a Witness VM.
• B. The Witness VM is located in a third site.
• C. The latency from the Witness VM to both Site 1 and 2 is too high.
• D. The latency between Site 1 and Site 2 is too high.

正解：D

解説：
Nutanix Metro Availability and Synchronous Replication have very strict networking requirements to ensure that real-time data mirroring does not introduce unacceptable application latency. The industry-standard requirement for Nutanix synchronous operations is a maximum Round Trip Time (RTT) latency of 5ms between the two primary clusters (Site 1 and Site 2). According to the diagram provided in the question, the latency between Site 1 and Site 2 is 25ms RTT. This latency is significantly higher than the 5ms threshold and will prevent the Metro Availability configuration from functioning correctly. While the latency to the Witness VM (200ms RTT) is perfectly acceptable (Option D), and having a Witness at a third site (Option A) is a best practice, the " data path " between the storage clusters is the bottleneck here. If an administrator attempts to enable Metro with 25ms of latency, the guest VMs would experience severe performance degradation because every write would be delayed by the 25ms it takes to receive an acknowledgment from the remote site.
Therefore, the high latency between the data-serving sites is the primary configuration issue that must be resolved, typically by moving the clusters closer together or upgrading the inter-site fiber connection.

質問 # 74
A mission-critical VM utilizing an NVIDIA vGPU profile for high-end graphical processing is replicated from a primary Nutanix cluster to a secondary disaster recovery site. After failover of a VM using an NVIDIA vGPU profile, the VM boots but hardware acceleration does not function. What action is required?

• A. Increase the VM memory allocation to compensate for the lost GPU buffer.
• B. Manually update the vGPU configuration on the VM at the recovery site
• C. Reinstall the guest operating system to recognize the new hardware ID.
• D. Disable Nutanix Guest Tools (NGT) to prevent driver conflicts.

正解：B

解説：
Virtual GPUs (vGPUs) are hardware-dependent resources that are tied to specific physical GPU cards installed in the Nutanix nodes. While Nutanix Disaster Recovery can replicate the VM ' s virtual disks and general configuration, the specific mapping to a physical vGPU profile is often not automatically preserved across clusters due to potential differences in hardware availability or GPU generations at the recovery site.
When the VM fails over and boots up at the secondary site, the guest OS may see the NVIDIA driver but will find that the " backed " hardware resource is missing or incorrectly mapped, leading to a failure in hardware acceleration. To resolve this, the administrator must manually edit the VM ' s hardware settings at the recovery site and re-assign a compatible vGPU profile from the local cluster ' s available GPU resources. This post-failover cleanup task is essential for workloads like VDI (Virtual Desktop Infrastructure) or CAD applications that depend on GPU processing. Relying on NGT (Option A) or reinstalling the OS (Option B) will not fix the underlying missing hardware assignment in the hypervisor, highlighting the need for specialized knowledge when protecting VMs with specialized hardware pass-through or vGPU requirements.

質問 # 75
Which two VM disk types does Self-Service restore support? (Choose two.)

• A. VGs
• B. PCI
• C. SCSI
• D. IDE

正解：C、D

解説：
Self-Service Restore (SSR) relies on the Nutanix Guest Tools (NGT) agent to mount a historical snapshot disk to the guest OS via the hypervisor ' s virtual controller. For this to work seamlessly, the guest OS and the NGT agent must support the virtual bus types used by the virtual machine.
Nutanix SSR natively supports the two most common virtual disk controller types: SCSI (VirtIO) and IDE.
These are the standard formats for most virtual disks in Nutanix AHV and ESXi environments. When a user requests a file-level restore, the system takes the vDisk from the recovery point and attaches it as a new SCSI or IDE device to the running VM, which the guest OS then scans and mounts. Conversely, specialized storage entities like Volume Groups (VGs) (Option D) and certain high-performance direct-attached PCI-based storage (Option C) are not supported by the standard SSR workflow. Volume Groups, which are often used for shared storage between VMs (like SQL Clusters), require a different recovery method because they are not part of the standard VM-centric snapshot metadata that the SSR agent can browse. Therefore, SSR is primarily designed for the standard virtual disks that form the OS and application drives of typical virtualized workloads.

質問 # 76
An administrator plans on performing a failover of a VM from a source cluster to a DR cluster. The administrator needs the VM ' s IP address preserved after failover. In what scenario is the VM ' s IP address preserved?

• A. The IP address is always preserved, no additional configuration required.
• B. The source and destination network subnet must be stretched.
• C. Use unique networks for source and destination networks.
• D. The gateway and subnet mask are left empty in the network mapping.

正解：B

解説：
Preserving IP addresses during a failover is a common requirement for applications with hardcoded IP references or complex inter-service dependencies. In a standard multi-site DR setup, the source and destination sites reside on different Layer 3 subnets, meaning a VM would naturally require a new IP address to be routable at the recovery site. To achieve " IP Preservation, " the underlying network infrastructure must support Layer 2 (L2) stretching.
L2 stretching (often implemented via VXLAN or specialized VPN tunnels like Nutanix Flow Virtual Networking) allows a single logical subnet to span multiple physical locations. When a VM fails over to a cluster on a stretched subnet, it effectively stays on the same network broadcast domain. As a result, its IP address, default gateway, and subnet mask remain valid and unchanged. If the subnets are not stretched, the administrator must rely on the Recovery Plan ' s " IP Mapping " feature to assign a new, valid IP at the destination-which does not " preserve " the original address. While preserving IPs simplifies application recovery, it requires more complex network engineering to ensure that traffic is correctly routed to the active site during a disaster, highlighting the trade-off between application simplicity and infrastructure complexity in BCDR design.

質問 # 77
An organization uses a Recovery Plan to protect a SQL Cluster that relies on Volume Groups (VGs). The VGs are configured with hypervisor attachments. The administrator executes a Planned Failover to migrate the SQL Cluster to the Recovery Site. The Failover task completes successfully, but the database administrators report that the database is offline. What is the possible cause of this issue?

• A. VGs cannot be protected by Recovery Plans.
• B. VGs configured with hypervisor attachments do not reattach automatically after recovery.
• C. An administrator failed to configure mapping for the Storage Network in the Recovery Plan.
• D. An administrator failed to configure Protection Domains replication.

正解：B

解説：
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.

質問 # 78
An administrator configures disaster recovery between an on-premises AZ and a Nutanix Cloud AZ. After enabling DR and assigning protection policies to several VMs with volume groups, the administrator initiates failover and notices the VMs do not have their volume groups attached. Investigation reveals:
* The clusters are successfully paired in Prism Central.
* Protection policies and replication schedules are configured correctly.
* Recovery plan validation completes successfully.
* Required firewall ports between sites are confirmed open.
* Management IP addresses are reachable in both directions.
Despite this, the administrator observes the volume groups are still not attached. Which network-related prerequisite is most likely misconfigured?

• A. The recovery plan has not been validated.
• B. The clusters do not have a Data Services IP addresses configured.
• C. Nearsync replication does not support volume groups.
• D. The hypervisor management interfaces are not on the same subnet.

正解：B

解説：
Nutanix Volume Groups (VGs) provide block-level storage to virtual machines, often used for high- performance databases or shared storage clusters. Unlike standard vDisks, which are managed directly as part of the VM ' s hardware definition, VGs are presented as iSCSI targets. In a Disaster Recovery scenario, when a VM is recovered at a new site, it must be able to " find " and re-attach these Volume Groups to resume operation.
For this attachment to succeed, especially across different clusters or into a Nutanix Cloud AZ, both the source and recovery clusters must have a " Data Services IP Address " configured. The Data Services IP acts as the cluster-wide iSCSI target portal. When a VM fails over, the Nutanix orchestration engine uses this IP to coordinate the iSCSI login and mapping of the Volume Group to the guest OS. If this IP is missing on either cluster, the internal iSCSI redirection and handoff mechanisms will fail, even if the general management networking and Protection Policies are perfectly healthy. This is a common " Day 1 " configuration error because management connectivity (Prism) works without a Data Services IP, but block-level services like VGs and certain NGT features strictly require it. Verifying and configuring the Data Services IP at both availability zones is the primary fix for Volume Group attachment failures during DR failover.

質問 # 79
An administrator wants to protect the snapshots created on the cluster. Only authorized users should be allowed to modify or delete the snapshots on the cluster. How can the administrator harden the security of the snapshots?

• A. Configure a backup user with admin privileges.
• B. Configure CVM and AHV hardening.
• C. Configure cluster lockdown and use SSH keys.
• D. Configure Approval policy for snapshots.

正解：D

解説：
Hardening a Nutanix cluster for Business Continuity involves implementing security controls that protect recovery data from unauthorized destruction. In many modern cyberattacks, specifically ransomware, the goal is not just to encrypt production data but also to delete the snapshots and backups that would allow for recovery. To satisfy the requirement that only authorized modifications occur, the administrator must move beyond simple Role-Based Access Control (RBAC) and implement an " Approval Policy " .
The Approval Policy feature in Prism Central forces a secondary layer of validation for sensitive operations like snapshot deletion. When a user tries to delete a recovery point, the Nutanix orchestration engine captures the request and holds it in a " Pending " state. The request must be reviewed and approved by a designated person with approval authority. This ensures that even if an administrator ' s account is compromised, the attacker cannot immediately wipe out the snapshots needed to restore the environment. This " multi-person control " is a recognized security best practice for protecting mission-critical data. While cluster lockdown (Option C) prevents unauthorized SSH access, it does not manage the logical management of data through the Prism UI. An Approval Policy provides the specific " modification and deletion " control requested, ensuring that the cluster ' s recovery points remain a reliable " source of truth " following a security incident or administrative error.

質問 # 80
An administrator is tasked with ensuring the VMs do not experience downtime during an upcoming network maintenance on the primary cluster. The VMs are protected by a Protection Policy and are configured under a Recovery Plan. What failover mechanism should the administrator use to ensure the VMs are available on the target cluster before the maintenance window?

• A. Planned Failover
• B. Validate the Recovery Plan
• C. Unplanned Failover
• D. Test Failover

正解：A

解説：
In a Business Continuity strategy, " downtime " can be categorized as either unexpected (disaster) or controlled (maintenance). When an administrator knows that a disruption is coming, such as scheduled network maintenance on a primary cluster, they should utilize the " Planned Failover " mechanism within the Nutanix Recovery Plan.
A Planned Failover is a graceful, orchestrated migration. It first shuts down the virtual machines at the primary site to ensure all data is flushed and no new writes occur. It then performs a final synchronization to the recovery site to ensure zero data loss (Zero RPO), and finally powers the VMs on at the destination site according to the plan ' s sequence. This differs significantly from an " Unplanned Failover " (Option A), which assumes the primary site is already offline and may result in minor data loss depending on the last successful replication. A " Test Failover " (Option D) merely validates the process in an isolated environment and does not move the actual production workload. By executing a Planned Failover before the maintenance begins, the administrator ensures that the services are safely running on the target cluster, maintaining application availability and meeting the objective of zero downtime during the maintenance window.

質問 # 81
After a failover and stabilization of workloads at the recovery AZ, an administrator removes several VMs from the protection policy because they are no longer required. Which action should be performed as part of post-failover cleanup to prevent unnecessary storage consumption?

• A. Recreate the recovery plan.
• B. Delete the associated recovery points.
• C. Reconfigure the replication schedule.
• D. Disable Nearsync replication.

正解：C

解説：
Post-failover cleanup is a vital operational step to ensure that the environment remains optimized and that resources are not being wasted on workloads that are no longer part of the production environment. When virtual machines are removed from a Protection Policy after a failover, the orchestration engine stops creating new recovery points for them; however, the existing schedule metadata and historical snapshots may still consume space on both the primary and recovery clusters. Reconfiguring the replication schedule (Option B) is the specific task that refreshes the policy ' s state and forces the system to re-evaluate the storage requirements for the remaining entities. This action ensures that the background cleanup processes (managed by Cerebro and Curator) can properly identify and purge the snapshots associated with the removed VMs once their retention period has passed. Failing to reconfigure the schedule or the associated protection policy can leave " orphaned " snapshots in the storage tier, leading to a steady increase in storage utilization over time. By reconfiguring the schedule, the administrator confirms the new steady-state of the DR environment, ensuring that storage is only consumed by the active, required workloads.

質問 # 82
During the Recovery Plan configuration, the administrator maps the " Test Network " setting to the " Production Network " VLAN on the Recovery Site. What is the expected outcome when the administrator executes a Test Failover for this plan?

• A. The Test VMs will start, causing IP address conflicts with the live production VMs on the Primary Site.
• B. The Test VMs will remain turned off, maintaining isolation from all other network traffic automatically.
• C. The Test VMs will turn on, but will be isolated from all other network traffic automatically.
• D. The Test Failover will fail the validation check because the production network is already in use.

正解：A

解説：
Nutanix Recovery Plans allow for granular control over networking during different failover scenarios. The " Test Network " setting is specifically designed to provide an isolated sandbox for validation. If an administrator incorrectly maps this test network to the actual " Production Network " VLAN at the recovery site, they are effectively bypassing the safety mechanisms intended to isolate the test.
When the Test Failover is executed, the test VMs will boot up on the production VLAN using the exact same IP addresses they have at the source site. If the primary site is still online (which is the case during a test), the existence of two identical VMs with identical IPs on the same logical network will cause immediate IP address conflicts. This can disrupt live production traffic, cause routing instability, and potentially lead to service outages at both sites. The system does not " automatically " isolate traffic (Option B) if the administrator has explicitly directed the test VMs to the production segment. This scenario emphasizes the critical importance of network planning in BCDR: a " Test " network must always be an isolated, non- routable segment to ensure that validation remains non-disruptive as intended.

質問 # 83
An administrator performed an unplanned failover from AZ1 (primary) to AZ2 (recovery). Later, AZ1 is restored and the administrator wants to fail back the entities to AZ1. Which two statements are correct?
(Choose two.)

• A. After unplanned failover, failback success depends on recovery points being created locally on AZ1 before outage.
• B. Unplanned failover to AZ1 can use recovery points that were created locally in the past at AZ1, even if no recovery points replicate back from AZ2.
• C. After unplanned failover, replication begins in the reverse direction, and failback success depends on recovery points being replicated back from AZ2 to AZ1 after failover.
• D. Failback uses the same recovery plan, but the failover operations for failback must be performed at the primary AZ.

正解：B、C

解説：
Nutanix Disaster Recovery is designed to be bi-directional, supporting both failover and failback . In an unplanned failover, the primary site (AZ1) is assumed to have crashed. Once AZ1 is brought back online, the system must synchronize any data changes that occurred while the VMs were running at AZ2.
Statement C is correct because once the VMs are powered on at AZ2, the Nutanix Cerebro service automatically reverses the protection policy. New recovery points are created at AZ2 and replicated back to AZ1. For a successful, modern failback with zero data loss from the cloud session, the administrator must wait for these recovery points to replicate back to AZ1 before initiating the failback.
Statement B is also correct and describes a specific " recovery of last resort " scenario. If AZ1 is restored but connectivity to AZ2 is permanently lost (e.g., the cloud provider has an issue), an administrator can still " Unplanned Failover " back to AZ1 using the historical snapshots that existed locally on AZ1 before the original outage. This would result in data loss equal to the time the VMs were running at AZ2, but it allows for service restoration when the recovery site itself fails. These two statements highlight the flexibility of the Nutanix DR architecture in handling both controlled failback and emergency local restoration.

質問 # 84
A Protection Domain exists with a VM, but no new snapshots are being created and replication never starts.
Which is the most likely DR setup issue?

• A. Bandwidth throttling is set too low
• B. The Protection Domain has no schedule configured
• C. The remote site has no vStore mapping
• D. The Protection Domain has no entities that are protected

正解：B

解説：
In a Nutanix legacy Protection Domain (PD) configuration, three primary elements must be in place for data protection to occur: the entities (VMs), the remote site (destination), and the schedule. Even if a VM has been added to a Protection Domain (negating Option A), the cluster will not take any action unless it is explicitly told " when " and " how often " to do so.
If no new snapshots are being created locally and replication is not starting, the most likely issue is that no " Schedule " has been configured for that Protection Domain. The schedule defines the RPO (e.g., hourly, daily) and the retention period for the snapshots. Without an active schedule, the Cerebro service simply has no instruction to initiate the snapshot process. While a missing vStore mapping (Option C) would cause the " replication " to fail, the " local snapshots " would still be created in the PD. Similarly, low bandwidth throttling (Option D) would cause the replication to move slowly or time out, but it would not prevent the initial creation of the local recovery points. Therefore, verifying the presence of a valid, active replication schedule is the mandatory first step for an administrator when a Protection Domain appears to be " idle " despite having VMs assigned to it.

質問 # 85
An administrator executes a Recovery Plan for a set of high-performance VMs configured with SR-IOV network adapters. The VMs failover successfully to the Recovery Cluster.
What is the state of these VMs immediately after the planned failover completes?

• A. The VMs are powered on, but SR-IOV is disabled and replaced with a standard virtio-net adapter.
• B. The failover fails during the validation phase because SR-IOV VMs cannot be protected.
• C. The VMs are recovered in a powered-off state, and the SR-IOV profile is removed.
• D. The VMs are powered on, and SR-IOV is active.

正解：A

解説：
Single Root I/O Virtualization (SR-IOV) allows a virtual machine to bypass the hypervisor ' s virtual switch and communicate directly with a physical network adapter ' s virtual functions. This is commonly used for high-performance applications that require extremely low latency and high throughput. However, SR-IOV creates a " hard " dependency between the virtual machine and the specific physical hardware (NIC) of the host it is running on.
Disaster Recovery involves moving a VM to an entirely different cluster, which likely has different physical network adapters or a different SR-IOV configuration. Nutanix Disaster Recovery orchestration is designed to ensure that VMs can always boot at the recovery site, even if specialized hardware resources are unavailable.
For VMs configured with SR-IOV, the recovery process includes a built-in fallback mechanism. During failover, the system will recover the VM and power it on, but it will disable the SR-IOV attachment. To ensure connectivity, it automatically adds or falls back to a standard virtio-net virtual adapter. This allows the VM to have network access immediately, though at a potentially lower performance level. The administrator must then manually re-configure SR-IOV at the recovery site if the local hardware supports it. This design prioritizes service availability (powering on and communicating) over specialized hardware performance during a disaster recovery event.

質問 # 86
An administrator needs to provide leadership with a report showing the timeframe of each step during Recovery Plan failover testing. How should the administrator produce this report?

• A. Filter the Events log in Prism Central for Recovery Plan activity.
• B. Use ncli on a CVM to query Recovery Plan execution history.
• C. Review the built-in execution report from the test failover results.
• D. Generate a custom report within Prism Central Intelligent Operations.

正解：C

解説：
Validation is a core pillar of a robust Business Continuity and Disaster Recovery (BCDR) strategy. Nutanix provides built-in orchestration through Recovery Plans, which automate the failover process of virtual machines between sites. When a " Test Failover " is executed, the system performs all the necessary steps, such as booting VMs in an isolated network, applying network mappings, and executing any custom scripts.
To provide visibility into this process, Nutanix generates an automated execution report upon completion of any Recovery Plan task. This report provides a detailed chronological breakdown of every action performed by the orchestrator, including the exact start and end times for each stage (e.g., " Replication Check, " " Power On, " " IP Assignment " ). This built-in reporting is superior to manual event log filtering because it aggregates all related activities into a single, digestible summary that specifically tracks the performance of the DR plan. For leadership and compliance teams, these execution reports serve as documented proof that the RTO (Recovery Time Objective) is achievable and that every orchestrated step was validated during the test window.

質問 # 87
......

合格させるNutanix NCP-BC-7.5試験最速合格にはPassTest：https://www.passtest.jp/Nutanix/NCP-BC-7.5-shiken.html