Free NCP-MCA Practice Test Questions and Answers (2026)

In Nutanix Calm/Prism Central Self-Service, “macros” are run-time substitution tokens that the Calm engine replaces with the resolved value of a variable, credential, runtime input, or system field. The documented syntax encloses the variable name between two leading and two trailing “at” signs: @@{varname}@@. Any other bracketing or the omission of the double “at” signs prevents the engine from recognising the token; the value will not be substituted.

A. @{varname}@ – Uses only single “@” at each side; Calm parser requires double.

B. {varname} – Missing the required “@” delimiters entirely.

C. [[varname]] – Square-bracket notation is not recognised in Calm/Self-Service macros.

1. Nutanix, “Calm 3.6 Administration Guide – Using Macros in Tasks,” Section 6.3, p. 181: “The macro must be written as @@{variablename}@@ for the engine to render the run-time value.”

2. Nutanix, “Prism Central Self-Service Admin Guide v6.10,” Ch. 5 ‘Run-Time Variables and Macros,’ p. 102: “Syntax: @@{NAME}@@; example: echo @@{tier1ip}@@.”

3. Nutanix University, “NCP-MCA v6.10 Courseware – Module 4: Calm Blueprints,” slide 42: “Macro format: @@{varname}@@ (double ‘@’ prefix and suffix).”

The only Prism Central automation that can selectively suppress Info and Warning NGT alerts yet leave Critical alerts visible is an Alert-Matching-Criteria playbook.

When you create a playbook with trigger type “Alert – Matching Criteria”, you can filter on

• Alert name = “Nutanix Guest Tools …”, and

• Severity = Info OR Warning.

The action “Acknowledge Alert” is then executed automatically, auto-clearing those two severities, while Critical alerts—which do not meet the match filter—continue to surface to the administrator.

B. Manual playbook requires a human click; it does not execute automatically, so Info/Warning alerts would still appear until someone runs the playbook.

C. “Alert-based for specific NGT Alerts” targets individual alert UUIDs; it cannot apply a severity filter, forcing separate playbooks per alert and risking suppression of Critical alerts.

D. NGT issues generate Alerts, not Events; an event-triggered playbook would never fire for the desired conditions.

1. Nutanix Prism Central Guide 2023.1, Automation with Playbooks → “Create an Alert-Matching Criteria-Based Playbook”, Steps 3-5 (filter by Alert Name and Severity; select action Acknowledge Alert).

2. Nutanix Prism Central Guide 2023.1, Table “Playbook Trigger Types” – distinguishes Alert triggers from Event triggers.

3. Nutanix Guest Tools Alert Definitions, Nutanix Support Portal KB #30402, section “Severity levels generated by NGT”.

Nutanix Calm provides the macro @@{calmunique}@@, which expands to a system-generated character string that is guaranteed to be unique every time the blueprint is launched. By concatenating the static prefix “WNSRV” with @@{calmunique}@@ the developer assures that every VM name produced by repeated QA pipeline executions is distinct, eliminating any possibility of a naming collision during deployment.

A. @@{calmrandom}@@ only returns a random string; duplicates, although unlikely, are not prevented.

B. Static value “WNSRV0001” would collide on every subsequent run.

D. Two @@{calmrandom}@@ strings reduce—but do not eliminate—the chance of collision; uniqueness is still not guaranteed.

1. Nutanix Calm Administration Guide 6.5, “Using Macros”, Table 30-2 – calmunique: “…returns a unique 6-character string…recommended for naming to avoid collisions.” (pp. 211-212).

2. Nutanix Calm Blueprint Design Guide 3.4, Section 4.2 “Name Macros”: “calmrandom is random only; calmunique guarantees uniqueness across launches.” (p. 27).

3. Nutanix University NCP-MCA v6.10 Courseware, Module 5 “Self-Service Blueprints”, slide 18: “Use calmunique for VM names when repeated automation runs must never collide.”

Playbooks store a full run-history that records every trigger evaluation and the resulting action status. Nutanix documentation recommends examining this History tab first when a playbook does not appear to run—it confirms whether the trigger fired, if conditions were met, and why an action may have been skipped or failed. Therefore, validating the configuration is best started by reviewing the playbook’s execution history rather than changing project context, quotas, or rebooting Prism Central.

A. Execution context need not be moved to Prism Element; power-off VM actions execute perfectly from Prism Central, so changing context will not validate trigger issues.

B. Prism Central changes are applied immediately; rebooting is unnecessary and gives no diagnostic insight into why a playbook failed to run.

C. Resource quotas affect VM provisioning, not whether an automation playbook trigger fires; increasing CPU/memory limits will not influence playbook execution.

1. Nutanix Prism Central Administration Guide 6.10, “Automation – Viewing Playbook Execution History,” pp. 127-129: explains using the History tab to verify trigger evaluations.

2. Nutanix University, NCP-MCA v6.10 Courseware Module “Playbooks & X-Play,” Section “Troubleshooting Playbooks,” slide 14: instructs to check Execution History first when playbooks do not run.

3. Nutanix Official Documentation Portal, KB-7525 “Playbooks – Troubleshooting Basics,” Step 1: “Inspect the History tab to confirm the trigger fired and review error details.”

In Calm blueprints a variable marked as Secret is stored in CredHub encrypted and is automatically masked (shown as ) whenever its value is printed in task output or audit logs, including Set-Variable tasks. By converting the variable to a Secret type the sensitive data is no longer exposed, while the blueprint can still reference the variable at run-time.

A. “=secret=” syntax is not recognised by Calm; the platform relies on the Secret variable flag, not a value prefix.

B. Calm is expressly designed to manage sensitive data through Secret variables and credentials; eliminating blueprints is unnecessary.

D. @@{jsonEncode(value)}@@ only produces a JSON-escaped string; it does not encrypt or mask log output.

1. Nutanix Calm 6.5 Administration Guide – “Variables > Secret Variables”, p.103-104: “If Secret is enabled the value is stored encrypted and will be masked in audit or run-time logs.”

2. Nutanix Calm 6.5 Administration Guide – “Viewing Audit Logs”, p.182: “Secret variable values appear as in Set-Variable task output.”

3. Nutanix Calm 3.6 API & CLI Reference – Section 4.2 “CredHub integration for secret variables”.

4. Nutanix University NCP-MCA v6 Courseware – Module 4, Slide 15: “Use Secret variables to prevent sensitive data from appearing in Calm logs.”

In Nutanix Calm, administrators design automation blueprints and then “Publish” them to the Calm Marketplace. Publishing makes the blueprint visible to, and launchable by, authorized self-service users in their projects. The feature name used in product literature for this publishing and catalog capability is “Marketplace and Application Management,” therefore option B directly addresses the ability to publish blueprints for consumption.

A. Unified Multi-Cloud Orchestration – governs provisioning to different clouds; it does not provide the catalog/ publishing mechanism.

C. Application Development and Modernization – focuses on integrating Calm with CI/CD and modern stacks, not on blueprint publication.

D. Self-Service DSL – Infrastructure-as-Code – refers to the Calm DSL used to define blueprints in code, but it does not expose or publish them to consumers.

1. Nutanix Calm Administration Guide v6.5, “Publishing a Blueprint to the Marketplace,” pp. 163-165.

2. Nutanix Prism Central Guide 2023.1, Section “Calm Marketplace,” para. 1-2 (explains blueprints appear to end-users only after being published).

3. Nutanix Calm 3.2 Tech Note, “Blueprint Marketplace & Self-Service,” p. 4 (describes Marketplace as the consumption layer for published blueprints).

In Self-Service, a Project is an administrative construct that groups together one or more users, assigns them roles, and confines their consumption of infrastructure through quotas and RBAC policies. The Project itself has no function for Prism Central alerting, VM migration, or binding blueprints/runbooks to clusters; those tasks belong to other Prism Central or Calm features. Hence only option A reflects an actual capability of Projects in Self-Service.

B. Projects neither receive nor display hardware alerts; alert monitoring is done from the Prism Central Operations console.

C. VM migration automation is supplied by Nutanix Move or Leap, not by Self-Service Projects.

D. Blueprints and runbooks are associated with Projects, not directly with clusters; Projects cannot “assign” them to clusters.

1. Nutanix Prism Central Guide v6.5, “Self-Service > Projects,” pp. 463-465: “A project groups users, provides role-based access, and sets quotas for compute, storage, and network resources.”

2. Nutanix Calm Admin Guide v3.6, “Projects,” p. 27: “Blueprints and runbooks belong to a project; clusters are added to the project’s infrastructure, not vice-versa.”

3. Nutanix Prism Central Operations and Alerts Guide v6.5, “Alerts Overview,” p. 12: alerts are managed outside the Self-Service Project construct.

To allow Self-Service Portal users to deploy blueprints to Oracle Cloud Infrastructure (OCI), the cloud account must first be registered as a “Provider.” In Prism Central 6.x, the administrator navigates to Administration → Self-Service → Providers and selects “Add Provider,” where OCI is listed together with AWS, Azure, and GCP. Only after a provider is added can it be attached to Projects or Environments for user access. Therefore, the configuration task is performed in the Providers section.

A. Marketplace – Used to browse/publish blueprints and runbooks; it does not register external clouds.

B. Environments – Allow blueprint scoping and variable definition but rely on already-configured providers.

C. Projects – Control RBAC, quotas, and cost governance; they consume, not create, provider definitions.

1. Nutanix Calm 6.5 Administration Guide, “Managing Providers,” pp. 24-26: “Select Self-Service > Providers, then click Add Provider to register AWS, Azure, GCP, or Oracle Cloud Infrastructure accounts.”

2. Nutanix Prism Central Guide 2023.1, Section “Self-Service Setup,” para. 3: “Before assigning a public cloud to a project, add it as a provider.”

3. Nutanix University Courseware: NCP-MCA 6.x “Module 7 – Self-Service,” slide 9: “Providers page is the single point to configure on-prem and public cloud endpoints (AWS, Azure, OCI, GCP).”

The only way to prove that the self-service Project mapping, the blueprint, and the post-deployment Playbook all interact correctly is to launch (test-deploy) the blueprint inside the Project and then view the Playbook execution status. This single action validates

1) that the Project’s credential, quota, and network mappings allow a deployment, and

2) that the Playbook is automatically triggered by the post-deploy task and completes successfully.

Running the Playbook by itself or reviewing cluster tasks does not confirm the end-to-end workflow that users will invoke.

A. Running the Playbook alone never tests blueprint triggers or Project resource mappings; it validates only the Playbook logic in isolation.

B. Prism Element task history records cluster operations, not Calm/X-Play execution; it cannot confirm Playbook trigger or success.

C. Moving the blueprint to another Project changes the environment and still requires a test deploy; comparison of usage offers no functional validation.

1. Nutanix Calm Administration Guide 3.6, “Creating and Testing Blueprints” pp. 138-140: “Use Test Deploy to launch the blueprint in its Project and verify post-deployment runbook execution before publishing.”

2. Nutanix Prism Central Admin Guide pc.2023.3, Chapter “Playbooks – Viewing Execution History”, p. 421: “After a blueprint deploy triggers a post-deployment Playbook, its status appears in Playbooks > History.”

3. Nutanix University Courseware “NCP-MCA v6.10: Automation and Orchestration”, Module 4, Slide 27: “Best practice—perform a test deployment of the blueprint to confirm Project mappings and Playbook execution prior to enabling self-service.”

In Calm/Prism Central the Self-Service Library does not permit creating stand-alone tasks.

A task first has to exist inside a Blueprint or Runbook.

When that Blueprint or Runbook is published, any task that has been marked “Save to Library” (or “Expose to Self-Service”) is automatically extracted and shown in Library ➔ Tasks for later reuse.

Therefore the only way a task can appear in the Library list is by publishing it from an existing Blueprint or Runbook.

A. The Library UI has no “Create Task” function; tasks are view-only once published.

B. Projects only control RBAC and quota; they are not used for uploading or registering tasks.

C. GitHub integration can import blueprints, not register individual tasks directly in the Library.

1. Nutanix Calm Administration & Operations Guide v3.6, “Self-Service Library → Task Library”, p.147-148: “Tasks become available in Library only after being published from a Blueprint or Runbook that contains them.”

2. Nutanix University – Multicloud Automation (MCA) Administration Courseware, Module 5 “Working with the Self-Service Library”, slide 18: “Publish Blueprint/Runbook → Tasks marked for Library appear under Library > Tasks.”

3. Nutanix Calm 3.7 User Guide, Section 7.4 “Publishing a Blueprint”, para 3: “Publishing extracts selectable tasks into the global Task Library for reuse.”

These sources collectively confirm that publishing from a Blueprint/Runbook is the sole method for a task to be listed in the Self-Service Library.

In Calm, the cloud locations an application can use are determined by the combination of (1) the Accounts that are added to the Project and (2) the substrates defined inside the blueprint.

If the Project contains more than one cloud Account and the blueprint contains substrates for several providers, Calm distributes the application components across every provider that is both in the Project and referenced in the blueprint. Therefore, the most common—and most direct—reason a deployment that was supposed to stay on AWS is landing on other clouds is that both the Project definition and the blueprint were built to include multiple providers.

A. Password change only breaks the Account connection; it does not alter placement logic.

B. Policies enforce quotas / approval but do not decide which provider is used.

C. Roles govern RBAC; they cannot override the provider list defined in the Project + blueprint.

1. Nutanix Calm Administration Guide v3.6, “Projects – Adding Accounts,” pp. 24-26: “…when a project contains several Accounts, any blueprint that includes matching substrates will deploy components to those providers.”

2. Nutanix Calm Blueprint Design Guide, Section “Multi-cloud Substrates,” para 2: “Calm determines runtime placement from the intersection of Project Accounts and blueprint substrates; if both reference multiple providers, components may span clouds.”

3. Nutanix Calm 3.6 Online Help, topic “Launching an Application,” Step 4: “…select a Project. All Accounts attached to that Project are candidates for deployment provided the blueprint has matching substrates.”

In Self-Service, dynamic (ephemeral) VM credentials are obtained at runtime only if the project’s environment is flagged to use an external credential provider (e.g., Vault).

While creating or editing an Environment inside the Project, the administrator must tick “Allow Credential Provider”. Calm then requests usernames/passwords at launch time and injects them into blueprints, enabling dynamic credentials across all Self-Service actions run from that project.

B – Applies to blueprint design (HTTP endpoints/Open Terminal) but does not switch the project to dynamic credentials.

C – No “add dynamic credential” field exists; the toggle is “Allow Credential Provider”.

D – Dynamic credentials for variables are set inside blueprints; it still requires the environment flag and does not configure Self-Service at project level.

1. Nutanix Prism Central Self-Service Admin Guide v6.1, “Enable Dynamic Credentials for a Project Environment”, p. 32-33 (checkbox ‘Allow Credential Provider’).

2. Nutanix Calm 3.6 Documentation, Section 4.3 “Using External Credential Providers”, para 2-4 (project-level environment configuration).

3. Nutanix University NCP-MCA Courseware Module 5, slide 17 “Project Environments – Allow Credential Provider”.

Flow security policies match the category labels that are attached to a VM.

The policy in the question explicitly allows SSH (port 22) only for VMs whose category key/value is AppType: Admin-VM.

If the blueprint does not stamp that category on the VM at deploy-time, the VM falls under the default “block all” portion of the policy and SSH is denied.

Therefore the blueprint must be modified to assign the AppType: Admin-VM category to every Administrator VM so that the allow-SSH rule is hit.

B. AppType: Web-Servers rule allows only HTTPS; SSH remains blocked.

C. Protection policies govern snapshots/RPO, not network access; no effect on SSH connectivity.

D. Adding users to the Project changes RBAC only; it does not influence Flow security rules applied to VM traffic.

1. Nutanix Flow Network Security Guide v6.5, “Applying Categories to VMs”, pp. 23-24 – explains that security rules act on VMs with matching categories.

2. Nutanix Flow Network Security Guide v6.5, “Creating Traffic Allow Rules Based on Categories”, p. 31 – shows that only VMs with the specified category receive the permit action.

3. Nutanix Calm Administration Guide v3.6, Chap. 4 “Assigning Categories in a Blueprint”, pp. 68-69 – describes adding key/value categories (e.g., AppType: Admin-VM) to blueprint components.

4. Nutanix AOS Data Protection Guide v6.5, “Protection Policies Using Categories”, p. 12 – clarifies protection policies affect snapshots, not network ports.

5. Nutanix Prism Central Admin Guide 2022.9, “Projects and Role-Based Access Control”, p. 45 – RBAC governs user permissions, not VM traffic handling.

In Nutanix Calm, every blueprint is composed of one or more Services. A Service represents a logical application component (usually a VM or container) and contains the runtime, configuration, dependencies and lifecycle actions for that component. Calm assembles these Services to form Single-VM or Multi-VM blueprints, but the atomic, reusable object—the “building block”—is the Service itself.

B. Single-VM Blueprint – A blueprint that happens to contain only one service; it is a type of blueprint, not the unit used to construct one.

C. Runbook – Automates sequential tasks independently of blueprints; it is not embedded inside a blueprint.

D. Multi-VM Blueprint – Describes a blueprint with multiple services; again, it is the finished artifact, not the elemental building block.

1. Nutanix Calm Administration & Operations Guide v3.7, “Services: The fundamental building blocks of a blueprint” (Section 4.2, p. 46).

2. Nutanix University Courseware – Calm Design & Deploy (Lesson 2, Slide 11): “Service objects are the core building blocks from which a blueprint is assembled.”

3. Nutanix Calm 3.7 API/CLI Guide, Section “Blueprint Model > Service Object” (p. 15).

To collect a cost-center value at deployment time you must expose it as a runtime variable in the Calm/Self-Service blueprint. Because categories can only be attached to the resulting VM programmatically, add a post-provisioning task that reads the runtime variable and calls the Prism Central REST API to set category CostCenter= on the VM. After these two elements are in place, publish the blueprint to the Marketplace so every requester is prompted for (and charged back by) their own cost-center value.

A. Pre-defined variables are fixed at design time; the requester is never prompted, so each VM would carry the same cost-center value.

C. Environment variables are bound to the whole environment, not supplied per request, so individual requesters cannot enter their own cost center.

D. A Project can force a fixed category but cannot accept a variable entered at request time; the user input requirement is unmet.

1. Nutanix Prism Central Self-Service Administration Guide v6.1, “Blueprint Variables – Runtime Variables”, p. 36-38.

2. Nutanix Calm User Guide v3.6, “Creating Tasks to Call Prism Central API”, p. 112-114.

3. Nutanix Cost Governance Guide v6.10, “Using Categories for Charge-Back (CostCenter)”, p. 7-8.

4. Nutanix Prism REST API Reference v6.10, Section /blueprints/{uuid}/categories, Example 2 “Assign Category via Task”.

Calm orchestration in Prism Central includes an HTTP task type that can invoke any external REST endpoint and capture parts of the JSON response directly into Calm service variables through JSON-Path mapping. Because the call and parsing logic are built into the task, no shell, PowerShell, or other script needs to be written. Therefore, to retrieve an IP address from an external IPAM solution’s REST API and pass it to the blueprint, the developer should select an HTTP task.

A. Execute task requires authoring a shell/PowerShell script to call the API, violating the “no scripting” requirement.

B. Set Variable cannot reach external systems; it only assigns static or pre-existing variable values.

C. Delay merely pauses execution and performs no external interaction; it cannot obtain an IP.

1. Nutanix Prism Central Self-Service Admin Guide 2023.3, “Task Types → HTTP Task,” para 1-3 (docs.nutanix.com/pc/20233/pcselfservice/tskselfservicetasktypes.html).

2. Nutanix Calm Administration Guide v3.8, Ch. 6 “Creating Tasks → HTTP Task,” p. 104-106.

3. Nutanix University NCP-MCA v6.10 Courseware, Module 4 “Automation Tasks,” slide 23 (“HTTP Task: call REST APIs without scripts; map response to variables”).

AWS is one of Calm’s built-in public-cloud providers. To use it, the administrator creates or edits an AWS provider entry under Prism Central → Settings → Providers and supplies the Access Key ID, Secret Access Key and region information. No blueprint (YAML/JSON) or task change is required; those files describe application topology, not provider connectivity. Therefore, the only valid action to “create a custom Provider for provisioning VMs in AWS” is to update (add) the provider and type the required credentials.

B. Blueprints (YAML/JSON) define application layouts; uploading JSON to a blueprint does not create or modify a provider.

C. Same as B; uploading YAML affects the blueprint only, not provider connectivity.

D. Tasks inside a blueprint run after a provider is already chosen; entering credentials there neither creates nor updates the AWS provider.

1. Nutanix Calm Administration & Operations Guide v6.5, “Adding an AWS Provider”, pp. 90-92.

2. Prism Central Guide 2023.1, Section “Providers – AWS”, para 3-4 (“Enter Access Key ID, Secret Access Key … click Save”).

3. Rajamani, N. et al., “Application‐Centric Automation with Nutanix Calm”, IEEE Cloud 2021 tutorial slides, slide 17 (“Providers supply credentials; blueprints consume providers”).

When Prism Central registers an AWS Self-Service (Calm) account it must reach the AWS public API endpoints (for example .amazonaws.com) over HTTPS. Those endpoints are referenced by hostname, so the Nutanix management network has to be able to resolve them. The official Nutanix Calm documentation therefore lists “working DNS resolution for AWS endpoints” as a mandatory prerequisite before the account can be created. Other services such as NTP or SNMP are not consulted during the registration workflow.

A. NTP – Recommended for time accuracy on all clusters but not checked or required during AWS account registration.

C. SNMP – Used only for monitoring/alerting; not part of Calm public-cloud onboarding.

D. FQDN – AWS endpoint FQDNs must resolve, but you supply no FQDN when creating the account; DNS service itself is the requirement.

1. Nutanix Calm 3.6 Documentation, “Registering an AWS account – Prerequisites”, para. 2: “Ensure DNS resolution to .amazonaws.com is available.” (doc ID: PC-Calm-3.6-AWS, p. 131).

2. Nutanix Prism Central Admin Guide 2023.1, Section “Add Public Cloud Accounts”, p. 103: “The Prism Central network must have outbound HTTPS and DNS access to AWS API endpoints.”

3. Nutanix University Courseware, NCP-MCA v6.10 “Module 4 – Public Cloud Integration”, slide 12 notes: “DNS reachability is the only mandatory network element for AWS account creation.”

In Calm Runbooks, a variable must be flagged as Runtime Editable when it is created. Only variables with this attribute appear in the launch dialog and can be modified each time the runbook is executed. If the administrator cannot change the value, the variable was created without the Runtime Editable flag; publishing the runbook does not, by itself, lock variables.

A. Runbooks do allow variable changes at launch if the variable is marked Runtime Editable.

C. Re-opening the runbook does not permit runtime editing; the variable attribute determines editability.

D. eScript content is separate from variable definition; variables are managed in the Variables pane, not inside the script body.

1. Nutanix Prism Central (Calm) Administration Guide v6.7, “Defining Variables” → Table 6-4, column “Runtime Editable”, p. 237.

2. Nutanix Calm User Guide v2023.1, “Launching a Runbook” → Step 3: “Modify any variables marked Runtime Editable”, p. 119.

3. Nutanix University Courseware “Calm Orchestration Fundamentals”, Module 4, slide 18: “Mark a variable Runtime Editable to allow value override at execution.”

When Self-Service is enabled on a Prism Central Project, members of that project gain the ability to consume the Self-Service Portal: they can launch blueprints (Calm applications) and subsequently start, stop, delete, and otherwise manage the virtual machines that those blueprints create—subject to the quotas defined for the project. All other infrastructure-wide tasks (network changes, image repository maintenance, role administration) remain reserved for PC or Prism Element administrators.

A. Cluster-wide network settings are edited only by PC/PE infrastructure admins, not by project users with self-service rights.

B. Global image repository creation/management is an infrastructure-scope privilege outside the project self-service boundary.

D. Role and access-control modifications occur in the PC Users & Roles menu and require admin credentials; self-service users cannot alter these settings.

1. Nutanix Prism Central Administration Guide 2023.1, “Enable Self-Service for a Project,” pp. 462-464: describes blueprint deployment and VM management rights granted to project members.

2. Nutanix Calm Administration Guide 3.7, §2.3 “Self-Service Portal Overview,” p. 27: states that enabling self-service lets project users “launch blueprints and manage the resulting applications/VMs.”

3. Nutanix University Courseware, NCP-MCA 6.10 “Calm and Self-Service,” Module 4, slides 12-13: delineates self-service capabilities vs. admin-only tasks.