Free Practice Questions for Nutanix NCP-MCA Exam

In Nutanix Self-Service (Calm), Macros are used to reference variables and properties dynamically using the syntax @@{Entity.Attribute}@@.

Servicesare a primary supported entity for macros. You can reference properties of other services within the same application blueprint. For example, a web server service might need the IP address of a database service. This can be achieved using a macro like @@{Database_Service.address}@@. This allows for dynamic orchestration where values are populated at runtime based on the actual deployment details of the Service entity.

To use (leverage) a Dynamic Credential (provided by an external IPAM or Secrets solution like CyberArk or Vault) within a project, the administrator must configure theProject Environment.

Workflow:

Navigate to theProjectsettings and select theEnvironmenttab.

In theCredentialssection of the Environment configuration, clickAdd Credential.

Select theCredential Provider(Dynamic) rather than a Static credential.

Result:This action effectively "adds" the dynamic credential configuration to that specific environment, making it available for blueprints launched within that context.

Option A ("Allow credential provider") usually refers to theInfrastructuretab where accounts are whitelisted, but the specific configuration of the credential itself happens via the "Add" action in the Environment.

When configuring a Playbook in Intelligent Operations (X-Play), the "User Execution" settings allow the administrator to define a specific user context (impersonation) under which the playbook actions run.

However, for alocal user accountcreated in Prism Central to be available and valid for this impersonation, that usermust have logged into the Prism Central interface at least once. This login event creates the necessary user profile and mapping within the Prism Central database that X-Play requires to authenticate and execute actions on their behalf. If the user has been created but never logged in, they cannot be successfully used for playbook execution.

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.

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.

Nutanix Calm and Self-Service automation workflows require validation within the same execution context used by end users. Nutanix documentation specifies the following principles:

1. Playbook validation requires execution in the same user and project context

Playbooks that target resources using aCalmProjectcategory must be tested in the exact context in which they will operate.

The"Execute on behalf of"option allows the administrator to run the Playbookas if a project user initiated it, ensuring validation of:

Project-based scoping

User permissions

Category-based triggers

Playbook logic and automation flow

This matches the documented requirement that Playbooks must be validated under theintended user execution model, makingOption B correct.

2. Deployment must occur inside the Project to activate category-driven Playbooks

Blueprint deployments only trigger Playbooks when:

The deployment occursinside the Project, and

The VM receives metadata (such as CalmProject category) associated with that Project.

Nutanix Calm documentation highlights that Playbooks relying onProject categoriesonly activate when VMs are provisionedfrom that specific Project.

Deploying from the Marketplace does not guarantee that the correct project context or categories will be applied.

Thus, verifying Playbook execution requires deploying the blueprint assigned to the Project, makingOption D correct.

Why the other options are incorrect

❌Option A – “Execute”

This executes Playbooks only in the admin context, not the Project context. It doesnotvalidate permissions, user behavior, or category-based triggers required for Self-Service operation.

❌Option C – Marketplace deployment

Marketplace deployments do not necessarily apply Project-specific categories or metadata, so they cannot reliably test integration with Playbooks bound to a Project.

Comprehensive and Detailed Explanation

Nutanix Calm naming macros:

@@{calm_random}@@→ Generates a random short string,not guaranteed uniqueacross deployments.

@@{calm_unique}@@→ Generates a unique, monotonically increasing integerguaranteed not to repeat.

Static values (e.g., WNSRV0001) will always collide.

Calm documentation specifies:

calm_uniqueshould be used when a deterministic, guaranteed unique VM name is required across multiple deployments.

Therefore, the correct VM naming pattern is:

✔WNSRV@@{calm_unique}@@

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.

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.