Separate the Architecture exam from Application Design & Build
Pega Academy calls the credential Certified Pega Lead System Architect (CPLSA). A System Architect certification and then a Senior System Architect certification are required on the path. Pega recommends real-world implementation experience before attempting CPLSA, but describes its 36-month experience suggestion separately from the formal certification prerequisites. Confirm your own current eligibility directly with Pega Academy's program page.
The Lead System Architecture exam assesses design and architecture knowledge first. After passing it, candidates move to the Application Design & Build assessment. Pega describes the Infinity '25 version as a single-phase assessment that uses Blueprint to support design; candidates still submit a high-level design supplemented by the generated Blueprint document as well as an implemented application. Older descriptions of separate design and build phases should not drive a current plan. Check the official version and instructions before scheduling because Pega controls these requirements.
The plan below helps you build independent skills and evidence. It does not reproduce an official assessment scenario, predict exam tasks, verify your eligibility or promise a passing result.
Start with a gap matrix you can update
Rate each capability as can explain, can demonstrate or needs practice. “Can explain” means you can state the trade-off; “can demonstrate” means another person can inspect a small artefact or test. Keep the distinction visible: knowing a term is not the same as applying it in an application.
| Capability | Evidence to keep | Next practice activity |
|---|---|---|
| Requirements and case design | A requirements-to-case map with personas, stages, alternate paths and acceptance criteria | Take an ambiguous request and write three clarifying questions before drawing a case life cycle. |
| Data, reuse and integration | A small data model, a boundary diagram and a written reason for each reusable rule | Decide which data belongs in the case, which is referenced and which comes from another system. |
| Security and user experience | A role-to-action matrix plus views tested with two different personas | Try to access a restricted record as the wrong persona, then explain the control that blocks it. |
| Operations and quality | Exception tests, a background-work decision, a deployment checklist and a short support runbook | Simulate one failed integration and one duplicate request; record recovery without hiding either failure. |
Record your result after each practice cycle: what was unclear, the choice you made, a test you ran and what you would change. Use the current Lead System Architect mission to find learning material for a weak area rather than searching for alleged “real App Build” answers.
Five adaptable preparation stages
These are milestones, not a fixed-duration class or a claim about how quickly someone becomes ready. If you already lead Pega implementations, a stage may be a short review; if you have not built and operated complex applications, it may need several practice cycles.
Confirm the official path and create a baseline
Begin with Pega Academy, not an old App Build checklist. The current CPLSA pathway requires prior System Architect and Senior System Architect certifications. Pega recommends substantial field experience; it does not present the recommendation as an extra certification prerequisite. The Lead System Architecture exam comes before the Application Design & Build assessment.
- Open the current CPLSA program page and note the assessment version that applies to you.
- Read the current Lead System Architect mission and Architecture exam outline. Mark each topic as explain, practise or revisit.
- Choose one original, non-confidential application idea and define what a reviewer could inspect at the end.
Keep this output: A dated gap matrix and a one-page learning objective, not a guessed exam timetable.
Refresh architecture decisions before configuring rules
The Pega '25 mission groups advanced learning around Constellation Adoption, Infrastructure and Architecture, Planning and Design, and Implementation and Deployment. Use those areas to ask why a design is appropriate, not merely whether a feature exists.
- Explain the intended application layers, reusable capabilities and data ownership in plain language.
- Compare synchronous and asynchronous work, including what the user sees if a downstream service is unavailable.
- Sketch how access, auditability, monitoring and deployment affect the design from the beginning.
Keep this output: A small decision log: choice, alternative, trade-off and a test that could disprove your assumption.
Design an independent practice application
Use your own fictional business requirements. Pega's Infinity '25 assessment is a combined, single-phase Application Design & Build exercise using Blueprint, but an independent practice project must never be described as the official scenario or submitted work.
- Define personas, case stages, the data model, approval and exception paths before implementation.
- Use Blueprint to explore a starting design, then review and revise every suggested case type, stage, step, data object and integration boundary.
- Keep a human-authored high-level design and explain what changed between the first Blueprint and the final application.
Keep this output: A shareable practice brief, revised design and small demonstrable application using invented data.
Test the design from more than one role
A happy-path demonstration is not enough. Test whether each persona sees the right work, whether the application recovers from failure and whether the design remains understandable to another builder.
- Write positive, negative and exception tests from acceptance criteria before marking a feature complete.
- Trace a denied action, a duplicate request and a failed external response through user messaging and support evidence.
- Ask a peer to review your independent design rationale, not confidential assessment materials.
Keep this output: A test matrix with observed results, unresolved defects and a brief deployment or rollback note.
Review weak areas and choose the next official step
Review your gap matrix again. A useful readiness decision is based on what you can explain and demonstrate, not on the number of hours spent or a claim that a practice app predicts the assessment.
- Explain two design trade-offs without reading your notes and identify a situation where your first choice would fail.
- Show evidence for access controls, exception handling, testing and maintainability.
- Recheck the Pega Academy program page for current eligibility, registration and assessment instructions before booking.
Keep this output: An honest readiness summary and a short plan for the remaining gaps.
Example: an independent software-access request app
Imagine a fictional company where employees request access to an internal software tool. A manager approves the business need, a system owner checks licence availability, an administrator fulfils the request and security can audit who approved which entitlement. This is an original ITCertPath practice example, not a Pega assessment scenario or an invitation to discuss an assessed submission.
- Clarify requirements. Ask whether urgent requests can bypass a manager, what happens when a licence is unavailable, who revokes access and which data must be retained. Turn the answers into observable acceptance criteria.
- Model the case. Sketch intake, manager decision, entitlement check, fulfilment and closure. Compare a single case type with a separate fulfilment subcase; explain when splitting work would improve ownership and when it would add complexity.
- Define data boundaries. Distinguish the requester and requested entitlement from licence inventory held in another system. Decide how to refresh external data and what the case should show if that integration is unavailable.
- Make access explicit. A requester should see their own request, while a system owner may see licence data. Test a denied action rather than relying only on a hidden UI control.
- Review the Blueprint. Use Pega Blueprint as a design starting point where available, then revise generated stages, personas and data objects. Explain every important edit and keep human review visible.
- Prove behaviour. Test approval, rejection, no available licence, duplicate request and a failed external response. Document what the user sees, what is logged and how work resumes.
The artefact is most useful when another learner can understand the alternatives and rerun the tests. The related practice-project design and testing guide provides a more detailed method for a decision record and test coverage.
A readiness review based on evidence
Before moving to the next official step, ask a trusted peer to challenge your independent practice design. Do not ask them to review any real assessment materials. The following questions expose gaps more reliably than a self-reported number of study hours.
- Can you explain the business requirement and show where each acceptance criterion is tested?
- Can you defend your case structure, application layers and reuse decisions against a plausible alternative?
- Can you identify where data lives, what comes from an external system and how a failed integration is handled?
- Can two personas demonstrate different permitted actions, with one negative access test?
- Can you describe what Blueprint suggested, what you changed and why the final design remains maintainable?
- Can you show test evidence for a normal path, an exception and recovery after failure?
- Can you describe deployment, monitoring and rollback considerations without assuming that a working demo is production-ready?
- Have you reopened Pega Academy to confirm the assessment version, eligibility and instructions that apply to your booking?
If you cannot support an answer with a document, rule, test result or explanation, add a small focused exercise. Repeat the review after fixing the weakest two areas rather than starting another large practice application immediately.
Protect the official assessment boundary
Pega's program page states that candidates must not share their actual Application Design & Build scenario or work outside the Pega CPLSA team. Keep official prompts, submitted designs, application packages and questions out of public forums, training enquiries and peer reviews. Only bring independently invented examples and general learning goals to a discussion with ITCertPath or another mentor.
For current assessment instructions, use the Pega CPLSA program overview rather than an older tutorial or a seller's promise. For a broader conversation about your study goals and what independent support may be available, see Pega LSA App Build preparation guidance. You can also compare the overall credential on the Pega certification page.
Official references and editorial note
This ITCertPath guide organizes preparation activities independently. Pega controls certification requirements, assessment materials and registration. Official pages may change; we last checked the sources below on 25 October 2026.
Read ITCertPath's editorial standards and revisit Pega Academy before acting on version-specific information.