NCP-MCA Practice Questions

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.”

In Prism Central playbooks the Autopilot switch governs whether an action is executed automatically or only shown as a “Recommended Action.” If Autopilot is disabled the trigger is still evaluated and an alert is generated, but the remediation task is never run until a user approves it. Therefore, when a playbook that is supposed to auto-remediate high-severity alerts performs no action, the most common and intended cause is that Autopilot is turned off.

A. Trigger mismatch would keep the playbook from firing at all, yet the scenario states it is configured for high-severity alerts; lack of action despite firing points to Autopilot, not the trigger.

B. Mis-defined remediation steps would cause failures or errors, not total absence of execution; the question stresses “no actions are being triggered.”

D. Alert severity being medium contradicts the given “high severity” requirement; this is a red-herring and not pertinent to execution flow.

1. Nutanix Prism Central Administration Guide v6.7, “Working with Playbooks – Enabling Autopilot,” pp. 531-533: “When Autopilot is disabled, playbooks generate Recommended Actions only; actions are executed automatically only after Autopilot is enabled.”

2. Nutanix Playbooks Best Practices White Paper, Rev. 2022-04, §2.3 “Autopilot versus Recommendation Mode,” p. 9.

3. Nutanix University Courseware OPS-402 “Operations Automation with Prism Central,” Module 3 slide “Autopilot Mode – Automatic Remediation.”

To be certain that both the Self-Service project scoping and the post-deployment Playbook work, the administrator should:

• first manually fire the Playbook with “Execute on Behalf Of”, selecting a VM that carries the CalmProject category. This runs every task exactly as the Playbook would when it is later triggered automatically, validating its logic and variable resolution.

• then deploy the blueprint from inside the same Project. The resulting VM(s) inherit the CalmProject category, so the Playbook should trigger automatically; observing this confirms that the Project/blueprint binding and Playbook trigger are correctly configured before opening access to users.

A. “Execute” lacks entity context; tasks that depend on VM-level variables or categories will not be validated.

C. Deploying the Marketplace-level blueprint bypasses the Project context; VMs will not receive the Project category, so the Playbook trigger cannot be confirmed.

1. Nutanix Prism Central Guide v2023.1, “Testing Playbooks – Execute vs. Execute on Behalf Of”, p.228-229, paras 3-5.

2. Nutanix Calm & Self-Service Admin Guide v6.5, “Project Categories and Playbook Triggers”, p.114-116.

3. Nutanix Calm Self-Service Admin Guide v6.5, “Validating a Project: Deploying a Blueprint from the Assigned Project”, p.120.

4. Nutanix University NCP-MCA v6.5 Courseware, Module 6 “Playbooks”, slides 27-30.

In Prism Central X-Play a playbook can have only one trigger, but an Alert (or Event) trigger can include several alert definitions so a single playbook fires when any of those alerts occur. The UI provides “+ Add Another Alert” to add the additional alerts. This capability is unique to Alert/Event triggers; it is not related to the number of actions, which can be multiple for any trigger type. Therefore statement A is the only universally correct statement.

B – Branch is an action, not a trigger; a playbook cannot be “triggered” by Branch.

C – Webhook triggers do not limit or grant “multiple scriptable tasks”; scriptable tasks can always be added, irrespective of trigger type.

D – You can chain multiple actions after any trigger (Alert, Event, Webhook), so this is not a property specific to Event triggers and is therefore misleading/incorrect.

1. Nutanix Prism Central Guide 5.20, “Creating a Playbook”, Step 5: “For Alert triggers you can add more than one alert by clicking + Add Another Alert.” (doc ID: pcguide520, p. 115).

2. Nutanix Prism Pro/X-Play Tech Note, “Playbook Triggers and Actions”, §2.1: “Only one trigger per playbook; Alert and Event triggers may contain multiple alert/event definitions.” (TN-Nutanix-XPlay-2021, p. 3).

3. Nutanix University Courseware, NCP-MCA 6.10 “Automating with X-Play”, Module 3 Slide 18: “+Add Another Alert allows combining several alerts into one playbook trigger.”

In Nutanix Calm, every blueprint is created and modified in the Blueprint Editor.

The editor presents the blueprint as a drag-and-drop canvas that graphically depicts all application tiers, services, dependencies, and actions. This visual topology allows designers to understand resource relationships at a glance and is the only interface in Calm that renders the blueprint in graphic form. Other blueprint-related tools (Showback, Configuration, Macros) provide text or tabular data only, not a visual diagram.

A. Blueprint Showback – Displays cost analytics; no visual topology is rendered.

B. Blueprint Configuration – Lists variables and settings in form fields; lacks graphical canvas.

D. Blueprint Macros – Supply shorthand syntax inside scripts; they are code snippets, not a visualization tool.

1. Nutanix Calm 3.6 User Guide, “Working with the Blueprint Editor,” Section 4.2, pp. 33-35.

2. Nutanix Calm Administration Guide, Rev. 2023-06, “Blueprint Showback and Cost Governance,” p. 78.

3. Nutanix Calm 3.x Developer Guide, “Macros in Calm Scripts,” Section 6.1, p. 112.

If VMs build but automation does not run, first confirm whether the playbook actually fired and, if so, which task failed. Playbook Execution History (menu: Operations → Playbooks → History) records every trigger, status, and error log, allowing root-cause inspection. If no execution is recorded, the next step is to confirm the blueprint really invokes the playbook through the Post-Deploy (or other) action mapping. A mis-configured or missing action binding will prevent the playbook from launching even though the VM portion of the blueprint completes successfully.

A. Project quota affects VM provisioning, not post-deploy playbook invocation; VMs are already building, so quota is not the issue.

B. Prism Element audit logs only show VM operations; they contain no playbook trigger or task data, thus provide little insight into automation failure.

1. Nutanix Prism Central Admin Guide 6.10, “Working with Playbooks → Viewing Execution History”, pp. 325-326 – describes checking trigger and task status for troubleshooting.

2. Nutanix Calm 6.10 Guide, “Blueprint Actions and Playbook Mapping → Post-Deploy Actions”, pp. 112-114 – explains configuring a blueprint to call a playbook after deployment and effects of misconfiguration.

3. Nutanix University Courseware, NCP-MCA 6.10 “Module 5: Automation”, slide 39 – recommends verifying playbook binding and reviewing execution history as first steps in troubleshooting SSP automation.

Within Prism Central Self-Service (Calm/Runbooks) an Endpoint object represents an external machine against which Calm can execute tasks. The product currently recognises only two operating-system types—Linux and Windows. An Endpoint type must therefore be defined generically as Windows (using WinRM/PowerShell) or Linux (using SSH). “Windows” is therefore a valid choice; the other names do not match any supported Endpoint type in Self-Service.

A. API Gateway – Not an Endpoint type; API Gateway is a playbook/action target only.

C. CentOS – CentOS would be covered by the generic “Linux” Endpoint, not recognised as a distinct type.

D. Kubernetes – Kubernetes clusters are added as Calm Providers, not as Endpoints.

1. Nutanix Prism Central Guide 2022.9, “Manage Runbooks → Working with Endpoints,” p. 243: “Prism Central supports two endpoint OS types: Linux and Windows.”

2. Nutanix Calm Administration Guide 3.8, Section 4.4 “Creating an Endpoint,” ¶2: “Choose the endpoint type: Linux or Windows.”

3. Nutanix Prism Central Guide 2022.9, “Playbooks → Actions,” p. 310 (notes API Gateway as action target, not endpoint).

A snapshot-recovery operation generates a Prism Central event (for example, “VM Snapshot Restore Succeeded”).

An Event-triggered Playbook can watch for this event and automatically apply an action such as Assign Category → “snapshot-recovered” to the affected VM.

Because Categories are first-class searchable objects in Prism Central, the administrator can later filter or report on all VMs with the “snapshot-recovered” category, thereby obtaining the required list. Alert- or time-based Playbooks do not capture this recovery event, so they cannot reliably build the list.

B. Alert triggers fire only on Prism alerts; snapshot-restore produces an event, not an alert, so no VMs would be captured.

C. Time-based triggers run on a schedule and do not react to individual snapshot-restore events; they neither detect nor list the recovered VMs.

D. “Alerts Matching Criteria” still depends on alert objects (severity, type); with no alert generated for snapshot recovery, the Playbook never runs.

1. Nutanix Prism Central Administration Guide v6.7, “Playbooks → Event Triggers,” pp. 541-543: describes event-based Playbooks and example using “Assign Category” after VM events.

2. Nutanix Prism Central Administration Guide v6.7, “Event Reference,” p. 916: lists “VM Snapshot Restore Succeeded” as a system event.

3. Nutanix University NCP-MCA 6.x Courseware, Module 7 “Intelligent Operations,” Slide 15: recommends assigning a category via event-triggered Playbook to tag VMs for later reporting.

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-based Self-Service, an administrator first builds reusable automation components—called “library tasks”—and then drags them into blueprints or runbooks. These atomic tasks (Bash, PowerShell, Ansible, etc.) are created and stored in the Calm Library, making them centrally maintained and easily reused across multiple automations.

A. VAML – Calm blueprints are written in YAML/JSON, not “VAML,” and YAML is a format, not the location where tasks are created.

B. Projects – Provide multi-tenancy, RBAC and quotas; they do not store or create automation building blocks.

C. Tasks – A task is the building block itself, not the place where you create and manage them; that place is the Library.

1. Nutanix Calm 3.7 User Guide, “Using the Calm Library → Creating a Library Task,” pp. 55-57.

2. Nutanix Prism Central Self-Service Admin Guide v6.5, “Calm Library Components,” Section 4.1.

3. Nutanix University Courseware: NCP-MCA v6.5, Module “Automation & Orchestration,” slide 38 (“Library tasks are reusable building blocks added to blueprints/runbooks”).