NCP-DB Practice Questions

For deploying Nutanix Database Service (NDB), the required file type to download from the Nutanix

Portal is an OVA (Open Virtual Appliance) file. The OVA format is a standardized package that includes

a pre-configured virtual machine image, including the NDB software, which can be imported into

supported hypervisors (e.g., VMware ESXi or Nutanix AHV). This simplifies the deployment process

by providing a ready-to-use VM template with all necessary components.

Option A (ZIP) is incorrect as ZIP files are generic archives, not deployment-specific formats for NDB.

Option B (QCOW2) is incorrect because QCOW2 is a disk image format primarily used with

KVM/QEMU, not the standard for NDB deployment.

Option C (OVA) is correct as it is the official file type provided by Nutanix for NDB deployment.

Option D (TAR) is incorrect as TAR files are used for archiving, not as a deployment package for NDB.

Administrators should download the OVA from the Nutanix Portal and follow the deployment guide.

Reference:

Nutanix Database Service (NDB) User Guide, Chapter 1: Deploying NDB, Section: Downloading and

Deploying the OVA

Nutanix Support & Insights, Knowledge Base Article: "NDB Deployment Prerequisites"

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

NDB

When an administrator changes the NDB language settings from English to Spanish, but the language

reverts to English when accessing NDB from a different workstation, it indicates that the language

settings are tied to the web browser on the original workstation rather than being globally applied.

NDB’s language settings are typically stored locally in the browser’s cache or pReference:s (e.g., via

cookies or browser locale settings), meaning they do not persist across different devices or browsers

unless explicitly synchronized (e.g., via user profile settings, which NDB does not universally enforce).

Other options are incorrect:

B . The language settings match workstation regional settings: This would depend on the OS locale,

not the observed behavior of reverting to English.

C . The language settings revert to English after logoff: NDB does not reset language settings upon

logoff; the issue is device-specific.

D . The language settings are bound to NDB users: If this were true, the language would persist across

workstations for the same user, which is not the case here.

Thus, the verified answer is A, reflecting browser-local language management.

Official Nutanix Database Automation Reference:

Nutanix Database Management & Automation (NDMA) course, Module 1: Introduction to NDB,

Lesson 1.3: User Interface Customization.

Nutanix Certified Professional - Database Automation (NCP-DB) v6.5 Knowledge Objectives, Section

1: Understand NDB Basics, Objective 1.2: Navigate the NDB UI (applicable to v6.10).

Nutanix NDB User Guide: "Customizing Language Settings" section, noting browser dependency.

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.

Reference:

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) v6.5 Blueprint, Section 6: Administer

an NDB Environment

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.

Reference:

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

Multi-Cluster Configuration

Nutanix Certified Professional - Database Automation (NCP-DB) v6.5 Blueprint, Section 3: Configure

an NDB Environment

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.

Reference:

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

Updating Database Server VMs

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

Database Servers

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.

Reference:

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) v6.5 Blueprint, Section 3: Configure

an NDB Environment

The correct answer is A because NDB handles the database restore operation by copying the specific

database files from the snapshot volume to the source volume, without affecting the other

databases that share the same source volume. NDB uses a copy-on-write mechanism to create

snapshots and clones, which means that only the changes made to the database files are stored in

the snapshot or clone volume, while the original files are kept in the source volume. Therefore, when

restoring a source database from a snapshot, NDB only needs to copy the specific database files that

have been modified since the snapshot was taken, and overwrite them on the source volume. The

other options are not correct because they either cause data loss or unnecessary data transfer.

Option B is not correct because replacing the source volume with specific db disks would erase the

other databases that share the same source volume, which is not desirable. Option C is not correct

because replacing the source volume with the snapshot volume would also erase the other

databases that share the same source volume, as well as any changes made to the source database

after the snapshot was taken, which is not desirable. Option D is not correct because copying all

database files to the source volume would be inefficient and unnecessary, as only the modified files

need to be copied, and the other files are already present on the source volume. Reference:: 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]

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.

Reference:

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

Database Software Profiles

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.

Reference:

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) v6.5 Blueprint, Section 5: Protect

Databases Using Time Machine

The Era copy data management service includes several components, one of which is the Time

Machine. The Time Machine is responsible for collecting logs and snapshots from the

database123. This functionality allows for granular clone and refresh operations, making it a crucial

part of the Nutanix Era’s database as a service (DBaaS) solution1.