OutSystems Delivery Specialist study plan
OutSystems Delivery Specialist · Give each week a clear focus.
8 weeks · About 6 hours per week
Exam content domain 1 (not enumerated in source) & Exam content domain 2 (not enumerated in source)
Map the four exam domains into a personal tracker, weighting Domain 1 and Domain 2 at 60% of total study time because they carry the same 25% each but anchor the rest of the material.
Define OutSystems platform vocabulary in your own words: module types, reactive vs traditional web, entities, aggregates, server actions, client actions, screens, and blocks.
Build a one-page glossary of 20 platform terms with a concrete example of where each appears in a real project.
Set up a free OutSystems personal environment and confirm you can create, publish, and open a blank reactive app end to end.
Your checkpoint
A published blank reactive app plus a 20-term glossary document stored in your notes.
Exam content domain 1 (not enumerated in source)
Model a normalized data layer for a small case study (for example a course enrollment app) with at least four entities and correct relationship cardinalities.
Write aggregates that filter, sort, and join entities, and explain in writing why an aggregate beats a hand-written loop for each case.
Implement static and dynamic entity actions and describe when server-side logic must run instead of client-side logic.
Document three data-modeling mistakes you made or nearly made and the correction for each.
Your checkpoint
A working data model with four entities, five aggregates, and a written design rationale of at least 300 words.
Exam content domain 1 (not enumerated in source) & Exam content domain 2 (not enumerated in source)
Build a multi-screen flow with input validation, a list screen, and a detail screen, wiring navigation parameters correctly.
Implement client variables, screen input parameters, and session variables, and record which scope you chose and why for each value.
Add reusable blocks and a layout, then refactor duplicated UI into those reusable elements.
Trace one user action from button click through screen action, server action, and aggregate, writing the call path in order.
Your checkpoint
A three-screen working app with at least two reusable blocks and a written call-path trace for one user action.
Exam content domain 2 (not enumerated in source)
Implement exception handling with explicit error flows and user-facing messages, then test the failure path deliberately.
Apply role-based access control: define roles, protect screens and server actions, and verify a lower-privilege user is actually blocked.
Add a REST API integration consuming an external endpoint, including error handling for timeout and non-200 responses.
Review your app against a self-made checklist of 15 platform best practices and log every violation found.
Your checkpoint
A security and integration hardening report listing each finding, the fix applied, and a retest result.
Exam content domain 3 (not enumerated in source)
Explain the deployment lifecycle from development to quality to production, including what a solution and a deployment plan contain.
Describe how OutSystems handles application versions, and practice tagging and rolling back a version in your environment.
Write a checklist for promoting an app between environments that covers dependencies, timers, and site properties.
Identify which configuration values belong in site properties rather than hard-coded in logic, and move at least three values accordingly.
Your checkpoint
A one-page environment promotion checklist plus a tagged version and a documented rollback rehearsal.
Exam content domain 3 (not enumerated in source) & Exam content domain 4 (not enumerated in source)
Instrument your app with logs and timers, then verify a scheduled timer executes and is visible in the monitoring view.
Diagnose one deliberately introduced performance problem using aggregate analysis and explain the root cause in writing.
Describe the roles and responsibilities across a delivery team and where code review, testing, and release approval sit.
Draft a test plan covering unit, integration, and user acceptance levels for your case-study app.
Your checkpoint
A performance diagnosis write-up with root cause and fix, plus a three-level test plan.
Exam content domain 4 (not enumerated in source)
Complete a full timed practice set across all four domains and score it by domain to expose weak areas.
Re-study your two lowest-scoring domains using targeted notes rather than re-reading everything.
Teach two difficult concepts aloud or in writing as if explaining to a junior developer, and note where your explanation stalled.
Rebuild one feature from scratch without notes to confirm retention.
Your checkpoint
A scored practice result with a per-domain breakdown and a ranked list of the five weakest topics.
Exam content domain 1 (not enumerated in source) & Exam content domain 2 (not enumerated in source) & Exam content domain 3 (not enumerated in source) & Exam content domain 4 (not enumerated in source)
Close the five weakest topics from week 7, writing a short corrective note for each.
Run two full timed mock exams under exam conditions and compare domain scores between attempts.
Review your glossary, checklists, and error log once, converting anything still shaky into flashcards.
Finalize exam-day logistics: format, timing, allowed materials, and a pacing strategy per question.
Your checkpoint
Two scored mock exam results showing improvement, plus a final one-page summary sheet.
Milestones
Week 2: You can model a four-entity data layer and justify each aggregate without referring to notes.
Week 4: Your app enforces role-based access, handles exceptions, and consumes an external REST endpoint with tested failure paths.
Week 6: You can explain the deployment lifecycle and diagnose a performance issue end to end in your own words.
Week 8: Two timed mock exams completed with all four domains scored and a documented improvement between attempts.