Nutanix NCP-MCA Nutanix Certified Professional - Multicloud Automation (NCP-MCA 6.10) Exam Exam Practice Test

Nutanix Self-Service defines several user roles, each with specific permissions.

Documentation describes theConsumerrole as:

Allowed todeploy applications from the Marketplace or assigned blueprints

Allowed to performday-2 operations(power actions, snapshots, etc.)

Restricted from modifying blueprints, environments, or project configurations

Ideal for end users who need access to deploy and manage their workloadswithout administrator capabilities

This matches exactly what the DevOps team requires.

Why the other roles are incorrect

Developer (A):Can modify blueprints and environments — too much privilege.

Project Admin (C):Full control over project resources — far more access than needed.

Operator (D):Used for automation and operational oversight, not end-user VM deployment.

Thus,Consumer (B)is the correct and intended role.

Playbooks are a feature of Intelligent Operations (formerly Prism Pro or X-Play), not Nutanix Self-Service (formerly Calm). Therefore, the first step is always to access the Intelligent Operations console in Prism Central.

The logical flow for defining an automation routine in a Playbook isTrigger first, then Action.

Select Trigger:The administrator must first definewhenthe playbook runs (e.g., on an Alert, an Event, or Manually).

Add Actions:Once the trigger is established, the administrator defineswhathappens (e.g., Power off VM, Send Email, Slack Notification).

The correct order found in the Nutanix Intelligent Operations Guide is: Access Intelligent Operations > Create Playbook > Select Trigger > Add Actions > Save.

Nutanix Calm documentation states thatApplication Profiles (App Profiles)define:

Default variable values

Deployment targets (cluster, subnet, environment)

Runtime configuration differences across environments

App Profiles act aslogical deployment configurationswithin a blueprint, allowing the same blueprint to be deployed differently across staging, test, or production environments.

Thus, the correct answer isC. App Profiles.

When creating a Runbook that involves power cycling a VM (Restart), there is a gap in connectivity while the Guest OS reboots and network services initialize.

If the Runbook moves immediately from the "VM Restart" task to the "Add new credential" task (which likely uses SSH or PowerShell to connect to the VM), the connection will fail because the VM is not yet accessible.

To correct this, the administrator must insert a Delay task between the restart and the configuration step.

The sequence should be:

VM Restart:Initiates the reboot.

Delay:Pauses the runbook execution for a set duration (e.g., 60-120 seconds) to allow the OS to boot.

Add new credential:Executes the script once the VM is back online.

The most efficient and scalable method for managing user access in Nutanix Self-Service Projects is leveraging existing Identity Providers (such as Active Directory).

Add an Active Directory group to a role:When adding users to a Project, the administrator can select an entireDirectory Group(AD Group) and assign a specific Project Role (e.g., Developer, Consumer, Operator) to that group.

Result:All users currently in that AD group, and any users added to that AD group in the future, automatically inherit the assigned Project Role. This eliminates the need to manually manage individual user accounts (Option D) or maintain separate local groups (Option A) within Prism Central.

Comprehensive and Detailed Explanation

Self-Service platform sync allows Prism Central to periodically collect updates from external providers.

Nutanix documentation states that the providers supportingplatform sync with a 20-minute update windoware:

Nutanix (AHV)

VMware (vSphere)

AWS

These environments support the metadata collection necessary for tracking:

IP changes

Disk resizing

VM availability

Thus, the valid set isNutanix, VMware, and AWS, makingOption Ccorrect.

Comprehensive and Detailed Explanation

Nutanix Calm documentation states:

TheBlueprint Editoris the graphical interface used to design, visualize, and modify a blueprint’s components, such as services, packages, substrates, dependencies, and tasks.

The editor provides avisual topologyof the multi-tier application.

Thus, the correct answer isC. Blueprint Editor.

To automate the provisioning of a VM and the subsequent application installation within a Nutanix Self-Service (Calm) Blueprint, the administrator must configure a Service.

The definition of a Service in a blueprint involves three distinct components to achieve this requirement:

VM Resource:Configuring the underlying infrastructure specifications (vCPUs, Memory, Disks).

Guest Customization:Configuring Cloud-init (Linux) or Sysprep (Windows) to handle the initial OS bootstrap (hostname, user creation).

Tasks (Package Install):Adding a script task (e.g., Shell or PowerShell) under the "Service Installation" action or a dedicated Package install step. This task executesafterthe VM is provisioned and running to install the web server application.

Nutanix Self-Service governance supportsApproval Policiesthat enforce control over resource consumption and automation actions. Nutanix documentation states that approval policies:

Apply toblueprint deployments,runbook executions,day-2 actions, orresource scale-up requests.

Requireexplicit authorizationfrom a designated approver before the action proceeds.

Provide governance to ensure resource usage aligns with organizational policies.

Thus, Approval Policies existspecifically to require authorization before a user-triggered task is executed, makingOption C correct.

Options A, B, and D are unrelated to approval workflows.

The placement of applications in Nutanix Self-Service is dictated by the intersection of theProjectconfiguration and theBlueprintdefinition.

Project Construct:The Project defines which infrastructure accounts (Providers) are available for use (e.g., AHV, AWS, Azure). If the Project is configured to allow access tobothAWS and another provider (like on-prem AHV or Azure), the potential exists for deployment to those targets.

Blueprints:The Blueprint (or the specific Environment selected at launch) dictates where the workload actually goes. If the administrator intended "Only AWS," but the Project allows multiple providers and the Blueprints (or the users launching them) are configured to use a non-AWS environment, the application will be deployed there.

Therefore, the cause is that theProject construct(allowing multiple clouds) and theBlueprints(utilizing those available clouds) are configured to allow this distribution. To restrict it, the administrator should remove the unintended providers from the Project's "Infrastructure" or "Environment" settings.

To configure access to a new cloud target (such as Oracle Cloud, AWS, Azure, or GCP) within Nutanix Self-Service (formerly Calm), the administrator must define the connection in theProviderssection.

Providers (Settings):This is the foundational configuration area where connection details, API endpoints, and authentication credentials for external infrastructure are defined. Before any Project, Environment, or Blueprint can utilize a new cloud, the "Account" or "Provider" definition must be created here.

Workflow:The administrator navigates to theProviders(or "Cloud Providers") tab, selects the provider type (using a plugin or generic provider if Oracle Cloud is not natively listed in the version), and inputs the necessary region and credential information.

Differentiation:

Environments (B)are subsets of a provider assigned to a specific Project.

Marketplace (A)is for publishing applications, not configuring infrastructure connections.

Comprehensive and Detailed Explanation

Blueprint tasks in Calm run at specificlifecycle stages:

Pre-create→ Tasks executedbeforeVM creation

Post-create→ Tasks executedafterVM creation butbefore power-on

Pre-delete→ Tasks executed before VM deletion

Post-delete→ Tasks executed after removal

Nutanix documentation states:

Actions that must occurbetween VM provisioning and first power-onshould be added to thePre-createorPost-createstage depending on their dependency.

AD OU assignment requires the VM to exist in inventory butbefore power-on, which aligns with:

✔Pre-create– This is used to configure environment-specific metadata, directory placement, and provisioning adjustmentsprior to initial VM startup.

Correct answer:B

Comprehensive and Detailed Explanation

Nutanix Playbooks can start based on anAlert Trigger, which is defined as:

A specificPrism Central alertthat, when generated, automatically starts the Playbook.

Alert Triggers map directly to an alert definition that Calm will monitor.

Thus, the Alert Trigger doesnotgenerate alerts or notify admins by itself—itwaits for a selected alertand launches the Playbook when that alert fires.

Correct answer:D

In Nutanix Self-Service (Calm), to share a Runbook across multiple projects, it must be published to the Marketplace.

When an administrator selects an existing Runbook and chooses the "Publish" option:

Secret Handling:The system strictly enforces thatsecrets (passwords/keys) are not published. The administrator is required to verify that no secret values are hardcoded. Any sensitive variables are stripped or must be set to runtime input during the publication process.

Project Selection:During the publication or approval workflow via theMarketplace Manager, the administrator configures theProject Sharingsettings. This determines which projects have access to view and execute the Runbook from the Marketplace.

It is not necessary to clone the Runbook first; the publication process itself creates the Marketplace entry derived from the source Runbook.

When configuring aNutanix(AHV) provider account within Self-Service (formerly Calm) to deploy infrastructure, the fundamental artifact required for VM provisioning is anAHV Image.

AHV Image:Nutanix AHV uses theImage Serviceto manage disk images (typically in QCOW2 or ISO format) that serve as the base for virtual machines. Before a Blueprint can be designed or deployed on a Nutanix account, a validDisk Imagemust be uploaded to the Prism Central Image Service. This image is then referenced in the Blueprint's VM configuration (Substrate) as the "Disk Image" source.

Contrast with other Providers:

VMware Template (Option B):This is the required artifact for theVMware vSphereprovider.

VHD (Option A):Typically associated with Hyper-V or Azure.

OVA (Option C):An export format, not a direct provisioning source for the Nutanix provider within Self-Service.

Therefore, ensuring anAHV Imageexists and is available on the cluster is the specific pre-configuration requirement for the Nutanix provider.

The visibility of clusters within a Self-Service Project is strictly controlled by theInfrastructure(or Accounts) configuration within the Project settings.

Infrastructure Whitelisting:When configuring a Project, the administrator must select which Accounts and Clusters are available for use. This is often referred to as defining theProject Scopeor whitelisting infrastructure.

The Cause:If users can see and create Environments targeting "Production Clusters," it is because the administrator explicitly selected (whitelisted) those Production Clusters in the Project's Infrastructure tab.

Environments vs. Infrastructure:Environments are definitions createdusingthe allowed infrastructure. Option D is less accurate because you whitelist theInfrastructure(resources), and then Environments are created on top of them. The root cause of the resource availability is the infrastructure whitelist in the Project Scope.

Nutanix Playbooks allowevent-driven automation.

Documentation states that Playbooks can:

Trigger onVM Powered Offevents

Filter targets usingcategories(e.g., OSType: Linux, Environment: Dev)

Perform actions such asVM Reduce CPU,VM Resize, etc.

To automatically and immediately update CPU count when the VM powers off, the proper method is:

✔Use aPlaybook

✔Trigger:VM Powered Off

✔Target VMs using categories

✔Action:VM Reduce CPU

Self-Service Runbooks (Option D) are manually executed; they do not automatically trigger on events.

Therefore,Option Cis correct.

In the Nutanix Cloud Platform,Categoriesare the fundamental metadata structure used to group and tag resources (such as VMs, Hosts, and Blueprints) for management purposes.

Functionality:Categories are key-value pairs (e.g., CostCenter:Marketing or Environment:Production) that provide a logical abstraction layer above the physical infrastructure.

Usage:

Cost Allocation:Nutanix Cost Governance (formerly Beam) uses categories to map resource consumption to specific business units or budgets.

Reporting:Prism Central uses categories to filter and group entities in reports.

Compliance/Security:Flow Network Security policies rely on categories to define traffic rules (e.g., "Allow traffic from App:Web to App:DB").

Protection:Disaster Recovery policies assign replication schedules based on categories.

Differentiation:"Labels" is a term often used in Kubernetes or public cloud (AWS/Azure tags), but "Categories" is the specific terminology and feature implementation within Nutanix Prism Central.

To fully validate the integration between a Self-Service Project and a Playbook, the administrator must perform a test deploymentwithin the specific Project context.

Project Context:Playbooks often rely on triggers (like Categories) or parameters that are applied specifically by the Project's environment settings. Running the Playbook independently (Option A) only tests the script logic, not the trigger or the project-specific inputs.

End-to-End Validation:By deploying the blueprint associated with the Project (Option D), the administrator confirms:

The Project correctly provisions the resources (Quotas/Environment).

The Resources receive the correct Categories/Tags from the Project.

The Playbook Trigger successfully fires upon detecting these specific Project-derived events.

The Playbook executes successfully.

This is the only method that validates "both the Project and Playbook configurations" as a unified workflow.

Nutanix Prism Central includesPredefined Playbooks(System Playbooks) that cover common use cases (e.g., "Email on Alert"). These system playbooks are protected templates.

Immutability:You cannot directly edit or modify a Predefined Playbook (making Option D incorrect).

Cloning Workflow:To customize a Predefined Playbook—such as adding an additional action step like "Slack Notification" or "VM Snapshot" at the end—the administrator mustClonethe playbook.

Process:Select the Predefined Playbook -> Click "Clone" -> Save as a new User Playbook. The administrator can then fully edit triggers and actions in this new copy.

While this effectively creates a "new" playbook (Option B), the specific mechanism provided in the interface and documentation to leverage the existing definition isCloning.

In Self-Service, anOperatorrole can:

Create blueprints

Modify blueprints

Add tasks (shell, PowerShell, script, package installs, etc.)

Use project-provided resources (images, networks, credentials)

To deploy a Linux VM with NGINX:

Asingle-VM blueprintis sufficient.

Developer must selectLinux substrate.

Installation of NGINX occurs througha shell taskin the blueprint’s package or service.

No additional permissions are required for an Operator to perform these actions.

Therefore, the correct answer isC.

Nutanix Data Protection (Leap) and Flow Security policies rely on Categories to dynamically assign policies to entities.6

In this scenario, the administrator likely set up the Protection Policy to target the Protection: Silver category (standard practice for tiered Service Level Agreements, e.g., Gold, Silver, Bronze). While Environment: Prod is used for the Security Policy (isolation), the Protection Policy specifically requires the protection category to function as intended in a tiered architecture.

If the blueprint (Marketplace item) only assigned Environment: Prod, the VM is missing the critical tag (Protection: Silver) required to associate it with the 1-hour snapshot schedule. To fix this, the blueprint must be updated to assignbothcategories (Environment: Prod AND Protection: Silver) to the VM during provisioning.

To ensure that Prism Central sends the appropriate notifications (Alerts/Events) to ServiceNow—allowing ServiceNow's Event Management to process them viaEvent Rules—the administrator must configure an X-Play Playbook that exports these alerts.

According to the Prism Central Intelligent Operations Guide (ServiceNow Integration):

Export of alertsfrom Prism Central is achieved by creating an X-Play playbook.

The administrator should use theAlerts Matching Criteriatrigger. This trigger allows the administrator to define the scope of the export (e.g., "All Critical Alerts" or specific categories).

The Playbook then uses theSend Alert to ServiceNowaction to push these matching alerts to the ServiceNow Event API.

By configuring a Playbook with theAlerts Matching Criteriatrigger, the administrator ensures a continuous, policy-based flow of event data into ServiceNow, satisfying the requirement for Event Rules to have data to process. Option A describes the action but lacks the governing trigger mechanism (matching criteria) that defines "appropriate" events for the integration.

To successfully create, validate, and publish blueprints to the Self-Service Marketplace (formerly Calm Marketplace), aProjectmust be configured with the following two essential components:

Infrastructure (A):

The Infrastructure configuration (often found under the "Infrastructure" or "Accounts" tab in the Project settings) is the foundational requirement. It allows the administrator to select which Cloud Provider accounts (such as Nutanix AHV, VMware vSphere, AWS, Azure, or GCP) are available for use within that specific project. Without configuring Infrastructure, the project has no access to resource providers, and therefore no blueprints can be created or validated for publication.

Environments (B):

The Environment configuration is critical for the "Blueprint to Marketplace" workflow. An Environment defines the specific compute, network, and storage profiles for the infrastructure selected in the project (e.g., mapping a specific AHV Cluster and Network to the project).

During Creation:A blueprint relies on the Project Environment to define its platform-specific settings (like Images and Networks) while being designed and tested.

During Publication & Launch:When a blueprint is published to the Marketplace, it is often published "without platform-dependent configuration" to make it portable. This portability relies entirely on the destination Project having a configuredEnvironment. When a user launches a Marketplace item, the Self-Service engine "patches" the abstract blueprint requirements with the concrete details (Network, Cluster, Credentials) defined in the Project'sEnvironment.

Policies (C)(such as Quotas and Approvals) andTunnels (D)(used for network connectivity in hybrid/VPC scenarios) are optional configurations and are not strictly required to publish a blueprint to the marketplace.

The image typically displays the Project configuration tabs: "Users, Groups, & Roles," "Infrastructure," "Environments," "Policies," and "Quotas," visually confirming the hierarchy where Infrastructure and Environments are the primary configuration steps for resource definition.

Playbooks in Intelligent Operations (X-Play) areEvent-Driven. They execute strictly when a specific event (trigger) occurswhilethe playbook is active.

The Scenario:The administrator sees the category Expired is present on the VM, and the Playbook is currently enabled.

The Cause (Option B):If the category was applied to the VMwhile the Playbook was disabled(or before it was created), the system generated the "Category Assigned" event, but the Playbook was not listening for it at that time.

Consequence:When the administrator later enables the Playbook, it does not retroactively scan for existing VMs with that category; it only waits fornewassignment events. Since the event was missed, no execution record exists.

To fix this, the administrator would need to re-apply the category (remove and add) while the Playbook is enabled to generate a new event.

In Nutanix Self-Service (Calm),Endpointsare external execution targets used by Playbooks and Runbooks to run scripts or automation tasks. Nutanix documentation specifies the followingvalid Endpoint types:

Windows Endpoint

Linux Endpoint

Database Endpoints(e.g., PostgreSQL, MySQL)

HTTP/Webhook Endpoints

Calm identifiesWindowsandLinuxmachines as valid, manageable Endpoints, meaning administrators can run scripts, commands, and automation tasks on them.

Why the correct answer is B (Windows)

Windows is explicitly listed as a supported Endpoint type.It supports script execution (PowerShell), credential storage, and remote orchestration through Calm.

Why the other options are incorrect

❌A. API Gateway

An API Gateway isnot an Endpoint typein Self-Service; it is not used for script execution or orchestration.

❌C. CentOS

Although CentOS is a Linux distribution, Calm doesnotregister distribution-specific Endpoints like "CentOS."

Instead, it uses thegeneric Linux Endpoint type, not OS-specific entries.

Therefore, "CentOS" isnota selectable Endpoint type.

❌D. Kubernetes

A Kubernetes cluster can be integrated with Nutanix, but it isnot classified as a Playbook/Runbook Endpointin Self-Service.

Kubernetes resources are handled through Calm Blueprints—not through Endpoint registration for automation tasks.

To automate actions based on a signal from a third-party monitoring tool, the administrator should use the Webhook Trigger in Nutanix Intelligent Operations (X-Play).

Webhook Trigger:The administrator creates a playbook that starts with a Webhook Trigger. This generates a unique URL.

Integration:The third-party tool is configured to send an HTTP POST request (the notification) to this unique URL when the "low capacity" threshold is reached.

Automation:Receiving this signal automatically triggers the playbook to execute the expansion tasks (e.g., calling APIs to provision more VDI nodes or expand storage), removing the manual step.

While "Alert" (Option D) is used for native Nutanix alerts, the "Webhook" is the designated mechanism for receiving external events.

Nutanix Playbooks (part of Prism Central Automation) support multiple trigger types—Alert, Event, Webhook—and each trigger defines how automation workflows begin. The Nutanix Automation documentation highlights the following key rules:

1. Event Triggers (Correct Answer)

Playbooks using anEventtrigger supportmultiple playbook tasks, including script tasks, VM power operations, Prism actions, and more.

Nutanix documents specify that:

Event-based Playbooks activate when specificPC or cluster eventsoccur.

After an event trigger fires, administrators may definemultiple sequential actionsinside the Playbook.

This allows complex automation chains such as remediation actions, notification flows, or branching logic.

Therefore,Option D is correct, because Event-triggered Playbooks allow multiple actions to be added.

Why the other options are incorrect

❌Option A — Alert Trigger

Alert triggers only allowone alert definition per Playbook trigger.

Nutanix documentation states that an Alert trigger is mapped toa single alert policy, not multiple alerts.

Thus, Option A is incorrect.

❌Option B — Branch Step

ABranchisnot a trigger; it is aflow control elementusedafterthe Playbook has already started.

Branch steps define conditional paths but do not permit the addition of multiple "actions" as a trigger.

Therefore, Option B is incorrect.

❌Option C — Webhook Trigger

Webhook-triggered Playbooks start when external systems send an HTTP POST request.

While the Playbook may contain multiple tasks after triggering, the question specifically refers to addingmultiple scriptable tasks as part of the trigger, which is not possible.

Webhook triggers acceptonly one incoming webhook definition, not multiple script tasks embedded in the trigger.

Thus, Option C is incorrect.

In Nutanix Self-Service (Calm), when defining a variable for a Runbook (or Blueprint), there is a specific configuration attribute called "Runtime".

Runtime Editable:If this checkbox is selected during the variable creation, the user executing the Runbook will be prompted to provide or modify the value at the time of execution.

Not Runtime Editable:If this checkbox is left cleared (unchecked), the variable uses the default value defined by the administrator, and the user executing the Runbookcannot changethis value.

Therefore, if the administrator cannot change the value during execution, it is because the variable was not marked as runtime editable in the Runbook definition.

In the Nutanix Self-Service (Calm) Blueprint lifecycle, tasks are executed in a specific order relative to the provisioning of the infrastructure (Substrate).

Pre-Create Task:This is the specific phase designed to run scripts or set variablesbeforethe VM provision call is sent to the provider (AHV).

Workflow:

The developer creates a pre-create task (e.g., a Python script) to generate the custom hostname string based on logic (e.g., date, user input, or sequence).

The script outputs this string to a variable (e.g., @@{vm_hostname}@@).

The VM Service configuration (Substrate) references this variable in the "VM Name" or "Hostname" field.

Execution:When the blueprint launches, the pre-create task runs first, populates the variable, and then the VM creation occurs using that calculated name.

Tasks in post-create or package-install (Options B and C) runafterthe VM has already been provisioned and named, making them too late for this requirement.