PMI CD-P common mistakes
PMI CD-P · Understand the traps and how to avoid them.
Treating the stated request as the problem and jumping straight to a solution design, instead of spending discovery time on who is affected, what the current process costs, and how success will be measured before choosing a tool.
Citizen developers are usually handed a request by a colleague and feel pressure to show progress quickly; the platform is familiar, so building feels faster than interviewing stakeholders. The exam rewards problem framing first, so answers that skip discovery look efficient but are scored as incomplete.
What to do instead
Before any build decision, produce a short framing artifact: the business outcome in one sentence, the affected roles, the baseline metric and target, and the assumptions that would invalidate the project. Practice answering scenario questions by first asking 'what evidence would confirm this is the real problem?' and only then evaluating solution options.
Scoping the first release to the full end-to-end process because 'we will need it eventually', rather than carving out a thin slice that delivers measurable value and can be validated in weeks.
Candidates confuse thoroughness with professionalism and worry that a narrow scope will look unambitious. In practice, large first releases hide unvalidated assumptions until late, and the exam tests whether you can sequence value delivery under uncertainty.
What to do instead
Define a minimum viable scope with an explicit out-of-scope list and a stated learning goal for the first release. Rehearse justifying the cut to a sponsor using risk language: which assumptions get tested cheaply, and what decision the early release informs.
Selecting a platform because it is the one already licensed or the one the candidate knows, without mapping requirements such as data volume limits, connector availability, offline needs, licensing model, or environment strategy to the platform's actual constraints.
Tool familiarity creates anchoring, and licensing details feel like procurement trivia rather than exam content. The exam expects candidates to reason about platform fit and total cost, including connectors, premium features, and environment capacity.
What to do instead
Build a one-page comparison matrix for the two or three realistic platform options, scoring each against a fixed requirement list drawn from discovery. Memorize the categories that drive cost and constraint: connector tiers, API and request limits, storage, environment counts, and identity integration.
Assuming the default environment is fine for everything, so development, testing, and production artifacts share one environment with no solution packaging or managed-solution discipline.
A single maker environment works for a demo and is the path of least resistance. Candidates underestimate how environment strategy, solution layering, and connection references affect deployment and support, which the exam treats as core platform knowledge.
What to do instead
Learn the standard pattern: separate development, test, and production environments; build in an unmanaged solution; export and deploy as a managed solution; keep connection references and environment variables out of the solution's hard-coded values. Be able to explain what breaks when this discipline is skipped.
Designing the data model around the screens the requester described, creating a table per form, rather than modeling entities, relationships, and ownership so the same data serves multiple views and reports.
Requirements arrive as UI sketches, and translating them literally feels responsive. Normalization and ownership decisions are invisible in a demo but determine whether reporting, security, and later features are feasible.
What to do instead
Practice converting a described screen into entities with keys, relationships, and an owner field, then check the model against three future questions the business will ask. State explicitly which fields are calculated versus stored, and where the record's security boundary sits.
Putting business logic in the user interface layer, such as button visibility or form scripts, when the rule must hold for imports, API writes, and other apps, instead of enforcing it at the data layer.
UI-level logic is the fastest way to make the demo behave, and the candidate never sees the bulk-import path that bypasses it. The exam tests whether you can distinguish where a rule must be enforced from where it is merely convenient.
What to do instead
For each business rule, ask 'through which channels can this record be created or changed?' and place enforcement at the lowest layer that all channels pass through. Keep UI logic for presentation only, and be ready to say why a duplicate rule in both layers is sometimes justified.
Testing only the happy path with the maker's own account, skipping role-based checks, bulk data volumes, and the integration points that were stubbed during development.
The maker is typically an administrator or owner of the app, so permission problems are structurally invisible; test data is small; and external calls are the hardest thing to simulate, so they get deferred. The exam probes whether testing covers permissions, scale, and failure of dependencies.
What to do instead
Write a test plan with named personas at each security role, a dataset sized to realistic volume, and explicit negative cases for each integration including timeout and bad response. Record who signs off on each scenario before go-live.
Deploying by rebuilding or editing directly in production because it is faster than packaging and promoting, leaving no reproducible artifact and no rollback path.
Small changes feel exempt from release discipline, and the candidate has never had to restore a broken production app. The exam expects deployment as a repeatable pipeline with a known previous version and a communication plan.
What to do instead
Adopt a release checklist: version the solution, deploy the same artifact to test and production, capture a backup or prior managed solution before import, and define the rollback step and the user communication in advance. Practice describing the sequence for a mid-week hotfix.
Answering governance questions by choosing the most restrictive control available, such as a full ban or central approval of every app, rather than matching control strength to data sensitivity and business criticality.
Candidates associate governance with risk avoidance and assume stricter is safer. Over-control pushes makers to shadow IT, which is the outcome governance exists to prevent, so the exam rewards tiered, proportionate controls.
What to do instead
Build a tiering model: classify data and app criticality, then define what each tier requires for review, DLP policy, environment, and support ownership. When answering, name the tier and justify why a lighter or heavier control fits it.
Treating IT as an approver to be avoided until launch, so identity, data loss prevention, support ownership, and integration credentials are discovered at the end and force rework.
Citizen developers are empowered to build without tickets, and early IT contact can feel like inviting blockers. The exam tests collaboration behaviors: early consultation on shared concerns while retaining maker autonomy.
What to do instead
Define a short pre-build conversation with IT covering identity and access, data classification and DLP, integration endpoints and credentials, and who supports the app after handover. Frame the ask as guardrails and reusable services rather than permission, and document the agreed ownership in the app's record.