AP-223 CPQ and Billing Consultant Accredited Professional Exam Topics and Questions

This topic carries the exam's weight and it will cost you if your design instincts are generic. Revenue Cloud is two managed packages with hard edges, and the exam wants proof you know where native capability ends and customization begins. The domain is technical design under constraint, not aspirational architecture.

– Design within package boundaries

Recommending solutions within the capabilities of CPQ and Billing means knowing what each package does without extension. You need to distinguish between configuration that uses standard objects and fields versus changes that require custom code or external tools. The exam tests whether you reach for a declarative feature that already exists or propose development when the platform already handles the requirement. Candidates who treat every ask as a customization opportunity will lose marks. The other side matters too: recognizing when the managed package cannot meet a requirement and custom work is the only honest answer. That judgement separates candidates who have implemented these products from those who have only read about them.

– Legacy data and risk assessment

Analyzing legacy data implications means identifying what breaks when old records meet new validation rules, pricing logic or billing schedules. You are expected to spot data quality problems before they corrupt quotes or invoices, and to know which migration sequences preserve subscription continuity versus which create orphaned records. Risk assessment covers project, technical and business dimensions. The exam presents scenarios where scope creep, inadequate testing, poor integration design or misaligned stakeholder expectations threaten delivery. You must recognize the warning signs and know which mitigations actually reduce risk rather than add process overhead. The need for customization sits at the intersection of both areas: every custom component is a risk vector, and every legacy constraint shapes whether customization is justified.

How Revenue Cloud Technical Design is tested

With 68 percent of the exam, this topic determines your result. Items present a business requirement and ask which design approach fits the managed package model. Wrong answers typically propose custom development for functionality that exists in standard configuration, or suggest declarative solutions for problems that require code. You lose marks by failing to identify when legacy data structure will conflict with Revenue Cloud's data model, or by underestimating the risk a particular design choice introduces. Many items describe a client scenario with multiple constraints and ask you to choose the design that balances capability, risk and effort. The trap is recommending the most feature-rich solution when a simpler one meets the need within package limits. Others present a half-built implementation and ask what went wrong. The skill being tested is design judgement shaped by hands-on experience, not recall of feature lists.

Where the first topic tested design thinking, this one tests delivery discipline. Implementation management spans scoping through to post-deployment support, and the exam expects you to know the sequence of activities that keep a Revenue Cloud project on track. The cost comes from not recognizing when a phase is incomplete or a handoff is missing critical information.

How Revenue Cloud Implementation Management is tested

At 29 percent, this topic accounts for roughly a third of your score. Items describe a project phase and ask what activity comes next, what deliverable is required, or what risk the current state introduces. Leading scoping sessions means knowing which questions to ask stakeholders, how to surface conflicting requirements early, and when to push back on scope that cannot be delivered within package capability. Capturing solution design is tested through scenarios where documentation is incomplete or ambiguous, and you must identify what is missing before build starts. Managing build, test, deployment and support phases means recognizing when testing coverage is inadequate, when deployment sequencing will break dependencies, or when a support model will not sustain the solution post-launch. Wrong answers often describe activities in the wrong order or omit a step that later phases depend on. The exam penalizes candidates who treat project management as generic process rather than delivery shaped by how these two products behave in production.

This topic carries only 3 percent but it tests something many candidates overlook: how seasonal releases change what you should recommend. Salesforce ships CPQ and Billing updates three times a year, and a feature that required custom code six months ago may now be standard. The exam expects you to know when a new capability replaces an older workaround, and when adopting it will disrupt an existing implementation.

How New Release Capabilities is tested

Three percent means two or three items, but they can still decide a borderline result. The exam presents a scenario where a client is running an older design pattern and a recent release introduced a feature that addresses the same need. You must identify whether adopting the new capability is worth the migration effort, or whether the existing solution should remain in place. Another angle: a new feature is available but enabling it will conflict with customizations built before the feature existed. The trap is assuming every new release capability should be adopted immediately, without weighing the cost of refactoring working code. The inverse trap is failing to recognize when a new feature eliminates technical debt and simplifies long-term maintenance. The skill being tested is staying current with the platform while making pragmatic upgrade decisions. Candidates who have not reviewed recent release notes will guess.