NCP-MCA common mistakes
NCP-MCA · Understand the traps and how to avoid them.
Treating a playbook as a single linear script and expecting every action to run in sequence, instead of mapping out parallel branches, decision points, and the join behavior where branches reconverge before answering design questions.
Candidates come from a scripting background where execution is sequential, so they mentally flatten the playbook graph and then misjudge which actions can run concurrently or which downstream action waits on multiple branches.
What to do instead
Before answering, redraw the playbook as a directed graph: mark the trigger, every decision/parallel split, and every join. For each question, state explicitly whether the action is upstream, downstream, or on a sibling branch, and confirm which branch's completion gates the next step.
Confusing playbook triggers with runbook triggers and with alert-based automation, then selecting a trigger type that fires on the wrong event (for example choosing a schedule when the scenario requires an alert or an event).
Prism Central exposes several automation entry points that all 'start automation', and the exam scenarios describe the desired outcome rather than naming the mechanism, so candidates pattern-match on keywords like 'alert' or 'schedule' without checking which construct owns that trigger.
What to do instead
Build a one-page comparison of trigger types across playbooks, runbooks, and alert policies: what event fires each, what payload/context it passes, and whether it supports manual or API invocation. For each scenario, first identify the initiating event, then pick the construct that natively consumes that event.
Assuming every action in a playbook or runbook runs with full Prism Central admin rights, and ignoring how the executing user's role and the project scope constrain what the automation can actually do.
Lab environments are usually built with an admin account, so permission failures never surface during practice; on the exam, scenarios involving project-scoped users or restricted roles are answered as if the automation were omnipotent.
What to do instead
For any scenario involving a non-admin or project-scoped actor, trace the effective permissions of the account the automation runs as, and check whether the target objects (VMs, apps, categories, endpoints) are inside that account's project and role scope. If the action needs broader rights, the correct answer usually involves a credential or role change, not a different action.
Treating Calm blueprints as simple VM templates and missing the lifecycle model: multi-tier service dependencies, per-service actions, package install ordering, and the difference between app-level and service-level operations.
Candidates who mainly deploy single VMs conflate a blueprint with an image/template, so they answer lifecycle questions (start, stop, delete, scale, patch) at the wrong granularity and misorder dependent services.
What to do instead
Study one multi-tier blueprint end to end and annotate it: dependencies between services, deploy/start/stop/delete order, where variables and credentials are injected, and which operations exist at app versus service level. Answer lifecycle questions by naming the exact scope (application or service) before choosing the operation.
Mixing up X-Play task types (for example REST API, script/CLI, and approval or manual tasks) and choosing a task that cannot carry the required inputs or return the expected output for the next step.
The task names look interchangeable at a glance, and candidates do not track what each task consumes and produces, so a REST call is placed where a script is needed or a script is used to call an API that a native REST task handles with proper output parsing.
What to do instead
Memorize a small matrix of X-Play task types: required inputs, credential handling, output variables produced, and error/failure semantics. For each scenario, write down the input available and the output the next step needs, then select the task whose contract matches both.
Writing or reading REST/CLI calls without accounting for Prism Central API versioning, the v3 versus legacy endpoint split, authentication (basic versus API key/session), and pagination or async task polling.
Candidates reuse snippets from memory or older documentation and forget that a successful call may return a task reference rather than a completed result, or that the endpoint path differs between API generations.
What to do instead
For every API question, check four things explicitly: endpoint version and base path, auth mechanism, whether the response is synchronous or an async task needing polling, and whether results are paginated. Practice one create-read-poll cycle against Prism Central so the async pattern is concrete.
Designing runbooks that depend on interactive human steps or on state that does not persist between steps, then expecting the runbook to resume correctly after an approval or a long-running operation.
Candidates think of runbooks as checklists and overlook how execution state, approvals, and timeouts are handled, so they assume variables survive arbitrarily or that a paused runbook resumes automatically.
What to do instead
Trace a runbook with an approval step and a long task: identify where execution pauses, what is persisted, what happens on timeout, and how failure in one step affects subsequent steps. Design answers so each step's inputs come from declared variables or prior step outputs, never from an assumed session.
Ignoring governance constructs (categories, projects, quotas, roles, and approval policies) when answering self-service scenarios, and instead solving access problems by granting broad permissions.
Governance features are abstract until you build them, so candidates default to 'give the user more rights' rather than using categories and project scoping to expose exactly the intended resources.
What to do instead
Map each governance tool to the question it answers: categories for targeting and policy scope, projects for isolation and quota, roles for who can do what, approval policies for gating. For self-service scenarios, first ask 'how is the resource targeted and scoped', then 'who is allowed', and prefer scoping over privilege escalation.
Reading a failed automation as a single error and stopping there, rather than following the evidence chain across playbook/runbook execution history, task logs, and the underlying Prism Central or endpoint logs to find the first true failure.
The visible error is often a downstream symptom (for example an action failing because an earlier step returned an unexpected output), and candidates who fix the symptom choose a remedy that does not address the root cause.
What to do instead
Adopt a fixed triage order: identify the first failing step in execution history, read its input/output payloads, then check the credential, endpoint reachability, and target-object state at that step. Answer troubleshooting questions by naming the first failing component, not the loudest error message.
Memorizing product feature names without being able to say what problem each solves, so scenario questions that describe an outcome are answered by keyword matching rather than by mapping outcome to mechanism.
Exam prep often degenerates into vocabulary lists; the exam instead presents operational scenarios and expects the candidate to select the construct whose behavior produces the described result.
What to do instead
For each major feature, write a one-line 'problem it solves' and a one-line 'what it cannot do'. When practicing, cover the feature names and answer from the scenario's stated outcome, then justify the choice by the feature's defined behavior rather than by a matching noun.