Free Practice Questions for Nutanix NCP-DB Exam

When performing a SQL Server Restore Source Database operation in Nutanix Database Automation (NCP-DB), an administrator might choose the Restore Location as New Location if they want to restore to a new location and have Era apply Nutanix best practices1. This is because Nutanix Era automates and simplifies database management, allowing the administrator to manage databases at scale, and it applies Nutanix best practices during the restore process1. This ensures optimal performance and reliability of the restored database1.

In a high availability (HA) Nutanix Database Service (NDB) environment, custom SSL certificates are used to secure communication between clients (e.g., NDB GUI, API calls) and the NDB control plane. The HA Proxy VMs serve as the entry point for all external traffic, load balancing requests across the NDB API server VMs and providing secure SSL termination. When configuring custom SSL certificates, they must be updated on all HA Proxy VMs to ensure consistent and secure communication across the HA environment. Updating only a subset of servers or other components (like API or Repository VMs) would lead to inconsistencies or SSL handshake failures.

Option A (All API server VMs) is incorrect because the API servers do not directly handle external SSL termination; this is managed by the HA Proxy layer.

Option B (All HA Proxy VMs) is correct as these VMs are responsible for SSL termination and load balancing in an HA setup, requiring the custom certificates to be applied uniformly.

Option C (The API and Repository VMs running on the primary cluster) is incorrect because Repository VMs do not handle client-facing traffic, and the API servers rely on HA Proxy for SSL handling.

Option D (The primary API, Repository, and HA Proxy servers) is incorrect because it implies a single "primary" server focus, whereas in an HA setup, all HA Proxy VMs (not just a primary one) must be updated.

This aligns with NDB’s HA architecture, where HA Proxy VMs are the critical components for SSL certificate management.

References

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

Nutanix Support & Insights, Knowledge Base Article: "Configuring Custom SSL Certificates in NDB HA Environments"

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

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

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

A Log Catchup gap in Nutanix Database Service (NDB) occurs when transaction logs are missing or corrupted, disrupting point-in-time restore (PITR) operations for cloning or database restoration via Time Machine. The NDB Time Machine Heal Snapshot feature addresses this by repairing snapshots to resolve such gaps.

Option A (By default the time machine auto-heal feature is enabled) is incorrect because the auto-heal feature is not enabled by default; it requires explicit configuration or manual invocation.

Option B (Manual Heal is only used when gaps in Log Catchup are detected once the operation has begun failing) is incorrect because manual heal can be initiated proactively or reactively, not solely after failure detection.

Option C is correct because a successful Time Machine Heal process restores the snapshot integrity, allowing PITR to span the previously gapped period.

Option D is correct as the auto-heal process, when enabled, runs every 5 minutes to detect and address healable conditions, aligning with NDB’s automated maintenance schedule.

Together, C and D reflect the operational mechanics of the Heal Snapshot feature.

References

Nutanix Database Service (NDB) User Guide, Chapter 5: Configuring Time Machines, Section: Healing Snapshot Gaps

Nutanix Support & Insights, Knowledge Base Article: "Resolving Log Catchup Gaps with Time Machine Heal"

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

NDB supports centralized drive-letter customization for SQL Server through the NDB server CLI global configuration. Nutanix documents this as the supported method for setting the database, log, backup, and TempDB drive letters used by NDB-managed provisioning and clone workflows. After the administrator changes the global values, NDB applies those assignments when it prepares eligible SQL Server database server VMs. The drive letters are not supplied interactively during each provisioning operation, stored in a Windows Domain Profile, or introduced merely by adding disks to a Software Profile. Therefore, option A is correct. The candidate file’s supplied answer B conflicts with the documented NDB configuration method and has been corrected. Nutanix SQL Server limitations

The size of a database Time Machine in Nutanix Era is defined by the size of all snapshots and/or transaction logs maintained by Era1. The Time Machine leverages Nutanix’s efficient snapshot technology to capture the state of the database at different points in time1. These snapshots, along with transaction logs that record changes between snapshots, constitute the data maintained by the Time Machine1. Therefore, the size of the Time Machine is determined by the total size of these snapshots and transaction logs1.

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

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

When an administrator is creating a Windows Domain profile in Era, the SQL Service Startup Account is an optional field that can be skipped and provided during the provisioning process. This account is used to start the SQL Server service when the server starts up. If this field is not provided during the creation of the Windows Domain profile, it can be provided later during the provisioning process1.

PostgreSQL max_connections is an engine-level initialization parameter that controls the maximum number of concurrent sessions accepted by the database server. NDB manages settings of this type through a Database Parameters Profile. The administrator can create or customize a PostgreSQL parameters profile, set the required connection limit, and select that profile during provisioning so the new instance starts with the approved production configuration. A Network Profile controls VLAN and address allocation, not database session limits. A Software Profile contains the operating-system and PostgreSQL software image used to create the server. A Windows Domain Profile contains Active Directory and Windows service-account information and is not applicable to this Linux-based PostgreSQL setting. Therefore, option D is correct. The parameter should also be sized according to available memory and workload requirements. Official Nutanix PostgreSQL profile documentation

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