Online professional certificate

Professional Certificate in DevOps Engineering

Follow a reviewed code change through CI/CD, validation, a known artifact and a controlled release. Practise the checks, recovery steps and handoffs that make delivery understandable to the next engineer.

Format
Online, self-paced
Study time
Up to 1 month
Curriculum
20 practical lessons
Language
English

Practical capability

Make software delivery repeatable, inspectable and recoverable.

Learn how to check the path from source change to service feedback, then make one bounded improvement at a time.

01Source and workflow control

Clarify ownership, review changes and configure pipeline triggers, jobs and permissions with an execution record.

02Build and test evidence

Connect useful validation to the build, diagnose failed or misleading runs and compare clean and reused inputs.

03Artifacts and protective gates

Trace packages or images to source and registry, then test controls on the exact artifact and current run.

04Infrastructure and runtime readiness

Check delivery dependencies, target configuration and health prerequisites before a staged deployment.

05Controlled rollout and recovery

Plan and execute a bounded stage, inspect the active target and rehearse a recovery route with the right owner.

06Feedback and operational handoff

Verify signals, distinguish service faults from observation faults and leave a concise decision or runbook for partners.

Who this course is for

A practical route into DevOps engineering.

For people beginning delivery engineering, moving from software development, or organizing hands-on build, release and platform work. The separate Role Starter Pack includes a Model Job Description, an ATS-friendly Resume Template and a Model Role SOP/Operating Playbook.

DEAspiring DevOps engineer
DESoftware developer moving into CI/CD
DEBuild or release engineer
DEPlatform or SRE practitioner

The operating cycle

Move a software change through verified delivery.

Use the role operating playbook to follow one change from request to a tested output and a clear next decision.

Step 1Clarify the request and owner
Step 2Review source and workflow
Step 3Build and validate
Step 4Identify the artifact and controls
Step 5Deploy and observe within authority
Step 6Diagnose, recover and hand off

Curriculum

Four modules. Twenty practical lessons.

Module 1

Understand the Software Delivery Path

A software change needs a clear route from a request to a usable release. In this module, you will learn how to find the right inputs, identify who owns each decision, and follow a change through source control, automation, validation and artifact creation. You will practise making small changes that someone else can review and repeat. By the end, you will be able to show what entered a build, what checks ran, and which output is ready for the next step.

01Map a Change from Request to Release

Identify the first safe action, necessary inputs, owned steps, external decisions and expected delivery output.

Five practical steps

  1. Read the request and target service
  2. Identify source, build, artifact, environment and signal owners
  3. Ask for missing inputs
  4. Mark own actions and approval points
  5. Confirm the next handoff

Primary deliverable: Delivery-path and ownership map.

02Review a Source Change for Delivery

Review a bounded source/configuration change and explain what will run and what evidence must be checked.

Five practical steps

  1. Read change request and diff
  2. Identify changed trigger or job
  3. Check dependency and permission implications
  4. Run or inspect a safe test
  5. Record review finding and handoff

Primary deliverable: Workflow change review note.

03Automate a Repeatable Delivery Task

Create and test a small repeatable script or configuration change with clear inputs and reversible behavior.

Five practical steps

  1. Specify task and inputs
  2. Choose a minimal script or configuration change
  3. Handle failures and secrets
  4. Test on a safe sample
  5. Record result and reversal

Primary deliverable: Automation task record.

04Build and Test with Reliable Inputs

Make and execute a bounded build or test validation-stage change in a safe repository, then compare clean and warm runs and verify the produced output.

Five practical steps

  1. Identify source, toolchain and missing validation
  2. Change one build or test stage in a safe repository
  3. Run the changed stage and record observed test evidence
  4. Compare clean and warm runs and artifact identity
  5. Record correctness, failure behavior and next action

Primary deliverable: Build and test verification record.

05Identify the Artifact That Will Ship

Link the deployable artifact to its source revision, build job, digest and registry location.

Five practical steps

  1. Find source revision and build run
  2. Identify produced artifact and digest
  3. Check publication identity and destination
  4. Match target environment request
  5. Record ambiguity and handoff

Primary deliverable: Artifact identity record.

Module 2

Engineer Repeatable Delivery

A useful pipeline makes the same change travel through predictable checks. Here you will configure a workflow, diagnose a failed run, and keep the artifact connected to the code and job that produced it. Infrastructure and runtime settings support this path. You will learn to check what those settings do for delivery, record the result, and involve the right platform or security partner when the change needs their decision.

06Configure and Verify a CI/CD Workflow

Configure a bounded workflow and verify its trigger, execution identity, validation and failure behavior.

Five practical steps

  1. State expected trigger and stages
  2. Configure a small workflow
  3. Check permissions and dependency identity
  4. Run success and failure cases
  5. Record observed behavior and review decision

Primary deliverable: CI/CD workflow definition and verification note.

07Find the Cause of a Failed Pipeline

Narrow a failed run to a reproducible cause and recommend a bounded correction or owner handoff.

Five practical steps

  1. Capture failure and last good run
  2. Locate first differing stage
  3. Form competing hypotheses
  4. Test one safe discriminating check
  5. Document finding and next owner

Primary deliverable: Pipeline failure diagnosis.

08Configure Artifact and Security Gates

Configure a scoped artifact security or provenance gate in an approved sandbox, test passing and failing or unavailable cases, and control promotion of the exact artifact.

Five practical steps

  1. Identify requested artifact, source endpoint and digest
  2. Configure a scoped gate in the approved sandbox
  3. Run passing and failing or unavailable-control tests
  4. Record exact artifact and gate evidence
  5. Stop or promote within authority and route any exception

Primary deliverable: Artifact gate configuration and test record.

09Plan an Infrastructure Change for Delivery

Plan and perform an approved nonproduction infrastructure test or plan/apply-equivalent verification for a delivery dependency, record the observed result and hand any platform-owned decision to its owner.

Five practical steps

  1. Name the delivery dependency and current state
  2. Inspect the IaC change and predicted effects
  3. Identify platform owner and approved test scope
  4. Run an observed nonproduction test or plan/apply-equivalent verification
  5. Compare predicted and observed state, then document handoff

Primary deliverable: Delivery infrastructure change and test record.

10Check a Runtime Before Deployment

Check a target environment's deployment prerequisites and document what blocks release.

Five practical steps

  1. Identify intended artifact and target
  2. Check configuration and secret references
  3. Verify runtime and health prerequisites
  4. Test nonproduction behavior
  5. Record blockers and owner handoff

Primary deliverable: Runtime readiness checklist.

Module 3

Deploy, Observe and Recover

A deployment is useful only when the team knows what it is releasing, how it will watch the result, and what it will do if the service changes for the worse. This module turns a verified artifact into a controlled rollout. You will practise planning a release, observing a staged deployment, explaining a decision to partners, and rehearsing recovery. Production approval and security exceptions remain with the people who hold those responsibilities in the local organization.

11Prepare a Controlled Release

Write a release plan that names the target artifact, rollout method, checks, stop conditions and owner.

Five practical steps

  1. Confirm target and artifact
  2. Choose bounded rollout and window
  3. Set health checks and stop conditions
  4. Identify approver and communications
  5. Review a rehearsal outcome

Primary deliverable: Controlled release plan.

12Change and Run a Staged Deployment

Change and execute a bounded nonproduction deployment workflow through an approved gate and prove the actual target artifact identity and observed result.

Five practical steps

  1. Check approval, target and known artifact
  2. Make a small deployment workflow or configuration change
  3. Execute the approved nonproduction gate and rollout
  4. Inspect actual deployed target identity and health
  5. Record result, stop condition and owner decision

Primary deliverable: Executed staged deployment record.

13Coordinate a Release Decision

Present verified facts, uncertainties and options to the correct decision owner without assuming approval authority.

Five practical steps

  1. Collect current artifact and health evidence
  2. Name unresolved risks and impacted partners
  3. State options and criteria
  4. Send a concise recommendation
  5. Record the owner decision and next action

Primary deliverable: Release decision brief.

14Validate a Deployment Health Signal

Before a release decision, verify matching, nonmatching and absent health signals at the intended deployment check and discriminate a label, webhook or release-association fault.

Five practical steps

  1. Trace expected signal path
  2. Send matching and nonmatching test inputs
  3. Verify release association and receipt
  4. Discriminate label, webhook or release-association causes of a missing signal
  5. Record correction or escalation without declaring an unseen release healthy

Primary deliverable: Pre-release signal validation record.

15Rehearse Rollback and Manual Recovery

Rehearse a rollback in nonproduction, prove the target returned to the exact known prior artifact or version with an observed health check, and document failed-rollback manual escalation.

Five practical steps

  1. Confirm the known prior digest or version, target and owner
  2. Trigger an approved bounded failure condition
  3. Run rollback and inspect exact target identity
  4. Check the restored service health signal
  5. Test or simulate failed rollback and document manual escalation

Primary deliverable: Rollback rehearsal record.

Module 4

Operate and Improve the Delivery Service

Delivery engineering continues after a rollout. A failed job, changed telemetry field or repeated handoff problem is a chance to diagnose the system and make the next release easier to understand. You will practise investigating a fault, reviewing controls, agreeing work across teams, writing a usable runbook and adapting the role to a local employer. The aim is to make careful changes with clear evidence and a reliable next person to call.

16Diagnose and Recover a Delivery Incident

Diagnose an event after it occurs, rule out at least one competing cause, recommend a bounded recovery action and verify the result with the service owner.

Five practical steps

  1. Capture impact and current service state
  2. Compare service, delivery and telemetry evidence
  3. Test competing causes safely
  4. Recommend or perform an authorized recovery action
  5. Verify result and hand off follow-up

Primary deliverable: Incident diagnosis and recovery note.

17Review Delivery Gates and Exceptions

Evaluate control evidence, test an intended policy change safely and route exceptions to the authorized owner.

Five practical steps

  1. Identify control and failed condition
  2. Confirm scope, edition and intended behavior
  3. Reproduce in safe evaluation mode
  4. Present options and consequences
  5. Record authorized resolution

Primary deliverable: Delivery gate review.

18Agree an Improvement with Partner Teams

Facilitate a bounded interface agreement and record responsibilities, evidence and follow-up.

Five practical steps

  1. State recurring problem with examples
  2. Ask each partner for constraints
  3. Propose a limited interface and owner
  4. Confirm the agreed test and timing
  5. Record handoff and follow-up

Primary deliverable: Delivery improvement agreement.

19Write an Operator Handoff Runbook

Create one integrated runbook that gives the next operator the first action, ordered checks, work rhythm, stop conditions and escalation for a blocked promotion.

Five practical steps

  1. State trigger and current state
  2. List inputs and checks in order
  3. Mark stop conditions and owner decisions
  4. Record recovery and contact route
  5. Have a second reader test the note

Primary deliverable: Operator handoff runbook.

20Assess Role Fit and Progression

Create one truthful role-fit and progression analysis that distinguishes common delivery work from required, preferred, local and advanced conditions.

Five practical steps

  1. Read both postings for central delivery work
  2. Classify required, preferred and local conditions
  3. Separate common work from specialist or senior scope
  4. Match only truthful learner evidence
  5. State gaps, clarifying questions and progression action

Primary deliverable: Role-fit and progression analysis.

Applied capstone

Assess a staged release and recommend a next action.

Use the supplied observations to verify one intended artifact and one health signal before making an owner-ready recommendation.

The situation

A fictional customer-facing search service has a reviewed change and a passing build. Two registry image digests carry the same readable tag. A staged rollout is under way, and a monitoring alert reports elevated errors while one dashboard still appears green. The release window is closing.

Your task

Verify the intended artifact and the health signal, then submit a recommendation to continue, pause or recover to the named release approver, who makes the release decision.

Release recommendation briefOne evidence-based next-action recommendation for the named release approver, with verified facts, uncertainty and options.

The people behind MTF

Meet MTF faculty and the learner community.

Explore the professional backgrounds of MTF faculty and learn more about the international community studying with the Institute.

Enrollment

Enroll in Professional Certificate in DevOps Engineering

One-time course price: €10, including applicable taxes. Payment is processed securely by Stripe. No card details are stored on the MTF Institute website.

You will receive an email with access to the course. If you have any difficulties, please write to welcome@gtf.pt.

Secure payment on this page

Enter your enrollment email to continue in Stripe's encrypted form.

Cards, Apple Pay, Google Pay and other eligible methods

Questions and details

Frequently asked questions

Open the sections that matter to you, including delivery format, AI-supported practice and the evidence used to design the curriculum.

Who is this DevOps Engineering course for?

It is designed for beginning DevOps engineers, software developers moving into delivery work, build or release engineers, and platform or SRE practitioners who want a clear source-to-feedback method. The cases start with bounded tasks and make local decision owners explicit.

What will I learn to do?

You will map a delivery path, review and configure CI/CD workflows, verify build and test results, trace artifacts, assess deployment prerequisites, observe a staged rollout, diagnose failures and hand off recovery or release decisions with evidence.

What practical work will I complete?

Each of the twenty lessons produces one usable work product, including a workflow review, artifact identity record, runtime readiness checklist, release decision brief, signal-path validation record and operator handoff runbook. The applied case asks for one Release recommendation brief.

Do I need to use one specific cloud or CI platform?

The course uses representative tools to show transferable checks: what source ran, which tests executed, which artifact moved, what the target reported and what signal reached the decision point. Apply the method with the systems and approved permissions in your own environment.

How is AI used in the lessons?

Each lesson offers a copyable drafting prompt, a separate critic prompt and a complete worked context. You check the draft against the supplied records, test actual system behavior where the task calls for it, and keep approvals with the responsible people.

What evidence informs the curriculum?

The course connects a structured study of 106 U.S.-eligible DevOps-related requisitions observed on 14 October 2026 with an independent review of recent workflow, artifact, deployment-feedback and telemetry changes. The research and trend publications explain their sources and limits.

What is the applied capstone?

You assess a staged search-service release with conflicting artifact and health observations. You prepare one Release recommendation brief that separates verified facts, uncertainty, options and a proposed next action for the named release approver.