OutSystems Delivery Specialist study materials
OutSystems Delivery Specialist study resources

OutSystems Delivery Specialist study plan

OutSystems Delivery Specialist · Give each week a clear focus.

8 weeks · About 6 hours per week

Week 1

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.

Week 2

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.

Week 3

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.

Week 4

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.

Week 5

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.

Week 6

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.

Week 7

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.

Week 8

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.