Practice Free NCP-DB-6.5 Exam Online Questions
Question #21
While registering an Always on Availability Group database, an administrator selects the following option:
Multiple Databases as a Group with One Time Machine
Which statement is true regarding this chosen option?
- A . PITR-based SLAs are supported for database groups containing mixed Recovery Model.
- B . PITR-based SLAs are not supported for database groups containing mixed Recovery Model
- C . Point in Time Clones are not supported by Database Groups.
- D . PITR-based SLAs are not supported for database groups.
Correct Answer: B
B
Explanation:
Nutanix Database Automation (NCP-DB) introduces the concept of MS SQL Server database groups, which allows multiple databases running in the same database instance to be grouped as one Time Machine entity1. This applies to both single DB Server VM setups, standalone databases, as well as to Availability Group databases1. However, it does not support Point In Time Recovery (PITR)-based Service Level Agreements (SLAs) for database groups containing mixed Recovery Models. This means that if the databases within the group have different recovery models, PITR-based SLAs cannot be applied to the group as a whole.
B
Explanation:
Nutanix Database Automation (NCP-DB) introduces the concept of MS SQL Server database groups, which allows multiple databases running in the same database instance to be grouped as one Time Machine entity1. This applies to both single DB Server VM setups, standalone databases, as well as to Availability Group databases1. However, it does not support Point In Time Recovery (PITR)-based Service Level Agreements (SLAs) for database groups containing mixed Recovery Models. This means that if the databases within the group have different recovery models, PITR-based SLAs cannot be applied to the group as a whole.
Question #22
How does NDB send notifications when alerts are generated?
- A . SNMP
- B . APIs
- C . Pulse
- D . Email
Correct Answer: D
D
Explanation:
NDB sends notifications when alerts are generated via email. The email notifications can be configured to send to one or more recipients, and can be customized to include the alert severity, category, description, and resolution steps. The email notifications help to inform the database administrator and other stakeholders about the status and issues of the NDB-managed databases and operations.
NDB does not send notifications via SNMP, APIs, or Pulse. SNMP is a protocol for collecting and organizing information about managed devices on a network. APIs are interfaces for communicating and exchanging data between different applications or systems. Pulse is a feature of the Nutanix cluster that collects and sends diagnostic and usage data to Nutanix for analysis and support.
Reference: Nutanix Database Management & Automation Training Course, Module 3: Nutanix Era Deployment,
Lesson 3.2: Nutanix Era Deployment, slide 11.
Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.1: Nutanix Era Operations, slide 6.
Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.2: Nutanix Era Alerts and Notifications, slides 5-7.
D
Explanation:
NDB sends notifications when alerts are generated via email. The email notifications can be configured to send to one or more recipients, and can be customized to include the alert severity, category, description, and resolution steps. The email notifications help to inform the database administrator and other stakeholders about the status and issues of the NDB-managed databases and operations.
NDB does not send notifications via SNMP, APIs, or Pulse. SNMP is a protocol for collecting and organizing information about managed devices on a network. APIs are interfaces for communicating and exchanging data between different applications or systems. Pulse is a feature of the Nutanix cluster that collects and sends diagnostic and usage data to Nutanix for analysis and support.
Reference: Nutanix Database Management & Automation Training Course, Module 3: Nutanix Era Deployment,
Lesson 3.2: Nutanix Era Deployment, slide 11.
Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.1: Nutanix Era Operations, slide 6.
Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.2: Nutanix Era Alerts and Notifications, slides 5-7.
Question #22
How does NDB send notifications when alerts are generated?
- A . SNMP
- B . APIs
- C . Pulse
- D . Email
Correct Answer: D
D
Explanation:
NDB sends notifications when alerts are generated via email. The email notifications can be configured to send to one or more recipients, and can be customized to include the alert severity, category, description, and resolution steps. The email notifications help to inform the database administrator and other stakeholders about the status and issues of the NDB-managed databases and operations.
NDB does not send notifications via SNMP, APIs, or Pulse. SNMP is a protocol for collecting and organizing information about managed devices on a network. APIs are interfaces for communicating and exchanging data between different applications or systems. Pulse is a feature of the Nutanix cluster that collects and sends diagnostic and usage data to Nutanix for analysis and support.
Reference: Nutanix Database Management & Automation Training Course, Module 3: Nutanix Era Deployment,
Lesson 3.2: Nutanix Era Deployment, slide 11.
Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.1: Nutanix Era Operations, slide 6.
Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.2: Nutanix Era Alerts and Notifications, slides 5-7.
D
Explanation:
NDB sends notifications when alerts are generated via email. The email notifications can be configured to send to one or more recipients, and can be customized to include the alert severity, category, description, and resolution steps. The email notifications help to inform the database administrator and other stakeholders about the status and issues of the NDB-managed databases and operations.
NDB does not send notifications via SNMP, APIs, or Pulse. SNMP is a protocol for collecting and organizing information about managed devices on a network. APIs are interfaces for communicating and exchanging data between different applications or systems. Pulse is a feature of the Nutanix cluster that collects and sends diagnostic and usage data to Nutanix for analysis and support.
Reference: Nutanix Database Management & Automation Training Course, Module 3: Nutanix Era Deployment,
Lesson 3.2: Nutanix Era Deployment, slide 11.
Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.1: Nutanix Era Operations, slide 6.
Nutanix Database Management & Automation Training Course, Module 5: Nutanix Era Operations, Lesson 5.2: Nutanix Era Alerts and Notifications, slides 5-7.
Question #24
An administrator was asked to change the snapshot schedule for a given database. The administrator discovered that the time machine is in a paused state.
How should the administrator change the schedule?
- A . Select the Time Machine; under Action select Update end define an appropriate schedule.
- B . Clone the Time Machine and define an appropriate schedule for the clone.
- C . Select Time Machine: Under actions Resume the Time Machine and then Update to define an appropriate schedule.
- D . Clone the database and define an appropriate schedule for the clone.
Correct Answer: A
A
Explanation:
According to the Nutanix Database Automation (NCP-DB) learning documents, an administrator can change the snapshot schedule for a given database by selecting the Time Machine, then under Action, select Update and define an appropriate schedule1. This is because the Time Machine in Nutanix Era allows you to specify the number of backups or snapshots the time machine should take, the time of day it takes those snapshots, and the day of the week it takes weekly or monthly backups1. These options help you build a complete schedule of time machine capture operations1. Even if the Time Machine is in a paused state, the administrator can still update the schedule1. Cloning the Time Machine or the database is not necessary for changing the snapshot schedule1.
A
Explanation:
According to the Nutanix Database Automation (NCP-DB) learning documents, an administrator can change the snapshot schedule for a given database by selecting the Time Machine, then under Action, select Update and define an appropriate schedule1. This is because the Time Machine in Nutanix Era allows you to specify the number of backups or snapshots the time machine should take, the time of day it takes those snapshots, and the day of the week it takes weekly or monthly backups1. These options help you build a complete schedule of time machine capture operations1. Even if the Time Machine is in a paused state, the administrator can still update the schedule1. Cloning the Time Machine or the database is not necessary for changing the snapshot schedule1.
Question #25
An administrator needs to perform patching on a MongoDB server cluster within an NDB environment.
How should the administrator accomplish this task?
- A . Perform a rolling upgrade, applying the patch to the primary member first, followed by the secondary members.
- B . Apply the patch to all nodes at once.
- C . Perform a rolling upgrade, applying the patch to the secondary members first, followed by the primary member.
- D . Disable the replica set while patching.
Correct Answer: C
C
Explanation:
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.
Reference:
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.
C
Explanation:
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.
Reference:
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.
Question #26
How would an administrator enter the NDB command line to change the static IP address on the NDB VM?
- A . era-server
- B . era
- C . cerebro_cli
- D . arithmos cli
Correct Answer: C
C
Explanation:
To change the static IP address on the NDB VM, an administrator would need to enter the NDB command line using the cerebro_cli command. The cerebro_cli command is used to access the Cerebro service, which is responsible for managing the NDB instance and its components.
The cerebro_cli command can be run from the NDB VM or from any other VM that has network connectivity to the NDB VM. The cerebro_cli command has various subcommands and options to perform different tasks, such as changing the IP address, hostname, password, or certificate of the NDB VM. To change the static IP address, the administrator would need to use the cerebro_cli network update subcommand with the appropriate parameters, such as the new IP address, netmask, gateway, and DNS servers. The cerebro_cli network update subcommand also requires the administrator to provide the current password of the NDB VM for authentication. After changing the IP address, the administrator would need to restart the NDB VM for the changes to take effect.
Reference: Nutanix Certified Professional – Database Automation (NCP-DB) v6.5, Section 2 – Deploy and Configure an NDB Solution, Objective 2.2: Configure an NDB Instance
Nutanix Database Management & Automation (NDMA) Course, Module 3: Nutanix Database Service (NDB) Installation and Configuration, Lesson 3.2: Configuring NDB, Topic: Changing the IP Address of the NDB VM
Nutanix Database Service (NDB) Command Line Interface Guide, Chapter 2: Cerebro CLI, Section: cerebro_cli network update
C
Explanation:
To change the static IP address on the NDB VM, an administrator would need to enter the NDB command line using the cerebro_cli command. The cerebro_cli command is used to access the Cerebro service, which is responsible for managing the NDB instance and its components.
The cerebro_cli command can be run from the NDB VM or from any other VM that has network connectivity to the NDB VM. The cerebro_cli command has various subcommands and options to perform different tasks, such as changing the IP address, hostname, password, or certificate of the NDB VM. To change the static IP address, the administrator would need to use the cerebro_cli network update subcommand with the appropriate parameters, such as the new IP address, netmask, gateway, and DNS servers. The cerebro_cli network update subcommand also requires the administrator to provide the current password of the NDB VM for authentication. After changing the IP address, the administrator would need to restart the NDB VM for the changes to take effect.
Reference: Nutanix Certified Professional – Database Automation (NCP-DB) v6.5, Section 2 – Deploy and Configure an NDB Solution, Objective 2.2: Configure an NDB Instance
Nutanix Database Management & Automation (NDMA) Course, Module 3: Nutanix Database Service (NDB) Installation and Configuration, Lesson 3.2: Configuring NDB, Topic: Changing the IP Address of the NDB VM
Nutanix Database Service (NDB) Command Line Interface Guide, Chapter 2: Cerebro CLI, Section: cerebro_cli network update
Question #27
Which default roles are available within Era for Role-Based Access Control?
- A . prism Admin
• Era Super Admin
• Era Database Admin Era Infrastructure Admin - B . Super Admin Database Admin
Database Infrastructure Admin
• Infrastructure Admin - C . Era Oracle Admin
Era SQLServer Admin
• Era PostgreSQL Admin Era Mariadb Admin - D . Super Admin Database Admin
Database Infrastructure Admin prism Infrastructure Admin
Correct Answer: A
A
Explanation:
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.
A
Explanation:
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.
Question #28
An administrator needs to apply a minor version upgrade of the PostgreSQL software to an Era provisioned instance.
Which step should the administrator take before applying the patch?
- A . Create a new software profile.
- B . Put the database instance into maintenance mode.
- C . Go to the Software Profile Version widget and click update.
- D . Migrate a new software profile.
Correct Answer: A
A
Explanation:
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.
A
Explanation:
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.
Question #29
Which statement describes a user in Era with the Database Infrastructure Admin role?
- A . The user is able to manage software profiles, Network Profiles. database Instance parameter profiles and time machine SLA
- B . The user is able to manage software profiles, Network Profiles. database parameter profiles end Time Machine SLAs,
- C . The user is able to manage database profiles, Network Profiles, database Instance parameter profiles and time machine SLA
- D . The user is able to manage software profiles, database parameter profiles and SLAs
Correct Answer: B
B
Explanation:
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.
B
Explanation:
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.
Question #30
An administrator needs to patch an Oracle Database Server VM and must ensure Grid home is allocated sufficient storage space.
At a minimum, how much space must be available for Grid home prior to completing this task?
- A . 5GB
- B . 10GB
- C . 15GB
- D . 20 GB
Correct Answer: B
B
Explanation:
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.
Reference: Nutanix Database Automation documentation, particularly in the sections discussing Oracle database server VM management and patching requirements.
B
Explanation:
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.
Reference: Nutanix Database Automation documentation, particularly in the sections discussing Oracle database server VM management and patching requirements.