Understand the deployment choice and operational responsibilities before moving a process from a developer exercise to production.
Evaluate Camunda's managed and self-managed options against data, security, operations, and environment needs. A development quickstart is useful for learning but is not a production architecture by itself.
Try it: Write a one-page decision record for a team that needs separate development and production environments and has a residency requirement.Camunda's self-managed reference architecture distinguishes a management plane from Orchestration Clusters. Plan identity, tenant isolation, upgrades, backups, and monitoring as explicit responsibilities.
Try it: Draw a high-level architecture with users, workers, identity, and one cluster per environment; mark who operates each component.Production readiness includes tested deployment, incident response, and recovery—not just a successful model upload. Review the current supported-environment matrix before choosing infrastructure versions.
Try it: Describe how the team would detect a stopped worker, protect in-flight work, and recover service without silently losing a process instance.The managed and self-managed options place different operational work on the customer team. Record data-location, network, identity, availability, upgrade, and support requirements before selecting a deployment. A local quickstart proves a model can run; it does not prove the organization can manage backups, identity integration, and incident response. Camunda's self-managed reference architectures are starting points rather than one-size-fits-all prescriptions. State which requirements are confirmed, which need a security review, and which can only be tested in a representative environment.
Try it: Create a decision table with five requirements for a regulated team. Compare managed and self-managed options without assuming either satisfies residency or compliance automatically.A working process depends on more than its orchestration cluster. It may need authentication for modelers and workers, outbound network access to partner APIs, secrets, observability, and a route for human tasks. A fault in any of those dependencies can leave instances waiting even when the platform itself responds. Draw the architecture as request paths and failure domains, not merely as a list of product names. For each component, assign an owner, upgrade window, log source, and recovery procedure. Keep development and production identities and endpoints separate so a test worker cannot act on live jobs.
Try it: Draw a small system with a process, worker, identity provider, task user, and external API. Mark what fails if each dependency is unavailable and how the operator detects it.A deployment checklist should include model versioning, worker compatibility, access control, and a tested response to failed jobs. Simulate a worker outage and verify that instances remain discoverable, then restore it and check completion. Review backup and restore procedures for the chosen architecture with the actual operators. For self-managed deployments, follow the current Camunda supported-environment and reference-architecture guidance rather than copying an old diagram unchanged. The output of the drill is evidence: which alert fired, who responded, how long recovery took, and whether any business operation was repeated.
Try it: Write a go/no-go checklist for one process launch: access, worker health, incident review, test recovery, version rollback plan, and business owner sign-off.This topic is an independent ITCertPath learning guide, not a separately named Camunda credential. Check current product behavior in the official documentation.
Read the official Camunda documentation ↗Tell us your goal, country and preferred schedule. Ask for the written syllabus, trainer, delivery format, fee and cancellation terms before enrolling.