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

In Nutanix Self-Service (Calm) Projects, the "Allow Collaboration" setting controls the visibility and management of entities shared among project members.

Allow Collaboration Enabled: This allows any group member to see the VMs, applications, scheduler jobs, and other objects created by other members of the group. With the appropriate role permissions, they can also modify these shared entities.

Allow Collaboration Disabled: Project users can manage only the objects that they strictly created themselves. They cannot view or edit objects created by other users, even if they are in the same project.

To modify a Scheduler Job created by another user, "Allow Collaboration" must be enabled for that Project.

In Intelligent Operations (X-Play) Playbooks , the syntax for string interpolation (using parameters) differs from Self-Service (Calm).

Playbook Syntax: X-Play uses the double curly brace syntax {{ ... }} to reference parameters.

Example: To reference the name of the entity that triggered the playbook, the correct parameter string is {{trigger[0].source_entity_info.name}} or {{trigger[0] .alert_entity_info.name}} depending on the trigger type.

Contrast: @@{...}@@ (Option B) is the syntax used in Self-Service (Calm) macros, not X-Play Playbooks.

To satisfy the requirement of acting on alerts based on specific properties (such as Severity levels: Info or Warning) rather than just the alert policy itself, the administrator must use the Alerts Matching Criteria trigger.

In Nutanix Intelligent Operations (X-Play), there are two primary alert triggers:

Alert Trigger: This triggers a playbook when a specific Alert Policy is generated (e.g., "Host Down"). It applies to all instances of that policy regardless of severity, unless the policy itself is severity-specific.

Alerts Matching Criteria: This trigger allows the administrator to define a playbook that fires on any alert matching specified criteria . Configurable criteria include Severity (Critical, Warning, Info), Impact Type , Target Entity , and Alert Policy .

By creating a playbook with the Alerts Matching Criteria trigger, the administrator can specifically select Severity: Info and Severity: Warning and filter for the NGT Alert Policy . The action "Acknowledge Alert" can then be added. This ensures that only non-critical NGT alerts are auto-acknowledged, while Critical NGT alerts (which do not match the criteria) continue to notify the administrator.

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

Documentation describes the Consumer role as:

Allowed to deploy applications from the Marketplace or assigned blueprints

Allowed to perform day-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 workloads without 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.

When a Playbook fails to fire despite an Alert occurring, the most common and "likely" cause is a mismatch in the Trigger configuration logic.

Trigger Precision: X-Play Triggers are precise. If the administrator selected the Alert trigger, they must select a single specific Alert Policy (e.g., "Host High Memory"). If the high-severity alert that occurred was "VM High Memory" (a different policy), the Playbook will not trigger, even if both are "High Severity."

Alerts Matching Criteria: To cover all high-severity alerts, the administrator must use the Alerts Matching Criteria trigger and filter by Severity == Critical. If they used the specific "Alert" trigger or configured the criteria incorrectly (e.g., wrong entity type), the system is "working as implemented" (ignoring non-matching events), but the logic does not match the user's intent.

Autopilot (Option C): While X-Play has an Autopilot feature for KPI optimization, it is not a mandatory requirement for standard alert-based remediation playbooks to function.

The image typically shows the distinction between the "Alert" trigger (Select one policy) and "Alerts Matching Criteria" trigger (Select filters like Severity/Entity), illustrating how a configuration error here leads to the issue described in Question 40.

The Policy Engine is the core component in Prism Central that enables governance and scheduling capabilities for Self-Service.

Requirement: According to the Administration Guide, the Policy Engine must be enabled to use Quotas , Approvals , and Scheduler features.

Function: The Scheduler relies on the Policy Engine to enforce timing and execution rules for Application Actions and Runbooks. Without this engine running, the Scheduler tab and functionality are unavailable.

To successfully create, validate, and publish blueprints to the Self-Service Marketplace (formerly Calm Marketplace), a Project must 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 configured Environment . 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's Environment .

Policies (C) (such as Quotas and Approvals) and Tunnels (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.

The "Environment" construct in Nutanix Self-Service is designed specifically to abstract infrastructure details from the end user while ensuring correct placement.

Within a single Project, an administrator can define multiple Environments (e.g., "Development" and "Production").

The Development Environment is configured to map to the Development Cluster and its associated networks.

The Production Environment is configured to map to the Production Cluster and its associated networks.

When a blueprint is launched, the user (or the application profile) simply selects the target Environment. The Self-Service engine then automatically directs the provisioning to the specific cluster defined in that Environment's settings, ensuring correct placement without requiring the user to know cluster details or manual intervention.

To satisfy specific ordering requirements around IP assignment (before VM existence) and Security Group assignment (after VM existence but before use), the administrator uses Pre-create and Post-create tasks.

Pre-Create Task (IP Address): This task executes before the VM provisioning call is made to the provider. The developer uses this phase (e.g., an HTTP task or Script) to request a specific IP from an external IPAM solution. The IP is stored in a variable and passed to the VM configuration.

VM Provisioning: The VM is created (using the IP from step 1) but is configured in the blueprint to stay in a Powered Off state initially.

Post-Create Task (Security Group): This task executes immediately after the VM resource is created (so the VM UUID/NIC exists) but before the application logic starts. The developer uses this phase to make an API call (e.g., to Flow or NSX) to place the VM into the required Security Group.

Power On: A subsequent task (or manual action) powers on the VM, ensuring it boots up with the correct IP and within the correct security boundary.

Option C is the only combination that covers both the "Before Creation" and "After Creation" phases required.