NCP-DB Nutanix Certified Professional - Database Automation (NCP-DB v6.10) Free Practice Exam Questions (2025 Updated)

The NDB database agent is a service that runs on each database server VM and communicates with the NDB instance. It uses port 443 for HTTPS API calls and port 9440 for Nutanix cluster API calls. These ports are required to be open on the database server VMs for NDB to function properly. References: Nutanix Database Management & Automation (NDMA), page 9; Ports and Protocols Reference Chart | Nutanix Community, section “Nutanix Database Service (NDB)”

A new web application with up to 200 concurrent connections to a PostgreSQL database requires a robust and scalable configuration. Provisioning a PostgreSQL HA (High Availability) instance in NDB is the most effective action to achieve this goal. An HA instance leverages replication (e.g., streaming replication) to distribute load and ensure availability, accommodating high concurrency by allowing multiple nodes to handle traffic. This approach simplifies configuration compared to manual scripting or parameter adjustments.

Option A (Use Post Create Command when provisioning the DB) is incorrect because post-create commands are for custom scripts, not optimal for handling concurrent connections.

Option B (Create a new Database Parameters profile) is incorrect because while it can tune settings, it’s less efficient than HA for scaling concurrency.

Option C (Edit the API equivalent shell script) is incorrect as it’s a manual and error-prone method compared to HA provisioning.

Option D is correct because a PostgreSQL HA instance natively supports high concurrency and availability.

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) v6.5 Blueprint, Section 4: Manage Database Engines

An NDB compute profile defines the CPU and memory resources for the database server VMs that are provisioned using NDB. It does not include any information about the network, domain, or software of the database server VMs. Those are specified in separate profiles, such as network profile, domain profile, and software profile.

References: Nutanix Support & Insights, section “NDB Compute”

The exhibit shows an error during the provisioning of NDB from the Prism Central Marketplace, with a failure reason stating "IP not found" in the "EraService - Substrate Create" step. This indicates that the provisioning process could not assign or detect an IP address for the NDB instance, likely due to an unconfigured or missing IP address during deployment. To prevent this issue, the administrator should configure an IP address when deploying the application. This involves specifying a static IP or ensuring IP Address Management (IPAM) is properly set up to allocate an IP during the Prism Central Marketplace deployment wizard.

Other options are less directly relevant:

B. Import the proper image in the Prism Central: This ensures the correct NDB image is available but does not address the IP assignment issue.

C. Provide a subnet with IP Address Management: While useful, this is a broader configuration step and not the specific action needed during deployment.

D. Register NDB using the correct IP address: Registration occurs after deployment and does not prevent the initial IP assignment failure.

Thus, the verified answer is A, as configuring the IP address during deployment directly addresses the "IP not found" error.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 2: Deploying and Configuring an NDB Solution, Lesson 2.2: Deploying NDB from Prism Central.

Nutanix Certified Professional - Database Automation (NCP-DB) v6.5 Knowledge Objectives, Section 2: Deploy and Configure an NDB Solution, Objective 2.2: Deploy NDB (applicable to v6.10).

Nutanix NDB Installation Guide: "Deploying NDB via Prism Central Marketplace" section, emphasizing IP configuration.

An NDB Software Profile is a template of the OS and database engine that you can use to provision or clone database server VMs using NDB. To create a software profile, you need to upload an installer package for the database software that you want to use, such as SQL Server or Oracle. The installer package must be compatible with the OS image that you have registered with Prism Element. You do not need a database server VM registered with NDB, a patch file for the installed databases, or an OS image registered with Prism Element to create a software profile. Those are required for other tasks, such as creating a software profile version, registering a database server VM, or provisioning a database server VM.

References: Nutanix Benefit 8: Integrated Self-service Database Management, Nutanix Support & Insights, section “NDB Software”

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) v6.5 Blueprint, Section 4: Manage Database Software Profiles

In Nutanix Database Service (NDB), a Network Profile is used to define networking configurations for database VMs, including VLAN assignments and IP address ranges. The correct procedure to create a Network Profile that assigns a VLAN and provides IP addresses to a database VM is as follows:

Create Network Profile: Start by initiating the creation of a new Network Profile within NDB. This is done from the NDB interface under the "Network" or "Profiles" section.

Select the VLAN: During the Network Profile creation process, you specify the VLAN that the database VM will use. This involves selecting an existing VLAN configured in the Nutanix cluster (e.g., via Prism Element) or defining a new VLAN ID if applicable.

Define IP Range: Finally, you define the IP address range (e.g., a subnet or specific IPs) that will be assigned to the database VM(s) within the selected VLAN. This ensures the VM receives a valid IP address for communication.

The sequence in option B aligns with the NDB workflow, where the Network Profile is created first, followed by associating it with a VLAN and then defining the IP allocation. Other options are incorrect:

A: "Add the VLAN" is vague and does not specify where the VLAN is added, disrupting the logical flow.

C: Adding a VLAN before creating the profile is not the standard NDB process, as VLANs are associated during profile creation.

D: Defining an IP range before creating the profile is out of sequence, as the profile must exist to hold the configuration.

Thus, the verified answer is B. Create Network Profile, Select the VLAN, Define IP Range.

Official Nutanix Database Automation References

Nutanix Database Management & Automation (NDMA) course, Module 3: Managing Database Instances, Lesson 3.2: Configuring Network Profiles.

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

Nutanix NDB Administration Guide: "Network Profiles" section, detailing VLAN and IP configuration steps.

 In Nutanix Era, a Volume Group is the recommended storage provisioning method for a large I/O-intensive database that doesn’t support a multi-disk layout1. A Volume Group in Nutanix Era is a collection of disks that can be managed as a single entity, providing a way to aggregate the storage capacity of multiple disks into a larger storage unit1. This allows for better performance optimization as it enables the database to leverage the combined I/O capabilities of all the disks in the group1. It’s important to note that while other options like Load Balancing, Storage Spaces, and vDisk based provisioning can also be used in certain scenarios, a Volume Group is specifically designed for situations where a single, high-performance storage unit is required1.

 The database parameters profile is used to define the initialization variables for different types of database engines and workloads, such as OLTP and DW. The database parameters profile allows the database administrator to customize the configuration settings for each database engine, such as Oracle, SQL Server, PostgreSQL, and MySQL. The database parameters profile can also be applied to different database operations, such as provisioning, cloning, and patching. The database parameters profile helps to optimize the performance and functionality of the databases according to the specific requirements and best practices of each database engine and workload.

The software profile version is used to define the software version and edition for each database engine, such as Oracle 19c Enterprise Edition or SQL Server 2019 Standard Edition. The software profile version is required for provisioning new databases and patching existing databases. The software profile version helps to ensure the compatibility and compliance of the databases with the supported software versions and editions.

The network profile is used to define the network configuration and security settings for the database server VMs and the databases, such as the IP address, subnet mask, gateway, DNS, firewall rules, and SSL certificates. The network profile is required for registering new database server VMs and provisioning new databases. The network profile helps to ensure the connectivity and protection of the database server VMs and the databases within the network environment.

The compute profile is used to define the compute resources and storage policies for the database server VMs and the databases, such as the CPU, memory, disk size, disk type, compression, deduplication, and replication factor. The compute profile is required for provisioning new databases and cloning existing databases. The compute profile helps to ensure the availability and efficiency of the database server VMs and the databases within the Nutanix cluster.

References:

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

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

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.

The Global Service Level Agreement (SLA) feature of Era allows an administrator to create Time Machine policies in a Multi-Cluster configuration1. This feature provides a unified way to manage and enforce backup and replication policies across multiple clusters, ensuring consistent data protection and recovery across the entire environment1.

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.

References: 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

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.

 Before patching a Linux OS on a database server VM provisioned using NDB, you must configure the repository for the OS updates. This can be done by creating a Repository Profile in NDB and specifying the URL, username, and password for the repository. The Repository Profile can be applied to one or more database server VMs during the provisioning process or later. By configuring the repository, you ensure that NDB can access and download the latest OS patches from a trusted source. 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.

 In the Nutanix Database Automation (NCP-DB) process, when a database administrator is tasked with creating a new clone of a running SQL database and there are no authorized servers available, the administrator should click the Action icon to authorize one or more database server VMs1. This is because the Nutanix Database Service (NDB) requires authorized servers to perform operations such as cloning1. The authorization process allows the NDB to manage and perform operations on the database server VMs1.

 Nutanix Era enables you to clone your source databases (running on Nutanix clusters) and refresh the database clones by using snapshots or transaction logs1. Era uses storage-efficient and time-efficient Nutanix snapshots, thus lowering the cost of managing multiple copies of your databases1. In this case, the administrator should create a clone from the July 31st snapshot in Time Machine to provide the legal team with the specific banking transaction event data they need for their audit1.

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) v6.5 Knowledge Objectives, Section 4: Troubleshoot NDB Solutions, Objective 4.3: Configure HA Across Clusters (applicable to v6.10).

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

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) v6.5 Knowledge Objectives, Section 3: Manage NDB Solutions, Objective 3.4: Migrate Databases (applicable to v6.10).

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

The correct answer is A and D because these are the two Time Machine options that are available when creating a database clone in NDB. Point in time allows the user to specify a date and time to create a clone from a specific point in the database history. Snapshot allows the user to select a previously taken snapshot to create a clone from a consistent state of the database. Option B is incorrect because Restore point is not a Time Machine option, but a feature that allows the user to restore a source database to a previous point in time. Option C is incorrect because Backup is not a Time Machine option, but a feature that allows the user to backup a database to a remote location.

References: The following sources provide more information about the Time Machine options and cloning features in NDB:

Nutanix Database Management & Automation (NDMA) course, Module 4: Protecting Databases Using Time Machine, Lesson 4.2: Cloning Databases

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

Nutanix Database Service (NDB) User Guide, Chapter 6: Protecting Databases Using Time Machine, Section 6.2: Cloning Databases

[Nutanix Support & Insights], NDB Time Machine Under the Hood