Practice Free NCP-DB Nutanix Certified Professional - Database Automation (NCP-DB v7.5) Exam Questions Answers With Explanation

To free up space in the NDB-managed container, the administrator needs to identify storage consumption sources. Two key locations in NDB provide actionable insights:

C. Clone Database table: This displays all clone databases, including their Size (current storage usage) and Last Refresh (indicating age or staleness). Clones often consume significant space, and older or unused ones can be deleted to reclaim storage.

D. Snapshot table in Time Machine: This shows snapshots with details like Reclaimable Space (space recoverable by deletion) and Age (how long snapshots have existed). Old or unnecessary snapshots are prime candidates for reclamation.

Why not the other options?

A. NDB Dashboard (Clone Data Age): While it provides a high-level view, it lacks granular details (e.g., size per clone) needed for targeted reclamation.

B. Source Database grid: This shows registered databases’ size and status but doesn’t focus on derivative objects (clones/snapshots) that typically consume more space.

Thus, C and D are the best locations for detailed storage analysis and reclamation research.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 6: Storage and Resource Management, Lesson 6.2: Monitoring and Reclaiming Storage.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 6: Optimize NDB Solutions, Objective 6.1: Manage Storage Consumption (applicable to v7.5).

Nutanix NDB Administration Guide: "Clone Database Table" and "Time Machine Snapshot Table" sections.

 The optimal path to restore the table back with minimum data loss is to use the point in time restore feature of NDB, which allows the administrator to restore the database to a specific point in time based on the available snapshots and logs1. By restoring using point in time till 10:42pm, the administrator can recover the table just before it was dropped by the user, and minimize the data loss to the least possible amount1. The other options are not optimal, as they either involve restoring an older snapshot, which may result in more data loss, or restoring a non-existent snapshot, which is not possible. References:

1: Nutanix Database Automation (NCP-DB) course, Module 6: Database Recovery, Lesson 6.2: Point in Time Restore, slide 5

NDB’s one-click patching workflow tracks patch actions and the corresponding database-server state in the NDB control plane. If an administrator patches the operating system manually outside NDB, those changes bypass the managed workflow, so NDB metadata is not updated. The VM is not automatically rolled back, and NDB does not automatically refresh it from a Software Profile. Instead, the difference between the server’s actual configuration and NDB’s recorded state can affect later lifecycle operations and produce unexpected behavior. Nutanix explicitly warns administrators to avoid manual patching outside NDB for this reason and states that the metadata will not update. Therefore, option D is correct. The candidate file’s supplied answer C states the opposite of the official One-Click Patching guidance and has been corrected. Nutanix One-Click Patching documentation

Point in Time Recovery (PITR) is a feature of NDB that allows restoring a database to any point in time within the retention period of the SLA. To enable PITR, the SLA must support Continuous Log retention, which means that NDB captures and stores the database logs continuously. This allows NDB to replay the logs from the last snapshot to the desired point in time during the restore process. The other options do not enable PITR, but rather affect the frequency and timing of the snapshots and log catch up operations.

 Nutanix Support & Insights, section “NDB Time Machine Point in Time Recovery”

In an NDB environment, the repository VM stores metadata and configuration data but is not a critical runtime component for service availability. If the team powers off the repository VM during maintenance, and it is neither the primary nor a synchronized copy node, the NDB service will continue to operate without interruption. NDB’s high availability (HA) architecture, managed by HAProxy and other components, ensures redundancy and failover capabilities, allowing the system to rely on the primary and synchronized nodes. The repository VM’s downtime only affects metadata access, which can be restored post-maintenance without impacting ongoing database operations.

Option A (The HAProxy VMs will failover instead) is incorrect because HAProxy failover is triggered by primary service node failures, not repository VM power-off.

Option B (There will be no service interruption) is correct as the HA design tolerates a non-primary, non-synchronized repository VM being offline.

Option C (Manual interaction will be required to restore service) is incorrect because no service restoration is needed during this scenario.

Option D (NDB services will fail over immediately) is incorrect because failover is not triggered by a non-critical repository VM power-off.

This reflects NDB’s robust HA implementation.

References

Nutanix Database Service (NDB) User Guide, Chapter 3: Configuring an NDB Environment, Section: High Availability Architecture

Nutanix Support & Insights, Knowledge Base Article: "Impact of Repository VM Maintenance in NDB"

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 3: Configure an NDB Environment

NDB can leverage snapshots and transaction logs to refresh a database clone to the latest state of the source database. Snapshots are point-in-time copies of the database that are stored on the Nutanix cluster. Transaction logs are records of the changes made to the database after the snapshot was taken. NDB can use either snapshots or transaction logs, or a combination of both, to refresh a database clone. Cerebro logs and templates are not used for refreshing database clones. Cerebro logs are used for log catch-up operations, which are different from refresh operations. Templates are used for provisioning new databases, not for refreshing existing ones. References:

Nutanix Database Management & Automation (NDMA) course, Module 4, Lesson 4.3 - Refreshing Clones

Nutanix Support & Insights, Nutanix NDB User Guide v2.5, Clone Database Management

The log frequency in the Era IJI for log catchup operation can be configured to as low as 5 minutes. This allows the system to capture changes to the database at a high frequency, enabling more precise point-in-time recovery options. However, it’s important to note that a higher frequency of log catchup operations can lead to increased system load. Therefore, the optimal frequency may vary depending on the specific requirements and capabilities of your system12. Please refer to the Nutanix Database Automation (NCP-DB) Learning documents for more detailed information.

When patching an Oracle Database Server VM, it's important to ensure that there is sufficient storage space allocated for the Grid home. A minimum of 10GB space is required for this purpose to accommodate the patching process without storage constraints.

To add Time Machine data access to a Nutanix cluster, the first step is to register the cluster in NDB. This will allow NDB to discover and manage the databases and snapshots on the cluster. You can register multiple Nutanix clusters in NDB using the Add Cluster option in the NDB settings page. You can also specify the cluster role, such as source, target, or both, depending on the data access and replication needs. Enabling or disabling multi-cluster in NDB is not the first step, as this is a global setting that affects the entire NDB instance. Deleting the TM data from the source database is not the first step, as this will remove the data protection and availability of the database. References:

Nutanix Database Management & Automation Training Course, Module 6: Managing NDB Multi-Cluster, Lesson 1: NDB Multi-Cluster Overview, Slide 5: Registering Nutanix Clusters

Nutanix Certified Professional - Database Automation (NCP-DB) 5 Exam, Section 6: Administer an NDB Environment, Objective 6.4: Apply procedural concepts to add Nutanix clusters to NDB

If an SQL database clone deletion fails immediately in NDB, the most likely cause is that the clone has been marked as Immutable. An immutable clone is protected from deletion to prevent accidental data loss, often set for critical development or testing environments. This protection must be explicitly removed by the administrator (e.g., via the NDB GUI or CLI) before the deletion can proceed.

Option A (A refresh operation is in progress) is incorrect because a refresh operation would delay but not immediately fail the deletion.

Option B (The clone has been marked as Immutable) is correct as immutability blocks deletion until changed.

Option C (The database was not marked as Offline before the operation) is incorrect because the offline state is not a prerequisite for clone deletion.

Option D (The database data drives are shared with other applications) is incorrect because shared drives might cause issues, but immutability is a more direct cause of immediate failure.

References

Nutanix Database Service (NDB) User Guide, Chapter 5: Configuring Time Machines, Section: Managing Clones and Deletion

Nutanix Support & Insights, Knowledge Base Article: "Troubleshooting Clone Deletion Failures in NDB"

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 5: Protect Databases Using Time Machine

A Compute Profile is a template that defines the CPU, memory, and disk resources for a database server VM. By creating a Compute Profile with the desired number of cores per vCPU, the administrator can easily apply it to multiple VMs during provisioning, ensuring consistent and optimal performance. This also saves time and effort compared to updating the VMs individually or modifying the default profile after provisioning. References: Nutanix Database Automation (NCP-DB) Course Details, Nutanix Database Automation (NCP-DB) Certification Details, Nutanix Database Automation (NCP-DB) YouTube Playlist, How-to setup number of cores per CPU in a virtual machine.

NDB supports SQL Server database groups so multiple databases can share one Time Machine and a coordinated protection schedule. Nutanix documents a maximum selection of 35 databases for group-registration workflows and states that Microsoft recommends no more than 35 databases in one database group. A SQL Server database server VM or cluster can contain as many as five NDB database groups. The efficient design for 90 databases is therefore three groups—for example, 35, 35, and 20 databases—with one Time Machine for each group. A single 90-database group exceeds the supported or recommended size, while creating 90 individual Time Machines or relocating databases to other servers introduces unnecessary operational overhead. Therefore, option B is correct. Nutanix SQL Server database-group documentation

The error message in the exhibit indicates that the operation failed during the “Create and Register Database Server VMs” step because “Provisioning of all the observers simultaneously took more than two hours.” This type of error is associated with MySQL, as it involves observers which are a part of MySQL Group Replication, used for ensuring high availability1. The other options are not related to the error message, as they do not use observers or Group Replication for clustering. References:

1: Nutanix Database Automation (NCP-DB) course, Module 5: Database High Availability, Lesson 5.2: MySQL Group Replication, slide 7

In Nutanix Database Service (NDB), when an administrator deprecates a software profile version, it is marked as obsolete and restricted from certain operations. Specifically, a deprecated software profile version can no longer be used for provisioning new database instances or VMs. This ensures that only current, supported versions are utilized for new deployments, maintaining consistency and security. Existing database servers using the deprecated profile can continue to operate and may still be patched (if updates are compatible), but the profile itself is excluded from future provisioning tasks.

Option A is correct because deprecation explicitly prevents the profile version from being selected for new provisioning, aligning with NDB’s lifecycle management.

Option B (It can be used in provisioning) is incorrect as this contradicts the purpose of deprecation.

Option C (Any database server using that profile will be updated to the latest software profile) is incorrect because deprecation does not automatically update existing servers; it only affects new provisioning.

Option D (Any database server using that software profile can no longer be patched) is incorrect because patching existing servers is still possible if compatible updates exist, independent of the profile’s deprecated status.

Deprecation is a deliberate administrative action to phase out outdated profiles while preserving existing deployments.

References

Nutanix Database Service (NDB) User Guide, Chapter 4: Managing Software Profiles, Section: Deprecating Software Profile Versions

Nutanix Support & Insights, Knowledge Base Article: "Software Profile Management in NDB"

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 4: Manage Database Software Profiles

When an administrator needs to scale the size of an Oracle database running on Nutanix NDB and originally configured using ASMLib (Automatic Storage Management Library), the most efficient approach is to use NDB’s built-in scaling ability to resize existing vDisks. NDB supports dynamic resizing of virtual disks (vDisks) associated with database VMs, allowing the administrator to increase storage capacity without disrupting the database or requiring complex migrations. This method leverages Nutanix’s storage integration, resizing the underlying vDisks and updating the ASMLib configuration to reflect the new size, ensuring seamless operation.

Option A (Leverage the scaling ability built into NDB to resize existing vDisks) is correct as it is the most efficient, native NDB feature for scaling storage.

Option B (Extend the size by adding new vDisks) is incorrect because adding new vDisks requires additional configuration (e.g., ASM disk group adjustments), making it less efficient than resizing.

Option C (Create a new, larger database and migrate) is incorrect because migration is time-consuming and unnecessary when resizing is supported.

Option D (Mount an iSCSI LUN and extend the database onto the new LUN) is incorrect because iSCSI LUNs are not the preferred method in NDB, and resizing vDisks is more integrated.

This approach minimizes downtime and complexity.

References

Nutanix Database Service (NDB) User Guide, Chapter 4: Managing Database Servers, Section: Scaling Storage for Databases

Nutanix Support & Insights, Knowledge Base Article: "Resizing vDisks for Oracle Databases in NDB"

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 4: Manage Database Servers

The provided exhibit shows the "Enable Multi-Cluster" configuration wizard in NDB, where the VLAN dropdown is empty with a "Nothing found" message, indicating that no VLANs are available for selection. This issue arises because NDB requires a network profile to be created before provisioning the NDB Agent VM and enabling multi-cluster support. A network profile defines the static VLANs managed by NDB, which are essential for network configuration during multi-cluster setup. The warning in the exhibit ("An NDB managed static vLAN is required to provision the NDB Agent VM. Add an NDB managed static vLAN using the Networks page to continue.") reinforces that the administrator must create a network profile via the Networks page to populate the VLAN dropdown.

Option A (A network profile must be created first) is correct as it addresses the root cause by ensuring VLANs are defined in a network profile.

Option B (Verify if subnet leverages advanced network control) is incorrect because advanced network control is not a prerequisite for VLAN selection in this context.

Option C (IP address pool must be managed in NDB) is incorrect because IP address pools are managed separately and not required for VLAN selection at this stage.

Option D (VLAN subnet must use IP address management) is incorrect because IP address management is not a direct requirement for enabling VLAN selection in the wizard.

After creating the network profile, the administrator can proceed with the multi-cluster enablement.

References

Nutanix Database Service (NDB) User Guide, Chapter 3: Configuring an NDB Environment, Section: Configuring Network Profiles for Multi-Cluster

Nutanix Support & Insights, Knowledge Base Article: "Troubleshooting VLAN Issues in NDB Multi-Cluster Setup"

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 3: Configure an NDB Environment

NDB supports database and database server VM deployment on NC2 on Azure by using overlay networks created through Nutanix Flow Virtual Networking. A Flow overlay subnet provides the logical network used by the NDB-managed database server VMs while allowing the networking configuration to operate consistently within the NC2 environment. Flow underlay subnets are not the supported choice for this NDB deployment model. AHV IP Address Management is associated with AHV-managed networks and does not represent the required NC2 on Azure networking type. Azure-native networking exists beneath the NC2 infrastructure, but NDB-managed database provisioning uses the Flow overlay network exposed within NC2 rather than directly attaching database VMs to a native Azure network. Nutanix’s official NDB on NC2 documentation confirms support for Flow Virtual Networking overlay networks on NC2 environments.

 The correct answer is B and D because they are the two restore options that can be used to restore an Oracle database to the prior day’s state using Nutanix Era. A snapshot is a point-in-time copy of a database that is stored in the Era Time Machine, which is a distributed file system that collects logs and snapshots from databases. A point in time is a specific moment in time within the retention period of the SLA policy that is applied to the database. By using either of these options, the administrator can select the snapshot or the point in time that corresponds to the prior day’s state and restore the database from it. The other options are not correct because they are not restore options that are available in Nutanix Era. Option A is not correct because Most Recent Time Available is not a restore option, but a clone option that creates a clone of the database from the most recent snapshot or log backup. Option C is not correct because Tail Logs Backup is not a restore option, but a backup option that captures the transaction logs of the database that have not been backed up by the SLA policy. References: Nutanix Database Management & Automation (NDMA) course, Nutanix Certified Professional - Database Automation (NCP-DB) certification, Nutanix NCP-DB Certification Exam Syllabus and Study Guide, [Nutanix Database Services: Database modernization with Era - Now available]

During an NDB upgrade, the upgrade process follows a specific order to maintain stability and HA. The Leader NDB API Server is upgraded first. This server coordinates API requests and ensures the control plane remains operational. Upgrading the leader first minimizes disruption, as subsequent components (e.g., other API servers, HAProxy) rely on its leadership role. Once the leader is upgraded, the remaining NDB HA control plane VMs (e.g., follower API servers, HAProxy) are updated in sequence.

Other options are incorrect:

A. NDB Server: Refers to the main NDB instance, not upgraded first.

C. Leader HAProxy: Upgraded after API servers to maintain load balancing.

D. NDB Agent VMs: Upgraded last, as they are client-side components.

Thus, the verified answer is B, reflecting the upgrade sequence.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 2: Deploying and Configuring an NDB Solution, Lesson 2.4: Updating NDB.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 2: Deploy and Configure an NDB Solution, Objective 2.3: Perform NDB Updates (applicable to v7.5).

Nutanix NDB Administration Guide: "NDB Upgrade Process" section.

The administrator should perform a rolling upgrade, applying the patch to the secondary members first, followed by the primary member, to accomplish the task of patching a MongoDB server cluster within an NDB environment. A rolling upgrade is a method of applying patches or updates to a cluster without downtime or interruption of service. The administrator can use the NDB patching feature to perform a rolling upgrade on a MongoDB server cluster, which consists of a primary member and one or more secondary members that form a replica set. The NDB patching feature allows the administrator to select the software profile version, the database parameters profile, and the network profile for the patching operation. The NDB patching feature also automates the steps of the rolling upgrade, such as:

Step 1: The administrator initiates the patching operation on the NDB instance, and selects the MongoDB server cluster to be patched.

Step 2: The NDB instance verifies the prerequisites and compatibility of the patching operation, and creates a pre-patch snapshot of the MongoDB server cluster.

Step 3: The NDB instance applies the patch to the first secondary member of the MongoDB server cluster, and waits for the patching to complete successfully.

Step 4: The NDB instance verifies the status and functionality of the patched secondary member, and repeats the patching process for the remaining secondary members of the MongoDB server cluster, one at a time.

Step 5: The NDB instance performs a failover of the primary member to one of the patched secondary members, and applies the patch to the original primary member.

Step 6: The NDB instance verifies the status and functionality of the patched primary member, and performs a failback of the primary member to the original primary member, if desired.

Step 7: The NDB instance creates a post-patch snapshot of the MongoDB server cluster, and completes the patching operation.

Performing a rolling upgrade, applying the patch to the secondary members first, followed by the primary member, is the recommended and best practice method of patching a MongoDB server cluster within an NDB environment, as it ensures the high availability, consistency, and performance of the MongoDB server cluster and the databases.

Performing a rolling upgrade, applying the patch to the primary member first, followed by the secondary members, is not a valid or feasible method of patching a MongoDB server cluster within an NDB environment, as it would cause downtime, data loss, and inconsistency of the MongoDB server cluster and the databases. Applying the patch to the primary member first would disrupt the replication and synchronization of the MongoDB server cluster, and would require manual intervention and recovery steps to restore the MongoDB server cluster to a functional state.

Applying the patch to all nodes at once is not a valid or feasible method of patching a MongoDB server cluster within an NDB environment, as it would cause downtime, data loss, and inconsistency of the MongoDB server cluster and the databases. Applying the patch to all nodes at once would require shutting down the entire MongoDB server cluster, and would expose the MongoDB server cluster and the databases to potential errors, failures, and corruption during the patching process.

Disabling the replica set while patching is not a valid or feasible method of patching a MongoDB server cluster within an NDB environment, as it would cause downtime, data loss, and inconsistency of the MongoDB server cluster and the databases. Disabling the replica set while patching would break the replication and synchronization of the MongoDB server cluster, and would require manual intervention and recovery steps to re-enable the replica set and restore the MongoDB server cluster to a functional state.

Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.1: Nutanix Era Operations, slides 11-12, 15-16.

Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.3: Nutanix Era Patching, slides 5-9.

Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.4: Nutanix Era Patching Lab, slides 5-10.

Nutanix Database Management & Automation Training Course, Module 7: Nutanix Era Troubleshooting, Lesson 7.1: Nutanix Era Troubleshooting, slide 6.

 In Nutanix Database Automation (NCP-DB), the Database Parameters profile is used to manage database-specific settings, including the maximum number of database connections. This profile would be the appropriate choice when an administrator needs to change these settings during the cloning workflow1.

In the Nutanix Database Automation (NCP-DB) framework, provisioning a new Oracle database through Era requires the configuration of both a Compute and a Storage profile1. The Compute profile is used to define the resources allocated to the database, such as CPU and memory, while the Storage profile is used to specify the storage configuration for the database. These profiles are essential in ensuring that the database is provisioned with the necessary resources and storage configurations for optimal performance23.

The correct answer is D because it meets the requirements of maintaining five days of time-travel capability to any second and an additional seven days of discrete recovery at a daily interval. Continuous log retention allows the administrator to restore the database to any point in time within the specified number of days, while snapshot retention allows the administrator to restore the database to a specific point in time at a fixed interval. Therefore, by setting the daily snapshot retention to 7 days, the administrator can ensure that there is a discrete recovery point for each day of the week. By setting the continuous log retention to 5 days, the administrator can ensure that there is a time-travel capability to any second within the last five days. The other options do not meet the requirements because they either have less than five days of continuous log retention or less than seven days of snapshot retention. References: Nutanix Database Management & Automation (NDMA) course, Nutanix Certified Professional - Database Automation (NCP-DB) certification, Nutanix NCP-DB Certification Exam Syllabus and Study Guide, Nutanix Certified Professional - Database Automation (NCP-DB) datasheet

An administrator needs to provision multiple database clones from the same source database for different purposes (e.g., QA and Test/Development) while avoiding resource starvation by differentiating VM resources for each department. The most efficient way to achieve this is by creating multiple Compute profiles in NDB. Compute profiles define CPU, memory, and other resource allocations for VMs, allowing the administrator to tailor resource limits (e.g., higher resources for QA, lower for Development) and apply them during clone provisioning. This approach is built into NDB, ensuring consistent resource management without manual adjustments.

Option A (Create multiple Compute profiles) is correct as it provides a scalable and efficient way to allocate resources per department.

Option B (Leverage NCM Self Service to deploy database clones) is incorrect because Nutanix Cluster Management (NCM) Self Service is for end-user provisioning, not resource differentiation.

Option C (Use a VM Template for each department) is incorrect because VM templates are less flexible and not natively integrated with NDB clone provisioning.

Option D (Generate a playbook to resize database VMs when released) is incorrect because playbooks are for automation, not initial resource allocation, and resizing post-provisioning is less efficient.

This method optimizes resource use across departments.

References

Nutanix Database Service (NDB) User Guide, Chapter 4: Managing Database Servers, Section: Configuring Compute Profiles

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 4: Manage Database Servers

NDB stores the selected user-interface language in the local web-browser context rather than in the administrator’s NDB user account. Consequently, changing the interface from English to Spanish affects the browser in which the preference was selected. When the same administrator opens NDB from another workstation or browser, that browser has no saved preference and the interface defaults to English. The behavior is not controlled by the workstation’s regional settings, and signing out does not inherently reset the preference in the original browser. If language selection were bound to the NDB user, it would follow the user across workstations, which the scenario explicitly shows does not occur. Therefore, option A accurately identifies the cause: NDB interface language settings are local to each web browser. NDB User Guide—Changing language settings

================

The command era-server > era server set ip=ip_address gateway=gateway_address netmask=ip_netmask nameserver=ns1 ntp_server=ntp1 is used to assign a static IP address to the NDB VM via the era-server CLI. This command requires core network parameters (ip, gateway, and netmask) to configure the VM’s network interface correctly. However, optional parameters like nameserver (DNS server) and ntp_server (Network Time Protocol server) can be omitted if the administrator relies on default or externally configured DNS and NTP settings (e.g., via DHCP or another management system). These optional parameters enhance functionality but are not mandatory for the basic static IP configuration.

Option A (ntp_server) is correct as it is optional and can be configured separately or omitted if NTP is managed externally.

Option B (netmask) is incorrect because the netmask is a required parameter to define the subnet for the IP address.

Option C (gateway) is incorrect because the gateway is a required parameter to specify the network route.

Option D (nameserver) is correct as it is optional and can be omitted if DNS is handled outside NDB.

Note: The typos in the question (gatevay_address, ip_J2etmas^c, narnesetver, ntpl) are assumed to be gateway_address, ip_netmask, nameserver, and ntp1 based on context.

References

Nutanix Database Service (NDB) User Guide, Chapter 6: Administering an NDB Environment, Section: Configuring Network Settings via CLI

Nutanix Support & Insights, Knowledge Base Article: "Configuring Static IP for NDB VM"

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 6: Administer an NDB Environment

SELinux enforcing mode permits access only when files, directories, mount points, and processes carry labels allowed by the active policy. NDB’s supported model uses database-engine-specific SELinux configuration and policies so restored storage paths receive the expected security contexts and remain accessible after attachment. This is why predefined contexts and file policies tailored to the database paths are the valid mechanism. NDB does not guarantee restores by switching the host to permissive mode, because that would suspend enforcement. It also does not install kernel-bypass modules or disable auditing. Dynamically inventing policies during every restore would be operationally unsafe and inconsistent with the documented requirement to prepare SELinux for the relevant database engine. Correctly applied persistent contexts allow the kernel to authorize mount and database access while SELinux remains fully enforcing. Nutanix describes the supported model in Security-Enhanced Linux Configuration.

When restoring a PostgreSQL HA instance in NDB, if the standby node fails to restore but the primary node is successfully restored and ready to serve application traffic, NDB considers the database operational from the perspective of the primary node. In this scenario, NDB leaves the database in an "ONLINE" state, reflecting that the primary node is functional and capable of handling requests, even though the HA configuration is not fully intact due to the standby failure. The administrator would need to address the standby node separately (e.g., by re-provisioning or troubleshooting), but the database’s state is determined by the primary node’s readiness.

Option A (PAKFIAL.READY) appears to be a typo and is not a valid NDB state.

Option B (OFFLINE) is incorrect because the primary node is operational, so the database is not offline.

Option C (ONLINE) is correct as it reflects the primary node’s ability to serve traffic.

Option D (RECOVERY PENDING) is incorrect because the primary node has completed recovery and is active, not pending.

This behavior aligns with NDB’s focus on maintaining service availability where possible.

References

Nutanix Database Service (NDB) User Guide, Chapter 5: Configuring Time Machines, Section: Restoring HA Instances

Nutanix Support & Insights, Knowledge Base Article: "Handling Partial Restore Failures in PostgreSQL HA"

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 5: Protect Databases Using Time Machine

Page files are temporary files that Windows uses to store data that does not fit in the physical memory. Page files can interfere with the registration of a database server VM with NDB, as they can cause errors or performance issues. Therefore, page files should be located in a separate drive or partition from the C:\ drive, where the NDB agent and other files are installed. System, database, and backup files do not prevent the registration of a database server VM with NDB, as long as they are not corrupted or incompatible with the NDB requirements. References:

Nutanix Database Management & Automation Training Course, Module 2: Deploying and Configuring an NDB Solution, Lesson 2: Configuring an NDB Instance, Slide 13: Registering Database Server VMs

Nutanix Certified Professional - Database Automation (NCP-DB) 5 Exam, Section 4: Operate and Maintain an NDB Environment, Objective 4.1: Apply procedural concepts to register database server VMs and databases

This is because it allows the database to be refreshed at the exact time specified (9:30 PM) with the most recent data. The other options either perform the snapshot before the desired time or do not specify when the snapshot would occur. Please note that the exact answer might depend on the specific database system and its capabilities. Always refer to the database’s documentation for the most accurate information.

To view information about all roles and the number of users assigned to each in NDB, the user must belong to the Super Administrator role. This role provides full administrative privileges, including access to the "Users and Roles" section of the NDB GUI, where role assignments and user counts are visible. Lower-tier roles (e.g., Database Infrastructure Administrator, Database Administrator, Infrastructure Administrator) have limited scopes and cannot access this comprehensive role/user overview.

Other options are insufficient:

A. Database Infrastructure Administrator: Manages infrastructure but not role/user details.

B. Database Administrator: Focuses on database operations, not user management.

C. Infrastructure Administrator: Handles cluster resources, not role/user analytics.

Thus, the verified answer is D, requiring the highest privilege level.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 1: Introduction to NDB, Lesson 1.4: Managing Users and Roles.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 1: Understand NDB Basics, Objective 1.3: Manage User Permissions (applicable to v7.5).

Nutanix NDB Administration Guide: "Role-Based Access Control (RBAC)" section, detailing Super Administrator privileges.

The Storage Usage widget on the NDB dashboard provides the required entity-level storage information. It displays the percentage of storage consumed by registered Nutanix clusters and NDB entities, including source databases, database clones, and Time Machines. Administrators can use this information to distinguish production database capacity from space consumed by protected copies and downstream clones. NDB periodically collects and stores historical usage information, which also supports storage-trend analysis and capacity forecasting. Prism Element and Prism Central provide infrastructure-level capacity information, but they do not present the same NDB-aware classification of source databases, clones, and Time Machines. NCM reporting is therefore unnecessary for this specific requirement. The official NDB Dashboard reference identifies Storage Usage as the dashboard widget that reports consumption for clusters, data sources, clones, and Time Machines.

To migrate an existing Microsoft SQL Server (MSSQL) database to NDB, the recommended approach is to:

Provision a new database server VM and database: Use the NDB interface to provision a new VM and configure an MSSQL database instance on the Nutanix platform. This leverages NDB’s automated provisioning capabilities to ensure compatibility with Nutanix infrastructure.

Migrate the data: Transfer the data from the existing MSSQL database to the newly provisioned database. This can be achieved using native MSSQL tools (e.g., backup/restore, log shipping, or replication) or NDB’s data migration features, such as cloning or restoring from a backup, depending on the source environment.

Other options are incorrect or incomplete:

A. Use Nutanix Move to migrate the database server VM: Nutanix Move is designed for VM migration between platforms, not for database-specific migrations within NDB, which requires data migration to a new instance.

C. Create a new database server VM and database then register it with NDB: Registering an existing VM with NDB does not handle data migration from the source MSSQL database.

D. Backup your database VM and import it into Nutanix: Backing up the entire VM and importing it does not integrate the database with NDB’s management framework, and data migration would still be required separately.

Thus, the verified answer is B, providing a structured migration process tailored to NDB’s capabilities.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 3: Managing Database Instances, Lesson 3.5: Migrating Databases to NDB.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 3: Manage NDB Solutions, Objective 3.4: Migrate Databases (applicable to v7.5).

Nutanix NDB Administration Guide: "Migrating MSSQL Databases to NDB" section, outlining provisioning and data migration steps.

The correct answer is C because it follows the recommended procedure for applying a CU to a SQL Server Software Profile in NDB. By applying the patch to the profile VM, the administrator ensures that the CU is compatible with the existing Software Profile settings and configuration. By creating a new Software Profile version, the administrator preserves the previous version of the Software Profile for rollback purposes and allows the new version to be tested and published. Option A is incorrect because it deletes the existing Software Profile, which may cause data loss and prevent rollback. Option B is incorrect because it does not apply the patch to the profile VM, which may result in errors or inconsistencies in the Software Profile. Option D is incorrect because it creates a new Software Profile instead of a new version, which may cause confusion and duplication.

The following sources provide more information about the Software Profile management and patching in NDB:

Nutanix Database Management & Automation (NDMA) course, Module 5: Patching Databases Using NDB, Lesson 5.2: Creating and Modifying Software Profiles

Nutanix Certified Professional - Database Automation (NCP-DB) v6.5, Knowledge Objectives, Section 4 - Operate and Maintain an NDB Environment

Nutanix Database Service (NDB) User Guide, Chapter 5: Patching Databases Using NDB, Section 5.2: Creating and Modifying Software Profiles

Nutanix Database Service (NDB) User Guide, Chapter 5: Patching Databases Using NDB, Section 5.3: Testing and Publishing Database Patches

The correct answer is A because the Windows Domain profile is the profile that includes information related to the SQL service startup account and the NDB worker service account. A Windows Domain profile is a collection of settings that define how NDB manages Windows-based database servers and databases. It contains the following information:

The domain name and credentials to join the database server VMs to the domain

The SQL service startup account and password to run the SQL Server service on the database server VMs

The NDB worker service account and password to run the NDB Database Agent service on the database server VMs

The SQL Server authentication mode to use for the databases

By using a Windows Domain profile, the administrator can simplify the database provisioning process by applying the same settings to multiple database server VMs and databases, without having to manually enter them each time. The other options are not correct because they describe different types of profiles that do not include information related to the SQL service startup account and the NDB worker service account. Option B is not correct because the Network profile is a profile that defines the network settings for the database server VMs, such as the IP address, subnet mask, gateway, DNS, and VLAN. Option C is not correct because the Database Parameter profile is a profile that defines the database parameters for the databases, such as the memory, CPU, storage, and performance settings. Option D is not correct because the Software profile is a profile that defines the software settings for the database server VMs and databases, such as the database engine version, edition, and features. References: Nutanix Database Management & Automation (NDMA) course, Nutanix Certified Professional - Database Automation (NCP-DB) certification, Nutanix NCP-DB Certification Exam Syllabus and Study Guide, Nutanix Database Services: Database modernization with Era - Now available

In an NDB high availability (HA) environment spanning multiple Nutanix clusters, with two clusters running VMware ESXi and one running Nutanix AHV, cross-hypervisor compatibility becomes essential to manage the heterogeneous environment effectively. Nutanix Prism Central is the centralized management platform that provides a unified interface and orchestration capabilities across multiple clusters, regardless of the underlying hypervisor (ESXi or AHV). For NDB HA to function seamlessly across these clusters, Prism Central is required to coordinate cluster operations, manage resources, and ensure consistent policy enforcement, including VM placement, failover, and database management tasks. It abstracts the differences between hypervisors, enabling NDB to operate in a mixed environment.

Option A (Stretched VLANs for all nodes) is incorrect because stretched VLANs address network connectivity, not hypervisor compatibility or NDB HA management.

Option B (NGT - Nutanix Guest Tools) is incorrect as NGT enhances guest VM functionality (e.g., drivers, backups) but does not facilitate cross-hypervisor orchestration for NDB HA.

Option C (Nutanix Prism Central) is correct because it provides the necessary multi-cluster management and compatibility layer for NDB HA across ESXi and AHV.

Option D (VirtlO) is incorrect as VirtIO refers to paravirtualized drivers for VMs, not a component for NDB HA or cross-hypervisor support.

Prism Central’s role ensures that NDB can manage database workloads across diverse hypervisor platforms efficiently.

References

Nutanix Database Service (NDB) User Guide, Chapter 3: Configuring an NDB Environment, Section: Multi-Cluster and Multi-Hypervisor Support

Nutanix Prism Central Administration Guide, Section: Managing Mixed Hypervisor Environments

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 3: Configure an NDB Environment

Before patching several Nutanix database server VMs using the "Patch OS now" feature in NDB, the administrator must configure a Repository. A repository (e.g., a custom patch repository or Nutanix-provided source) contains the OS updates or patches (e.g., for Windows or Red Hat-based systems). NDB requires this repository to be specified to fetch and apply the patches, ensuring the database VMs are updated from a validated source.

Other options are unrelated to patching:

B. Active Directory Access: Used for authentication, not patching.

C. pulse: Refers to Nutanix Pulse for support, not patch configuration.

D. An SMTP Server: Configured for alerts, not patching.

Thus, the verified answer is A, reflecting the patching prerequisite.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 6: Maintenance and Patching, Lesson 6.3: Creating Maintenance Plans.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 6: Optimize NDB Solutions, Objective 6.3: Manage Maintenance Plans (applicable to v7.5).

Nutanix NDB Administration Guide: "Configuring Patch Repositories" section.

In Nutanix Database Service (NDB), patching Oracle database engines requires the "Update" button to be available on the database server VM’s management interface. If this button is missing, it typically indicates a configuration issue preventing NDB from performing the patching operation. The most common and critical reason is that the operating system (OS) credentials for the database server VM have not been set or registered with NDB. These credentials are necessary for NDB to authenticate and execute patching tasks on the VM, such as accessing the Oracle software and applying updates via a software profile.

Option A is correct because missing OS credentials prevent NDB from establishing the required connection to the VM, disabling the Update button.

Option B (Database parameters are missing) is incorrect because while database parameters are important for configuration, they do not directly control the visibility of the Update button for patching.

Option C (Oracle DB engines cannot be patched) is incorrect as NDB explicitly supports patching Oracle databases when properly configured.

Option D (Software profile is not published) is incorrect because an unpublished software profile might limit availability to users, but the Update button’s presence relies on VM connectivity, not profile publication status.

To resolve this, the administrator must register valid OS credentials for the VM in NDB, enabling the patching functionality.

References

Nutanix Database Service (NDB) User Guide, Chapter 4: Managing Software Profiles, Section: Patching Database Engines

Nutanix Support & Insights, Knowledge Base Article: "Troubleshooting Missing Update Button in NDB"

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 4: Manage Database Software Profiles

When an administrator experiences issues with NDB and Nutanix Support requests a diagnostics bundle, it can be generated from two valid locations. The NDB GUI provides an option under the administration or support section to create and download the bundle, offering a user-friendly interface. Alternatively, the NDB CLI allows generation via specific commands (e.g., era diagnostics collect), providing a scriptable approach. Both methods are supported for troubleshooting and support purposes.

Option A (Prism Central GUI) is incorrect because diagnostics for NDB are managed within NDB interfaces, not Prism Central.

Option B (Prism Element GUI) is incorrect as Prism Element focuses on cluster management, not NDB-specific diagnostics.

Option C (NDB GUI) is correct as it supports bundle generation via the UI.

Option D (NDB CLI) is correct as it supports bundle generation via command-line tools.

References

Nutanix Database Service (NDB) User Guide, Chapter 6: Administering an NDB Environment, Section: Generating Diagnostics Bundle

Nutanix Support & Insights, Knowledge Base Article: "Collecting NDB Diagnostics for Support"

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 6: Administer an NDB Environment

According to the NDB documentation, the NDB patching process for MongoDB Server Cluster follows these steps1:

NDB identifies the primary member of the MongoDB Server Cluster and patches it first.

NDB triggers a failover to elect a new primary member from the remaining secondary members.

NDB patches the former primary member, which becomes a secondary member after the failover.

NDB patches the remaining secondary members one by one.

NDB verifies the patching status and the cluster health.

This process ensures that the MongoDB Server Cluster always has a primary member available to handle write operations, while minimizing the downtime and the impact on the cluster performance.

 Nutanix Support & Insights, section “Patching a MongoDB Server Cluster”

To add a new Nutanix AHV cluster to the current single default container for database provisioning and enable NDB multi-cluster functionality, the administrator must ensure a unified management framework. Nutanix Prism Central serves as the centralized management platform for multi-cluster environments, allowing NDB to manage multiple clusters (in this case, the existing cluster and the new AHV cluster) under a single instance. Before enabling multi-cluster support in NDB, both clusters must be registered with the same Prism Central instance, and NDB must be confirmed as registered to that instance. This ensures consistent policy enforcement, resource visibility, and database provisioning across clusters using the default container.

Option A (Deploy Nutanix Self Service VM and use blueprints) is incorrect because Nutanix Self Service is an optional tool for end-user provisioning and not a prerequisite for multi-cluster enablement.

Option B (Configure datastore mapping within Prism Element Protection Domains) is incorrect because datastore mapping is a lower-level configuration and not directly required for multi-cluster setup in NDB.

Option C (Enable High Availability for NDB service on the Administration page) is incorrect because HA is a separate configuration for NDB resilience, not a prerequisite for multi-cluster support.

Option D is correct as it aligns with NDB’s requirement for Prism Central integration to manage multiple clusters effectively.

This configuration ensures seamless multi-cluster operation.

References

Nutanix Database Service (NDB) User Guide, Chapter 3: Configuring an NDB Environment, Section: Multi-Cluster Configuration

Nutanix Prism Central Administration Guide, Section: Managing Multiple Clusters

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 3: Configure an NDB Environment

To ensure the NDB server, NDB agent, and NDB database agent can communicate with the registered cluster via REST API calls, port 2009 must be opened. This port is used by NDB components to facilitate RESTful communication with the Nutanix cluster (e.g., Prism Element or Prism Central) for operations such as provisioning, monitoring, and management. Proper firewall configuration to allow traffic on this port is a prerequisite for NDB’s integration with the cluster.

Other options are incorrect:

B. 3205: Not a standard NDB port; used for other Nutanix services.

C. 3260: Associated with iSCSI, not REST API communication.

D. 9440: Used for Prism Element’s HTTPS management interface, not NDB-specific REST calls.

Thus, the verified answer is A, reflecting NDB’s REST API requirements.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 2: Deploying and Configuring an NDB Solution, Lesson 2.1: Network and Port Requirements.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 2: Deploy and Configure an NDB Solution, Objective 2.1: Prepare Hosts (applicable to v7.5).

Nutanix NDB Installation Guide: "Network Ports and Protocols" section, specifying port 2009.

A Time Machine frozen status indicates that the database that was associated with the Time Machine has been de-registered from NDB, but the Time Machine itself has not been deleted. This means that the Time Machine still contains the snapshots and logs of the de-registered database, but it cannot perform any further operations on it. To resume the normal functioning of the Time Machine, the administrator can either re-register the database with NDB, or delete the Time Machine and free up the storage space.

 Nutanix Support & Insights, section “Resolving All Alerts for a Time Machine”

When completing the NDB (Nutanix Database Service) Wizard for initial setup or configuration, certain steps are mandatory to ensure the environment is properly configured, while others are optional based on specific needs. Network Segmentation is an optional step that allows for advanced network isolation and configuration, but it is not required for basic NDB deployment. Mandatory steps include specifying the NDB Cluster Name, selecting a Storage Container, and configuring Services (e.g., database services), as these are essential for NDB to function and manage databases.

Option A (Network Segmentation) is correct as it is an optional feature for advanced networking, not a required step in the wizard.

Option B (NDB Cluster Name) is incorrect because assigning a cluster name is a mandatory step to identify the NDB instance.

Option C (Storage Container) is incorrect because selecting a storage container is required for data storage and protection.

Option D (Services) is incorrect because configuring services (e.g., database engines) is a core requirement for NDB operation.

Note: The question mentions "NDE Wizard," which is assumed to be a typo for "NDB Wizard" based on context.

References

Nutanix Database Service (NDB) User Guide, Chapter 1: Deploying NDB, Section: Completing the NDB Wizard

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 1: Deploy NDB

According to the Nutanix Database Automation (NCP-DB) learning documents, metadata tags can be applied to various entities in Nutanix Era for better database inventory management1. Among the options provided, Databases and Clones are two entities that support metadata tags1. These tags can be used to categorize, search, and manage these entities more effectively1. Please note that the information might be available in the Nutanix Database Automation (NCP-DB) course materials or in the Nutanix Era documentation.

To register an Oracle Database Server VM to Era in Nutanix Database Automation (NCP-DB), certain dependencies must be met. One of these is that SUDO NOPASS access is required1. This allows the Era service to perform necessary operations on the Oracle Database Server VM. As for assigning a static IP address to the Era VM on ESXi, you can use the vSphere Client to configure static IP settings2. However, this is not directly related to the registration of an Oracle Database Server VM to Era. Please note that these answers are based on the information available as of my last update in 2021 and may need to be verified with the most recent Nutanix Database Automation (NCP-DB) documentation or resources.

An administrator can configure a custom SSL certificate for Era through the Era User Interface (UI)1. This can be done by logging into the Nutanix Console and selecting SSL Certificates from the drop-down list inside the gear icon23. In the SSL Certificate dialog box, the administrator can click Replace Certificate, then select the Import Key and Certificate radio button23. This process ensures secure communication within the Nutanix Era environment4.

After a DBA’s script corrupts an Oracle DB managed by NDB, the administrator needs to restore a clean copy using the latest available snapshot. The most straightforward action is to use the NDB Time Machine feature to select the most recent uncorrupted snapshot and create a new clone. This clone can serve as a restored version of the database, bypassing the corrupted data while leveraging existing snapshots for efficiency.

Option A (Fail the Oracle cluster over to a surviving RAC node) is incorrect because RAC failover is for HA, not corruption recovery via snapshots.

Option B is correct as it uses Time Machine to create a clone from a valid snapshot, addressing the corruption.

Option C (Use Time Machine to create a clone from file-level database backup) is incorrect because NDB primarily uses snapshots, not file-level backups, for cloning.

Option D (Provision a new Oracle DB and perform log catch-up) is incorrect because provisioning a new DB is more complex and unnecessary when a snapshot-based clone suffices.

This method ensures rapid recovery with minimal disruption.

References

Nutanix Database Service (NDB) User Guide, Chapter 5: Configuring Time Machines, Section: Restoring and Cloning from Snapshots

Nutanix Support & Insights, Knowledge Base Article: "Recovering from Database Corruption in NDB"

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 5: Protect Databases Using Time Machine

NDB provisions MongoDB by using standardized profiles that define the database software, network, compute, and database parameters. For MongoDB, Oracle, and SQL Server, Nutanix requires a Software Profile before a new database can be provisioned. The profile supplies the validated MongoDB binaries and configuration baseline that NDB uses to construct the database server VM and install the database engine. Database Parameter Profiles can refine runtime settings, but they do not replace the required software source. A Time Machine policy becomes relevant after provisioning when protection is configured, while database patches are incorporated through Software Profile versions rather than uploaded as the first provisioning step. Therefore, creating the Software Profile is the required first task. Nutanix NDB Profiles documentation

When consolidating Microsoft SQL Server instances on database server VMs managed by NDB using a medium compute profile, concerns about DB storage capacity can arise due to increased demand. In NDB, the appropriate task to address this is to "Update the Database Server VMs," which allows the administrator to adjust resource allocations, including storage capacity, for the VMs hosting the databases. This task can be performed within the NDB interface to expand disk space or reconfigure storage settings without altering the compute profile or requiring external tools.

Option A (Update the Database server VMs) is correct as it provides a direct method in NDB to modify VM resources, including storage.

Option B (Expand vDisk in Prism Element) is incorrect because NDB manages database VMs holistically, and storage expansion should be handled through NDB’s Update task rather than Prism Element directly.

Option C (Update the compute profile) is incorrect because compute profiles define CPU and memory, not storage capacity.

Option D (Scale the source database) is incorrect as scaling typically refers to database-level adjustments (e.g., adding nodes), not VM storage expansion.

This approach ensures seamless integration with NDB’s management framework.

References

Nutanix Database Service (NDB) User Guide, Chapter 4: Managing Database Servers, Section: Updating Database Server VMs

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 4: Manage Database Servers

To capture database transaction logs in NDB, the Log Catch-up operation within the Time Machine is used. Log Catch-up retrieves and applies transaction logs (e.g., PostgreSQL WAL, SQL Server logs) to a snapshot, ensuring the database can be restored to a specific point in time. This operation bridges gaps between snapshots by incorporating log data, maintaining a continuous recovery chain.

Other options are incorrect:

A. Write-Ahead Logging: A database feature (e.g., in PostgreSQL), not an NDB Time Machine operation.

B. Log Flush: Refers to writing logs to disk, not capturing them for recovery.

D. Snapshots: Capture the database state but do not handle transaction logs specifically.

Thus, the verified answer is C, aligning with NDB’s log management.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 5: Data Protection and Recovery, Lesson 5.2: Managing Time Machines.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 5: Protect Databases Using NDB, Objective 5.2: Manage Time Machine Operations (applicable to v7.5).

Nutanix NDB Administration Guide: "Log Catch-up Operation" section.

Time Machine data access is a feature of Nutanix Database Service (NDB) that allows you to access a point-in-time snapshot of a database without restoring it. To use this feature, you need to create a Data Access Management (DAM) policy that defines the access mode, the source database, the destination cluster, and the storage container mapping. The storage container mapping is needed when the source database and the NDB Server containers are different, because NDB needs to know where to store the metadata and the clone of the source database. If the source database and the NDB Server containers are the same, then NDB will use the same container for both the metadata and the clone. References:

Nutanix Certified Professional - Database Automation (NCP-DB), Section 5 - Protect NDB-managed Databases Using Time Machine

Database (NCP-DB) Exam Blueprint Guide - Nutanix, Page 9, Objective 5.6

Nutanix Database Management & Automation (NDMA) course, Module 4, Lesson 4.2 - Data Access Management

To release PostgreSQL HA instances using a dedicated subnet in Nutanix Database Service (NDB), the administrator must create a network profile that defines the subnet and its associated VLAN. Before creating this network profile, it is mandatory to add a VLAN to the NDB Networks configuration. This VLAN ensures that the dedicated subnet is recognized and manageable within NDB, allowing the HA instances to be provisioned with isolated network connectivity. The VLAN must be configured in the NDB Networks page to be available for selection during network profile creation.

Option A (The subnet in Prism Element must be IPAM configured) is incorrect because IP Address Management (IPAM) configuration in Prism Element is optional and not a mandatory prerequisite for creating a network profile in NDB.

Option B (The DB VMs must be registered first) is incorrect because VM registration is a subsequent step, not a prerequisite for network profile creation.

Option C (A VLAN must be added to NDB networks) is correct as it is a required step to define the network infrastructure before creating the profile.

Option D (Configure Network Segmentation) is incorrect because network segmentation is an advanced feature and not mandatory for basic network profile setup.

This ensures the dedicated subnet is properly integrated into NDB for HA provisioning.

References

Nutanix Database Service (NDB) User Guide, Chapter 3: Configuring an NDB Environment, Section: Configuring Network Profiles

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 3: Configure an NDB Environment

The recovery plans policy defines the Time Machine data availability across multiple registered clusters in NDB. The recovery plans policy allows the database administrator to specify the source and target clusters, the frequency and retention of the cross-cluster snapshots, and the network and compute profiles for the recovery operations. The recovery plans policy helps to ensure the disaster recovery and business continuity of the NDB-managed databases in case of a cluster failure or outage.

The data access management policy defines the access permissions and roles for the NDB users and groups. The data access management policy allows the database administrator to grant or revoke access to the NDB instance, the database server VMs, the databases, and the database operations. The data access management policy helps to ensure the security and compliance of the NDB-managed databases and users.

The data protection policy defines the backup and restore settings for the NDB-managed databases. The data protection policy allows the database administrator to specify the frequency, retention, and compression of the database snapshots, and the backup location and encryption for the database backups. The data protection policy helps to ensure the backup and recovery of the NDB-managed databases within the same cluster.

The service level agreements policy defines the performance and availability metrics for the NDB-managed databases. The service level agreements policy allows the database administrator to monitor and enforce the database uptime, latency, throughput, and IOPS. The service level agreements policy helps to ensure the quality of service and performance of the NDB-managed databases.

Nutanix Database Management & Automation Training Course, Module 4: Nutanix Era Configuration, Lesson 4.1: Nutanix Era Configuration, slide 9.

Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.1: Nutanix Era Operations, slides 8, 12, 16, 20.

Nutanix Database Management & Automation Training Course, Module 6: Nutanix Era Disaster Recovery, Lesson 6.1: Nutanix Era Disaster Recovery, slides 5-7.

In this scenario, a PostgreSQL instance managed by NDB on a Linux VM is malfunctioning after a manual OS update, and a new Linux DB server VM has been prepared to host the data. To migrate the data to the new VM, the administrator must integrate the new VM into NDB’s management framework. The correct action is to register the new DB Server VM in NDB, which allows NDB to recognize and manage the VM as a database server. Once registered, the administrator can use NDB’s features (e.g., cloning, restoring, or reprovisioning) to migrate the data from the broken instance to the new VM.

Here’s why the other options are incorrect:

A. Provision a new PostgreSQL instance from the Databases page: This creates a fresh instance without migrating existing data, losing the broken instance’s data unless separately restored.

B. From The Machine policy, Authorize Database Server VMs: Machine policies in NDB define rules for VM management, but authorizing VMs is not a direct migration action and assumes prior registration.

C. Follow the Provision a PostgreSQL Instance wizard: Similar to A, this provisions a new instance rather than migrating data to an existing prepared VM.

Registering the new VM in NDB (via the "Database Server VMs" section) enables the administrator to associate it with the existing PostgreSQL instance’s configuration and perform a data migration (e.g., using a snapshot or backup). This aligns with NDB’s workflow for replacing a broken server. Thus, the verified answer is D.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 3: Managing Database Instances, Lesson 3.3: Registering and Managing Database Server VMs.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 3: Manage NDB Solutions, Objective 3.2: Register and Manage DB Server VMs (applicable to v7.5).

Nutanix NDB Administration Guide: "Registering a Database Server VM" section.

In Nutanix Database Automation (NCP-DB), when an administrator logs into Era and sees a message “Update Available” on the Status of the Software Profile Version, it indicates that a newer version of the software profile is available1. The administrator should manually update the software profile to the latest version12. This process ensures that the database VM is running the most recent and compatible version of the software12.

After a new NDB deployment, the administrator can test the provisioning capabilities using a database instance that is fully supported and readily configurable out of the box. PostgreSQL is the most suitable option because it is one of the core database engines supported by NDB from the initial deployment, with built-in provisioning templates and HA capabilities. NDB provides a streamlined process to provision PostgreSQL instances, making it an ideal choice for testing provisioning workflows, including VM creation, storage allocation, and network configuration.

Other options may require additional setup or licensing:

B. Oracle DB: Requires specific licensing and additional configuration, not typically available for initial testing.

C. MSSQL Server: Supported but may need Microsoft licensing and setup, less immediate than PostgreSQL.

D. MongoDB: Supported but less commonly used for initial testing due to its NoSQL nature and additional configuration needs.

Thus, the verified answer is A, reflecting PostgreSQL’s accessibility for testing.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 3: Managing Database Instances, Lesson 3.1: Provisioning Databases.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 3: Manage NDB Solutions, Objective 3.1: Provision Database Instances (applicable to v7.5).

Nutanix NDB Administration Guide: "Supported Databases for Provisioning" section, noting PostgreSQL availability.

To provision a PostgreSQL HA instance from a software profile created from a VM with services like etcd, HAProxy, Patroni, and keepalived installed, the administrator must ensure the instance aligns with NDB’s HA framework. These services (e.g., Patroni for PostgreSQL HA management, HAProxy for load balancing) may conflict with NDB’s built-in HA mechanisms. Provisioning an HA instance with these services disabled allows NDB to manage HA using its native replication and failover capabilities (e.g., streaming replication), avoiding duplication or interference from the VM’s pre-installed services.

Option A (Provision an HA instance with the services enabled) is incorrect because enabling these services may cause conflicts with NDB’s HA management.

Option B (Disable the services, create a software profile version, and provision an HA instance) is incorrect because disabling services and recreating a profile is unnecessary; the provisioning step can handle service configuration.

Option C (Provision an HA instance with the services disabled) is correct as it ensures NDB’s HA features take precedence without interference.

Option D (Enable the services, create a software profile version, and provision an HA instance) is incorrect due to potential conflicts with NDB’s HA implementation.

Note: The typo "PostqreSQL" is assumed to mean "PostgreSQL."

References

Nutanix Database Service (NDB) User Guide, Chapter 4: Managing Database Engines, Section: Provisioning HA Instances

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 4: Manage Database Engines

The correct answer is B because setting VM-Host affinity ensures that the DB Server VMs are not migrated to another host during the LCM upgrade process. This way, the DB Server VMs can continue to serve the database requests without interruption. Option A is incorrect because updating the Nutanix cluster does not prevent the DB Server VMs from being moved to another host. Option C is incorrect because removing the Nutanix cluster from NDB will make the DB Server VMs unmanaged by NDB and lose the benefits of NDB features. Option D is incorrect because unsetting VM-Host affinity will allow the DB Server VMs to be migrated to another host during the LCM upgrade process, which may cause downtime or performance degradation.

The following sources provide more information about the LCM upgrades and VM-Host affinity in NDB:

Nutanix Database Management & Automation (NDMA) course, Module 6: Administering an NDB Environment, Lesson 6.3: Performing NDB Software Upgrades

Nutanix Certified Professional - Database Automation (NCP-DB) v6.5, Knowledge Objectives, Section 6 - Administer an NDB Environment

Nutanix Database Service (NDB) User Guide, Chapter 8: Administering an NDB Environment, Section 8.3: Performing NDB Software Upgrades

Nutanix Support & Insights, Your guide to the Upgrades, LCM Design

Nutanix Life Cycle Manager Guide, Chapter 3: Upgrading Software and Firmware, Section 3.2: Preparing for an Upgrade, VM-Host Affinity

To allow a non-administrative NDB user to provision an Oracle database using a Software Profile created by an administrator, the administrator must promote the Software Profile to Published. In NDB, Software Profiles define the database software version and configuration (e.g., Oracle binaries). By default, a newly created profile is in a draft or private state. Promoting it to "Published" makes it available for use by other NDB users, including non-administrative ones, within the access control framework. This ensures the profile is validated and accessible without requiring individual user assignments.

Other options are incorrect:

A. Ensure that specified users have access to the Software Profile using Access Control: Access Control manages user permissions but does not make the profile available unless it is published.

B. Replicate the Software Profile to other Nutanix clusters: Replication is for HA or disaster recovery, not user access.

C. Ensure that the Software Profile has been properly versioned to the latest release of Oracle: Versioning ensures compatibility but does not grant user access.

Thus, the verified answer is D, aligning with NDB’s profile management workflow.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 3: Managing Database Instances, Lesson 3.1: Managing Software Profiles.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 3: Manage NDB Solutions, Objective 3.1: Configure Software Profiles (applicable to v7.5).

Nutanix NDB Administration Guide: "Publishing Software Profiles" section.

The minimum frequency configurable for the NDB Log Catch-up operation is 15 minutes. This setting determines how frequently the log catch-up process runs, which is crucial for maintaining data integrity and ensuring up-to-date database states.

To automate OS and database patching in a Nutanix NDB environment, the administrator should configure a Maintenance Window. A Maintenance Window in NDB allows the administrator to schedule automated patching tasks (e.g., OS updates and database software updates) during specified time periods, minimizing disruption to production workloads. This feature integrates with software profiles and can be set to run periodically or on-demand, ensuring patches are applied efficiently and consistently across the environment.

Option A (Access Control) is incorrect because Access Control manages user permissions, not automation of patching.

Option B (Pulse) is incorrect because Pulse is a monitoring tool, not a scheduling mechanism for patching.

Option C (Maintenance Window) is correct as it provides the scheduling and automation framework for patching activities.

Option D (SMTP Server) is incorrect because SMTP is for email notifications, not patching automation.

This configuration enhances operational efficiency and reliability.

References

Nutanix Database Service (NDB) User Guide, Chapter 4: Managing Software Profiles, Section: Scheduling Maintenance Windows

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 4: Manage Database Software Profiles

 According to the Nutanix Database Automation (NCP-DB) learning documents, when provisioning a new database, there are two options available for the target12:

Provision database to an existing registered: This option allows you to provision a database to an existing registered database server. This is useful when you want to add a database to a server that is already being managed by Nutanix Era1.

Provision databases to a new container: This option allows you to provision a database to a new container. This is useful when you want to create a new isolated environment for your database1.

The "Savings over traditional cloning" metric in the Data Usage widget on the NDB dashboard reflects the efficiency of NDB’s cloning technology compared to traditional full-copy cloning methods. NDB leverages Nutanix’s near-zero byte cloning capability, which creates lightweight clones by sharing base data and only storing changes (deltas). This metric specifically quantifies the disk space saved by using these efficient clones instead of duplicating entire datasets, as would occur in traditional cloning. It highlights NDB’s storage optimization for database provisioning and management.

Option A is correct as it directly ties to NDB’s near-zero byte cloning technology, a core feature for space efficiency.

Option B (Compression) is incorrect because compression is a separate storage optimization technique not specifically tied to cloning savings.

Option C (Shadow clones) is incorrect because shadow clones are a Nutanix feature for caching, not the cloning mechanism used by NDB Time Machines.

Option D (Deduplication) is incorrect as deduplication, while related to storage savings, is not the primary mechanism reflected in this cloning-specific metric.

This metric helps administrators quantify the benefits of NDB’s cloning approach in terms of storage utilization.

References

Nutanix Database Service (NDB) User Guide, Chapter 1: Introduction to NDB, Section: Understanding Cloning and Storage Efficiency

Nutanix Support & Insights, Technical Note: "Interpreting NDB Dashboard Metrics"

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 1: NDB Concepts and Architecture

When an Oracle database is upgraded using Era, the type of upgrade category is an “In-place upgrade”. This method involves upgrading the database software within the same Oracle home as the existing database. The AutoUpgrade utility is used to automate the upgrade process, both before starting upgrades, during upgrade deployments, and during post-upgrade checks and configuration migration1. This method is preferred due to its simplicity and efficiency1.

When an administrator creates a new SQL Server software profile version to apply the latest cumulative update, they should update the software profile version and set the status to Published1. This makes the new profile version available to all users. NDB will show available updates for any database server using the software profile as soon as the new profile version is published1.

In NDB, publishing a software profile update for Microsoft SQL Server makes it available for broader use within the NDB environment. When an administrator creates and publishes an updated software profile (e.g., with a new SQL Server patch or version), this action allows all authorized NDB users to leverage that profile to patch or update the database software on their managed VMs. This is a key feature of NDB’s software profile management, enabling centralized control and distribution of standardized database configurations.

Option A is correct because publishing a profile democratizes access, allowing all users to apply the update to their database VMs, aligning with NDB’s collaborative administration model.

Option B is incorrect because it suggests the profile patches itself, which is not the intent; publishing enables usage, not self-application.

Option C is incorrect because publishing does not automatically deprecate older profiles; deprecation is a separate administrative decision.

Option D is incorrect because publishing facilitates patching, not stalls it.

This process enhances efficiency and consistency in managing SQL Server updates across an organization.

References

Nutanix Database Service (NDB) User Guide, Chapter 4: Managing Software Profiles, Section: Creating and Publishing Software Profiles

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 4: Manage Database Software Profiles

Nutanix Era offers Role-Based Access Control capabilities by organically embedding them in the product. It provides the ability to add and remove users from Era, create and assign roles to users, and associate various privileges with a role1. The default roles available within Era for Role-Based Access Control are:

prism Admin

Era Super Admin

Era Database Admin

Era Infrastructure Admin1 These roles allow for the management of both physical resources like IP addresses and VLANs along with database entities like databases, time-machines, clones, and so on1.

For an NDB offline upgrade, you need to download the upgrade bundle from the Nutanix Support Portal and copy it to the NDB server. Then, you need to use the NDB CLI command upload upgrade_bundle with the path parameter to specify the location of the upgrade bundle file. This command will upload the upgrade bundle to the NDB server and verify its integrity. After uploading the upgrade bundle, you can use the upgrade command to perform the upgrade. References: Nutanix Support & Insights, Cisco Nexus Data Broker Deployment Guide, Release 3.10.x

Nutanix Era is a database management system that provides API endpoints for automation and integration with external applications. These API calls are typically made over HTTPS for security, and the standard ports for HTTPS are 443 and 94401. Please note that the actual ports used can depend on the specific configuration of the Nutanix Era system. It’s always a good idea to check the system’s documentation or consult with the system administrator for the most accurate information.

The administrator should begin with the NDB dashboard because its Storage Usage information provides a consolidated view of capacity consumed by registered clusters and NDB-managed entities. The dashboard distinguishes consumption associated with source databases, clones, and Time Machines, making it the fastest location for identifying the largest storage consumers before investigating an individual entity. Database Server Details focuses on a selected server and does not provide the same environment-wide comparison. Time Machine Properties applies only to a particular protection entity, while Software Profile Management concerns database software images and versions rather than database storage consumption. NDB also records historical storage information, enabling administrators to assess trends and determine whether capacity pressure is increasing. Nutanix’s official NDB Dashboard documentation confirms that the Storage Usage view reports consumption for data sources, clones, Time Machines, and registered Nutanix clusters.

Option A: On the Era Dashboard Database Summary Table under Source Database. The dashboard provides a summary of the databases, including their sizes1.

Option B: Under the Capacity widget on the Database Server VMS > List database summary page. While this might provide information about the capacity, it does not specifically provide the size of a Source Database.

Option C: On the Databases > Sources table. This table provides detailed information about the databases, including their sizes1.

Option D: On the Profiles > Database Parameters list for the assigned DB Parameter Profile. This list provides parameters for the database but does not provide the size of a Source Database.

When an administrator is asked to add a database to a PostgreSQL instance already managed by NDB, the most appropriate task is to add a new database to the existing source database. In NDB, a PostgreSQL instance refers to a managed database server or cluster, and adding a new database involves creating it within the existing instance using NDB’s database management capabilities. This can be done through the NDB GUI or CLI by selecting the source database and adding the new database, leveraging the current configuration and resources without requiring new VM provisioning.

Option A (Add a new database to a source DB) is correct as it directly addresses adding a database to an existing managed instance.

Option B (Register a new DB VM to add the DB) is incorrect because a new VM registration is unnecessary when the instance is already managed.

Option C (Provision a new DB server VM and add the new DB) is incorrect because provisioning a new VM is overkill for adding a database to an existing instance.

Option D (Update a database clone to add a new DB) is incorrect because clones are read-only copies, not suitable for adding new databases.

This approach ensures efficiency and leverages the existing NDB-managed infrastructure.

References

Nutanix Database Service (NDB) User Guide, Chapter 4: Managing Database Engines, Section: Managing Databases in an Instance

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 4: Manage Database Engines

Failed NDB provisioning workflows normally perform a rollback that removes resources created during the unsuccessful operation, including the database server VM. For troubleshooting, the administrator can enable the global skip_rollback_global setting so that NDB does not execute this cleanup path. The failed VM is then preserved for inspection of its operating-system state, logs, network configuration, and database installation artifacts. Nutanix Support states that automatic deletion occurs only when delete_vm_on_failure is true and skip_rollback_global is false; other combinations preserve the VM and require manual cleanup afterward. Because the question specifically asks which global rollback option must be enabled, skip_rollback_global is the correct selection. It should be returned to its normal value after troubleshooting to avoid abandoned resources. Nutanix KB 14629

The correct answer is B because the Time Machine feature of NDB collects logs and snapshots from databases and stores them in a distributed file system. The Time Machine enables the administrator to protect, clone, and restore databases using the SLA policies and the NDB UI or API. The Time Machine also manages the replication of database snapshots in an NDB multicluster environment. The other options are not correct because they describe different features or functions of NDB. Option A is not correct because Database Restore is an operation that uses the Time Machine to restore a source database or a clone to a previous point in time. Option C is not correct because SLA is a policy that defines the frequency and retention of database snapshots and logs. Option D is not correct because One-click Patching is a feature that allows the administrator to test, publish, and apply database patches using the NDB UI or API. References: Nutanix Database Management & Automation (NDMA) course, Nutanix Certified Professional - Database Automation (NCP-DB) certification, Nutanix NCP-DB Certification Exam Syllabus and Study Guide, Nutanix Support & Insights

 According to the Nutanix Database Automation (NCP-DB) learning documents, when dealing with an Availability Group (AG) database, the database should be registered as an Availability database1. This is because the AG database is hosted on replicas with different named instances, and registering it as an Availability database allows for Copy Data Management operations to be performed across all instances. This is particularly important when services such as the Analytics service running on SQLAGN3\DW require real-time data1.

Based on the exhibit, the administrator is logged in with the Database Admin account (bsmith@ntnxlab.local), which does not have the permission to create local users on NDB. Only the Super Admin account (bsmith) has this permission, as indicated by the User type column. Therefore, the administrator needs to log out and log in again with the Super Admin account to add a new database admin as a local user to NDB. References: Nutanix Database Automation (NCP-DB) Course Details, Nutanix Database Automation (NCP-DB) Certification Details, Nutanix Database Automation (NCP-DB) YouTube Playlist, Nutanix Database Automation User Guide.

Configuring VM Host Affinity in a Nutanix AHV-powered cluster ensures that VMs are placed on specific hosts to optimize performance or HA. However, after a host failure, if database VMs cluster on a single remaining host, it indicates that the affinity rules alone are insufficient to maintain high availability (HA) during failover scenarios. To prevent this, the administrator should configure anti-affinity rules, which dynamically ensure that VMs (e.g., database server VMs) are spread across multiple hosts. Anti-affinity rules override default VM placement behavior during failover, reducing the risk of a single point of failure by keeping VMs separated even after a host outage.

Option A (Assign additional backup VMs on the same host) is incorrect because placing backups on the same host increases risk rather than mitigating it.

Option B (Increase affinity zones) is incorrect as "affinity zones" is not a standard Nutanix term in this context, and it does not address dynamic VM separation.

Option C (Configure automatic host failover in Prism Central) is incorrect because while failover is managed by AHV, it does not inherently prevent VMs from clustering without specific rules.

Option D is correct as anti-affinity rules proactively distribute VMs, enhancing HA in failure scenarios.

This approach leverages Nutanix AHV’s VM placement policies to ensure resilience.

References

Nutanix Database Service (NDB) User Guide, Chapter 3: Configuring an NDB Environment, Section: Configuring VM Affinity and Anti-Affinity

Nutanix AHV Administration Guide, Section: VM High Availability and Placement Rules

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 3: Configure an NDB Environment

NDB Time Machine protects Microsoft SQL Server databases through application-consistent snapshots and a continuous sequence of transaction-log backups captured by Log Catch-up operations. When the latest protected time is selected, NDB uses the appropriate snapshot as the baseline and applies the required transaction logs through the most recent available recovery point. This produces a transactionally consistent clone rather than a crash-consistent VM copy. NDB does not need to leave the source database in read-only mode, and Volume Shadow Copy Service alone cannot provide the transaction-log replay required for granular point-in-time cloning. “Latest Time” means the latest point covered by the valid Time Machine snapshot and log chain, not an unprotected wall-clock instant after the last log capture. Nutanix’s Database Log Backup Management documentation explains that Log Catch-up captures database transaction logs for point-in-time cloning.

 Nutanix Database Service (NDB) supports automated minor version upgrades for PostgreSQL1. Before applying the patch, the administrator should create a new software profile2. This is because the software profile contains the database engine binaries and other software required to run the database engine2. Therefore, to apply a minor version upgrade, a new software profile with the updated binaries needs to be created2. Once the new software profile is created, it can be used to patch the PostgreSQL database2.

The first NDB management-plane VM on an AHV-based Nutanix cluster is deployed from the NDB QCOW2 disk image. The administrator downloads the QCOW2 image from the Nutanix Support portal, configures it through the Prism Element Image Service, and then creates the NDB VM from that image. QCOW2 is the appropriate virtual-disk format for AHV because AHV uses the KVM virtualization stack. VMDK is principally associated with VMware virtual disks, VHDX is used by Microsoft Hyper-V, and VDI is associated primarily with Oracle VirtualBox. Those formats are not used for the initial NDB VM deployment on a dedicated AHV cluster. Consequently, option C is correct. The VM must subsequently receive the required compute, network, and static-IP configuration before NDB initial setup is completed. NDB User Guide—Installing NDB on AHV

================

In Nutanix Database Automation (NCP-DB), the Time Machine feature is used for protecting databases and creating database clones. To create a database clone using the Era Interface, an administrator should select Time Machines, select a source database, and then choose Create Clone12. This process allows the administrator to create a copy of the source database at a specific point in time1.

When an administrator enables NDB Multi-cluster functionality, certain components are deployed or reconfigured to support the distributed environment. HAProxy (High Availability Proxy) is a critical component that manages load balancing and secure communication across clusters. In a multi-cluster setup, HAProxy is deployed on a dedicated VM to ensure efficient traffic distribution and high availability for NDB services, such as API calls and GUI access, across the clusters. This dedicated deployment enhances scalability and resilience.

Option A (Agent VM) is incorrect because Agent VMs are typically deployed on managed database VMs, not as dedicated NDB service components in multi-cluster setups.

Option B (HAProxy) is correct as it is specifically deployed on a dedicated VM to handle load balancing in a multi-cluster NDB environment.

Option C (Repository DB) is incorrect because the Repository DB is part of the NDB control plane and not necessarily deployed on a separate VM for multi-cluster purposes.

Option D (APIVM) is incorrect because the API VM is part of the core NDB infrastructure but not specifically deployed as a dedicated VM for multi-cluster enablement.

References

Nutanix Database Service (NDB) User Guide, Chapter 3: Configuring an NDB Environment, Section: Multi-Cluster Configuration

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 3: Configure an NDB Environment

In Nutanix Database Service (NDB), the Time Machine (TM) feature allows restores, including Point-in-Time (PIT) restores, which require continuous log retention to replay transaction logs to a specific moment. If the option to restore data to a Point in Time is unavailable, it indicates that the current Time Machine Service Level Agreement (SLA) does not support continuous log retention. NDB SLAs are categorized (e.g., BRONZE, SILVER, GOLD), with BRONZE or higher levels required to enable PIT restore by including continuous log retention. The administrator must update the TM SLA to at least BRONZE to enable this feature, ensuring logs are retained for PIT operations.

Option A (Restore Source DB using a snapshot) is incorrect because a snapshot-only restore does not support PIT; it restores to the snapshot time only.

Option B (Update TM SLA to BRONZE or higher) is correct as it enables continuous log retention necessary for PIT restores.

Option C (Create DB clone using a snapshot) is incorrect because cloning from a snapshot does not provide PIT capability without log retention.

Option D (Update TM SLA to BRASS or lower) is incorrect because "BRASS" is not a valid SLA tier, and lowering the SLA would not enable PIT.

This adjustment ensures PIT restore functionality.

References

Nutanix Database Service (NDB) User Guide, Chapter 5: Configuring Time Machines, Section: Configuring SLAs for Point-in-Time Restore

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Blueprint, Section 5: Protect Databases Using Time Machine

When using the "Patch OS now" feature in NDB to apply updates to a Red Hat-based operating system, the administrator can limit updates to security patches only by leveraging the Advanced Options. Under the "Custom commands" section of the operating system patching command window, entering yum update --security instructs the package manager to install only security-related updates. This ensures the system remains secure without applying all available updates, which could introduce instability.

Other options are incorrect or incomplete:

A. Point the database VM to a custom patch repository and enter yum update --security command: This requires manual intervention outside NDB’s patching framework.

B. Check Advanced Options and under Pre-post commands, enter yum update security in the pre-operating system patching command window: Pre-post commands are for pre/post actions, not the main patching process, and the syntax lacks the --security flag.

C. Point the database VM to a custom patch repository before using the Patch OS now feature: This sets up a repository but doesn’t specify security-only updates within NDB’s interface.

Thus, the verified answer is D, aligning with NDB’s patching customization.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 6: Maintenance and Patching, Lesson 6.3: Creating Maintenance Plans.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 6: Optimize NDB Solutions, Objective 6.3: Manage Maintenance Plans (applicable to v7.5).

Nutanix NDB Administration Guide: "Patch OS Now with Custom Commands" section.

NDB supports high availability (HA) across multiple Nutanix clusters, including those in separate data centers, by replicating data and ensuring failover capabilities. However, NDB imposes strict network latency requirements for HA. The official documentation specifies that the round-trip time (RTT) latency between clusters should not exceed 25ms for HA to function effectively. If the latency between two clusters exceeds this threshold (e.g., due to geographic distance or network issues), HA cannot be enabled, as the synchronization and failover mechanisms rely on low-latency communication to maintain consistency and performance.

Impact of other options:

A. HA will operate with increased delay: While latency might cause delays, exceeding 25ms RTT prevents HA setup entirely, not just delays its operation.

C. The clusters will not synchronize: Synchronization issues may occur as a symptom, but the primary impact is HA enablement failure.

D. There will be no impact on HA functionality: This is incorrect, as latency beyond 25ms RTT violates HA prerequisites.

Thus, the verified answer is B, reflecting NDB’s latency constraints for HA across clusters.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 4: High Availability and Disaster Recovery, Lesson 4.2: Configuring Multi-Cluster HA.

Nutanix Certified Professional - Database Automation (NCP-DB) v7.5Knowledge Objectives, Section 4: Troubleshoot NDB Solutions, Objective 4.3: Configure HA Across Clusters (applicable to v7.5).

Nutanix NDB Administration Guide: "High Availability Configuration Requirements" section, specifying latency limits.