GitOps and Continuous Delivery

For development, DevOps and platform teams: practise traceable delivery through Git. Kubernetes is followed by Helm or Kustomize, GitLab CI/CD and Argo CD or Flux; preparation and advanced monitoring are optional.

THE LEARNING PATH AT A GLANCE

GitOps and Continuous Delivery: stages, scope and sequence

The route spans 5 stages, from “Prior knowledge” to “Role focus”. Workshop counts, training days and price refer to the core route.

  • 4 workshops · Core route
  • 10–11 training days · Core route
  • €5,550 to €6,105 excluding VAT · Core route
  1. Prior knowledge

    Existing experience can replace individual stations.

  2. Container foundation

    Either container foundation leads into the shared Kubernetes basics.

  3. Kubernetes basics

    Practical foundations for later role responsibilities and certification goals involving hands-on exams.

  4. Operations practice

    You deepen workload practice, scaling, access and network rules, operational signals and configuration per environment.

  5. Role focus

    This learning path follows a role path, which optional topics deepen.

Your route through this path

YOUR LEARNING PATH

The experience you bring

Check which learning steps you still need.

Find your starting point: 3 questions

TEAM ROUTE: OPTIONAL

Plan a shared training programme

Roles → skill gaps → shared plan

The result: a clear route for the whole team.

Your self-assessment

For each question, choose the answer that best describes your current situation.

Exam preparation is available only on request, outside all totals.

Recommendation without contact details or sign-up

Goal set by this learning path

Skills, sequence, workshops

Which Kubernetes skills build on each other?

The learning steps show this path’s recommended sequence. Depending on your goal, they include specialisations, optional topics or certification goals. Each step shows the workshops that cover it.

How to read the learning path
  • Required or recommended
  • Choice
  • Optional further study
  • Further learning path

Preparation

Before starting, if needed; excluded from the workshop count, days and price.

Show 6 skills
  • Prior knowledge

    Existing experience can replace individual stations.

    • PRIOR KNOWLEDGEOptionalIF NEEDED
      Linux and network access

      Command line, processes, file system, connectivity, ports, SSH access

      You practise Linux commands, processes and file permissions, check network interfaces, connectivity and open ports, and connect to remote computers using SSH. The Linux workshop helps fill knowledge gaps; the Docker and Podman workshops introduce YAML as a configuration format.

      Afterwards, you can inspect files, permissions and processes in a Linux terminal, narrow down network problems and work on remote computers using SSH.

      Linux command line skills are required for GitLab CI/CD and Argo CD, and for the Kubernetes introduction; Helm and Kustomize also require confidence in the terminal. If you lack these skills, build them in the Linux workshop; with existing experience, you can skip it.

      4 learning moves
      1. Navigate the file system

        You use shell commands to navigate directories and search file contents, so you can find your way around a Linux system.

      2. Check permissions and processes

        You check file permissions and running processes to understand access boundaries and stop unresponsive processes selectively.

      3. Examine network access

        You check network interfaces, connectivity and open ports separately to narrow down connection problems.

      4. Access remote computers with SSH

        You connect to a remote computer using SSH to apply your terminal skills on another system.

      • Prerequisite: The “Kubernetes basics” competency requires Linux and terminal fundamentals; if you already have this knowledge, you do not need the Linux workshop.
    • PRIOR KNOWLEDGEOptionalIF NEEDED
      Git and collaboration

      Commits, branches, merges, remotes, reviews

      You version changes with Git and practise collaboration through branches and reviews. Choose the Git introduction or the workshop using GitLab as its platform.

      Afterwards, you can version changes with Git, share them through branches and remotes, merge them after review and resolve merge conflicts.

      GitLab CI/CD requires Git fundamentals; Argo CD and Flux also require collaboration through branches and pull requests. If you lack these skills, choose Git or Git with GitLab; with existing experience, the preparation course is optional.

      4 learning moves
      1. Record changes as commits

        You trace changes from the working directory through the staging area to a commit, so you can choose what to version.

      2. Separate work with branches

        You work on changes separately in branches and compare them before bringing the work back together.

      3. Exchange changes through remotes

        You share commits through remote repositories and distinguish fetching other people's changes from integrating them.

      4. Review and merge changes

        In reviews, you discuss changes through their differences and resolve merge conflicts to combine contributions with team input.

      Choose 1 of 2

      Choose the Git workshop to start, or the GitLab workshop if your team uses GitLab.

      • Prerequisite: Working on GitLab pipelines requires Git fundamentals; existing experience can replace the introductory workshop.
      • Prerequisite: Argo CD and Flux require Git knowledge including branches and pull requests; existing experience removes the need for an additional workshop.
      • Prerequisite: The policy workshops require experience with Git branches; existing experience is sufficient.
  • Container foundation

    Either container foundation leads into the shared Kubernetes basics.

    Choose 1 of 2

    Choose Podman if your team or target platform uses it or containers must run without root privileges; otherwise choose Docker.

    • CONTAINEROptionalCHOICE
      Docker fundamentals

      Images, containers, volumes, networks

      You build container images with Dockerfiles, including multi-stage builds, and run containers with persistent storage and network connections. With Docker Compose, you run related application services.

      Afterwards, you can build custom images, connect containers with persistent storage and run related application services with Docker Compose.

      This optional preparation introduces container images and YAML. Container experience helps with the Kubernetes introduction but is not required; Helm and Flux expect YAML knowledge, while Kustomize also expects practice with simple Kubernetes manifests.

      4 learning moves
      1. Distinguish images from containers

        You start containers from images and inspect their state to distinguish the template from the running application.

      2. Build custom images

        When building images, you separate build stages from runtime contents so that build tools need not remain in the final image.

      3. Connect storage and networks

        You use volumes to retain data across container restarts and connect containers through networks so they can exchange data.

      4. Combine services with Compose

        In Docker Compose, you describe services, storage and networks with YAML and check how they work together in an application.

      • Recommended next step: Container experience helps with the Kubernetes introduction but is not a prerequisite for the fundamentals workshop.
      • Replacement route: The bundle connects Docker and Kubernetes through a shared booking and learning group instead of separate dates. It requires more prior knowledge: Linux command-line skills and development or system administration basics.
    • CONTAINERAlternativeCHOICE
      Podman fundamentals

      Rootless containers, pods, images

      You build container images with Podman and run containers without root privileges, with persistent storage and network connections. You group related containers into pods.

      Afterwards, you can build Podman images, run containers without root privileges using networking and persistent storage, and group them into pods.

      Choose Podman instead of Docker as optional preparation if your team already works with Podman or containers without root privileges.

      4 learning moves
      1. Understand rootless operation

        Through Podman's architecture, you learn how containers run under your user account without a central daemon.

      2. Build and manage images

        You build images and manage them in registries to provide applications as a reusable basis for containers.

      3. Connect networking and storage

        With networks and volumes, you connect containers and retain data while checking file permissions in rootless operation.

      4. Group containers into pods

        In pods, you group related containers and check their communication across the shared network.

      • Recommended next step: Container experience helps with the Kubernetes introduction but is not a prerequisite for the fundamentals workshop.
  • Operations practice

    You deepen workload practice, scaling, access and network rules, operational signals and configuration per environment.

    BOTH OPTIONAL

    These competencies deepen the learning path and are optional.

    • OPERATIONS PRACTICEOptionalOPTIONAL
      Workloads and scaling

      StatefulSets, database operators, scheduling, resource management, HPA, VPA, KEDA

      You examine stateful workloads with StatefulSets and use database operators. Through resource settings and scheduling rules, you control Pod placement. You configure autoscaling with HPA, VPA and KEDA.

      Afterwards, you can examine StatefulSets, use database operators, control pod placement and configure autoscaling with HPA, VPA and KEDA.

      In this optional extension, you learn more about applications with persistent data, Pod placement, resource allocation and automatic scaling.

      4 learning moves
      1. Understand stateful workloads

        Using a database running as a StatefulSet, you examine why stable pod identities and persistent storage belong together.

      2. Use database operators

        You set up database operators and consider their advantages and disadvantages to assess their role in database operations.

      3. Control resources and placement

        With resource requests and scheduling rules, you control which nodes pods can run on and observe their placement.

      4. Distinguish scaling approaches

        You configure HPA, VPA and KEDA, distinguishing pod counts, resource adjustments and events as a basis for scaling.

    • OPERATIONS PRACTICEOptionalOPTIONAL
      Networking, access and operations

      Ingress and Gateway API overview, service mesh overview, network policies, RBAC, monitoring, logging

      You place Ingress, Gateway API and service mesh in context and practise RBAC and network policies. With Prometheus and Grafana, you set up basic monitoring; with Loki, you set up logging. Gateway API migration and controller portability are outside the practical scope.

      Afterwards, you can assess networking approaches, restrict API access and communication, and set up basic monitoring and logging for Kubernetes.

      You examine networking options, practise access controls and set up basic monitoring and logging.

      4 learning moves
      1. Place routing and service mesh in context

        You compare the roles of Ingress, Gateway API and service mesh to understand their areas of use and limitations.

      2. Restrict API access and communication

        With RBAC, you restrict API actions and with network policies, communication, treating these as separate protection tasks.

      3. Collect and display metrics

        You set up Prometheus and Grafana through operators to collect cluster metrics and make them visible in dashboards.

      4. Centralise logs and configure alerts

        With Loki, you centralise cluster logs and add basic alerts to bring together indications of operational problems.

Core route

Each number represents one workshop included in the totals, which may cover several skills.

  1. Workshop step 1 of 4:

    Kubernetes basics

    Practical foundations for later role responsibilities and certification goals involving hands-on exams.

    • KUBERNETES BASICSCore stepSelf-declaredCORE
      Kubernetes basics

      Architecture, pods, deployments, deployment strategies, services, namespaces, CoreDNS, storage and CSI, ConfigMaps, secrets, kubectl

      You deploy and expose applications with Kubernetes, then configure and inspect them using kubectl, the Kubernetes command-line tool. You also set up basic persistent storage for applications.

      Afterwards, you can deploy applications in Kubernetes, make them reachable, supply configuration and persistent storage, and inspect them with kubectl.

      You learn to run an application on Kubernetes using Pods, Deployments and Services, inspect its state with kubectl and make changes.

      5 learning moves
      1. Understand architecture and pods

        You trace how the control plane, nodes and pods work together and use kubectl to inspect the state of your first pods.

      2. Deploy and update applications

        With deployments, you deploy applications and compare update strategies to assess their risks.

      3. Access and name resolution

        Services make pods reachable while you organise resources with namespaces and check name resolution with CoreDNS.

      4. Separate configuration from images

        Through ConfigMaps and Secrets, you supply configuration and sensitive values to pods so they remain separate from the image.

      5. Check persistent storage

        You attach volumes to pods, explain the roles of CSI and StorageClasses, and check whether data survives a pod restart.

      • Prerequisite: Working with Helm or Kustomize requires Kubernetes basics: Deployments, Services and simple YAML manifests.
  2. Workshop step 2 of 4:

    Operations practice

    You deepen workload practice, scaling, access and network rules, operational signals and configuration per environment.

    • OPERATIONS PRACTICECore stepSelf-declaredCHOICE
      Manage manifests

      Environment configuration, reuse, Helm or Kustomize

      You structure Kubernetes configurations for different environments. Choose Helm with charts and values or Kustomize with bases, overlays and patches. Your choice covers work with one tool, not both tools.

      Afterwards, you can use Helm or Kustomize to structure reusable Kubernetes configurations, adapt them for different environments and check the generated resources.

      Helm or Kustomize remains required in the core route: you write and version charts or overlays, reusable configurations for test and production. The later Argo CD or Flux workshops show how the tools deploy these configurations.

      4 learning moves
      1. Identify shared and differing settings

        You distinguish shared configuration from environment differences to identify reusable parts of your manifests.

      2. Build a reusable structure

        Using Helm or Kustomize, you structure shared resources so that environment variants build on the same foundation.

      3. Implement environment variants

        In your chosen tool, you make targeted adjustments for staging and production so that each environment receives its own configuration.

      4. Check generated resources

        You inspect generated resources to check how shared settings and adjustments interact, helping you identify configuration errors.

      Choose 1 of 2

      Helm packages, versions and releases software as charts; Kustomize adapts existing manifests per environment with template-free overlays.

      • Recommended next step: Charts or overlays provide a basis for the configuration reconciled by Argo CD or Flux.
  3. Workshop step 3 of 4:

    Role focus

    This learning path follows a role path, which optional topics deepen.

    • ROLE PATHCore stepROLE PATH
      GitOps

      Deliver changes through Git: from the recorded and reviewed revision to the running application.

      You connect the steps from a change in Git to the running application, with Git recording which version should run with which configuration.

    • ROLE COMPETENCYCore stepSelf-declaredROLE PATH
      Automate container image builds

      GitLab CI/CD: build, test and deliver, pipelines, runners for job execution, build outputs, security checks, test environments

      You create GitLab pipelines, control jobs, and build and publish container images. To these pipelines, you add scans and deployment steps and investigate pipeline failures. Git fundamentals are required.

      Afterwards, you can create GitLab pipelines to build, scan and publish container images, integrate test environments and diagnose job failures.

      With GitLab CI/CD, you automatically build, scan and publish container images on Git changes. Workflow phases, tasks, execution services (runners), image builds and scans, and target environments transfer to other CI systems; you can take Argo CD or Flux without this course.

      4 learning moves
      1. Match jobs to runners

        You structure a GitLab pipeline into jobs and stages and assign runners to make the sequence and execution location clear.

      2. Publish images and build outputs

        You build container images for the registry and pass build outputs as artifacts so that subsequent jobs can use them.

      3. Integrate checks and test environments

        With scan jobs and deployments to test environments, you check images and applications within the delivery workflow.

      4. Diagnose pipeline failures

        Syntax checks and job logs help you distinguish configuration errors from runner, image access and permission problems.

      4 more relationships
      • Recommended next step: With GitLab, you automate building and checking container images as a basis for subsequent delivery through Git.
      • Recommended next step: A pipeline or Flux image automation writes the new image version's reference to Git; Argo CD or Flux deploys the application from that Git revision.
      • Recommended next step: If you lack CI experience, you can build it in GitLab before working on policy tests. The policy workshops are not limited to GitLab.
      • Optional further study: For build and test pipelines running directly inside Kubernetes, you can request a Tekton introduction; this execution alternative does not replace GitLab CI/CD competency.
  4. Workshop step 4 of 4:
    • ROLE COMPETENCYCore stepSelf-declaredROLE PATH
      Automate delivery

      Reconciliation, deviations, environments, secrets without plaintext in Git, Argo CD or Flux

      With Argo CD or Flux, you deploy applications from Git and reconcile the managed Kubernetes resources with their desired state. You detect and correct deviations from the configuration in Git.

      Afterwards, you can deploy applications from Git with Argo CD or Flux, separate environments, integrate secrets without plaintext in Git and correct drift.

      Choose Argo CD or Flux: Git defines what should run in the cluster (declarative). The pipeline writes the new image reference to Git for Argo CD; Image Automation does this for Flux. You detect and correct drift, such as manual changes in the cluster that differ from Git.

      4 learning moves
      1. Understand Git as the desired state

        You follow how Argo CD or Flux retrieves configuration from Git and reconciles managed resources with that desired state.

      2. Separate configuration by environment

        Shared base configuration and targeted adjustments separate differences between environments without copying every manifest.

      3. Deliver secrets without plaintext

        You compare encryption in the repository with fetching external secrets so that confidential values are not stored as plaintext in Git.

      4. Investigate drift and failures

        Using Git configuration and controller feedback, you investigate failed reconciliations and correct deviations.

      Choose 1 of 2

      Use your team's tool; Argo CD for canary and blue-green with Argo Rollouts and a browser overview, Flux for automatic image updates in Git.

      • Prerequisite: Deployment from Git and reconciliation with the cluster provide the basis for traceable software delivery.
      3 more relationships
      • Optional further study: If you use Argo CD, Kargo adds controlled promotion of versions between environments; this extension does not build on Flux.
      • Optional further study: CGOA adds tool-neutral GitOps principles to Argo CD or Flux; CAPA requires knowledge of the whole Argo project, which the Argo CD workshop does not cover and Flux does not teach.
      • Optional further study: A central secrets store adds storage, rotation and issuance to GitOps synchronisation or encryption; you can request introductions to Vault and OpenBao.

Possible goals

This path builds the technical foundation for these goals.

  • GoalTraceable software deliveryYou configure application delivery to apply only reviewed Git changes and keep them traceable. You make deviations of the managed resources from Git visible and correct them.
  • GoalConfigure and interpret system signalsYou configure metrics, logs and alerting and interpret these operational signals. This extension goes beyond the GitOps core; the monitoring workshop requires Kubernetes cluster administration experience.

Further study

Optional further study; excluded from the workshop count, days and price.

Show 7 skills
  • Role focus

    This learning path follows a role path, which optional topics deepen.

    Extends the path but is not a mandatory step.

    • DEPTH COMPETENCYOptionalON REQUEST
      Pipelines with Tekton

      Tekton, automated builds and tests, Kubernetes resources, tasks, pipelines

      Tekton runs automated build and test pipelines as Kubernetes resources inside the cluster, providing an alternative way to run continuous integration (CI). You can request an introduction to Tekton; it does not replace the GitLab CI/CD competency.

      Tekton is a next step for teams that want to run their CI pipelines inside Kubernetes instead of using GitLab CI. The introduction adds this focus and does not replace the route’s GitLab CI/CD station.

    • DEPTH COMPETENCYOptionalCHOICE
      Policy as code

      Admission control, validation, mutation, exceptions, policy tests, CI

      You develop and test Kubernetes policies with Kyverno or OPA Gatekeeper and Rego. This includes examining validation, mutation and exception handling and integrating tests into CI. Git and CI fundamentals are required; the feature scope depends on the selected tool.

      Afterwards, you can develop Kubernetes policies with the selected tool, test them in CI and prepare their enforcement with narrowly scoped exceptions.

      After the pipeline step, optionally choose Kyverno or OPA Gatekeeper if your GitOps team needs to test policies in pipelines and at cluster admission. The bookable workshops require Kubernetes practice, Git branches and continuous integration experience; this extension stays outside all totals. KCA preparation on request concerns Kyverno only.

      4 learning moves
      1. Understand admission and resource checks

        You distinguish checks on new API requests from checks on existing resources to understand the reach of a policy.

      2. Design validation and mutation

        With the selected tool, you define validation rules and limited mutations to check requirements or supply missing values.

      3. Test rules and integrate CI checks

        Allowed, violating and excluded resources become CI test cases so unintended policy behaviour is detected before deployment.

      4. Scope exceptions and enforcement

        Narrowly scoped exceptions and reviewed check results help you make an informed transition from observing violations to blocking them.

      Choose 1 of 2

      Gatekeeper with Open Policy Agent (OPA) for existing use or a deliberate Rego choice, otherwise Kyverno for YAML policies; only Kyverno aligns with requestable Kyverno Certified Associate preparation.

    • DEPTH COMPETENCYOptionalON REQUEST
      Promote versions across environments

      Kargo, version promotion, development, staging, production, Argo CD

      Kargo controls the promotion of versions from development through staging to production. This extension builds on Argo CD, not Flux; you can request an introduction to Kargo.

      If your team chose Argo CD, Kargo builds on it: the focus is controlled promotion of versions from test through staging to production. This next step is not intended for teams using Flux.

    • DEPTH COMPETENCYOptionalON REQUEST
      Manage secrets centrally

      HashiCorp Vault, OpenBao, central storage, rotation, dynamic issuance

      HashiCorp Vault and OpenBao centrally store, rotate and generate secrets such as passwords, complementing Kubernetes Secrets, synchronisation via External Secrets Operator and encryption with SOPS or Sealed Secrets. OpenBao is an open-source fork of Vault. You can request introductions to Vault and OpenBao.

      If your team wants to manage credentials centrally, choose HashiCorp Vault or OpenBao as a next step after the secrets approaches in the Argo CD or Flux workshop. The External Secrets Operator covered there can retrieve credentials from such a central store.

      Choose Vault if already operated or licensed by your organisation, OpenBao if an open-source licence or community governance is required.

    • DEPTH COMPETENCYOptionalON REQUEST
      GitOps and Argo (CGOA, CAPA)

      GitOps principles, reconciliation, Argo CD, Argo Rollouts, Argo Workflows, Argo Events

      Certified GitOps Associate (CGOA) assesses tool-neutral principles and fits after Argo CD or Flux. Certified Argo Project Associate (CAPA) covers the Argo project including Workflows and Events, taught by neither the Argo CD nor the Flux workshop. Preparations are on request; book and pay for exams separately with the Linux Foundation.

      Preparation for Certified GitOps Associate (CGOA) deepens tool-neutral GitOps principles after Argo CD or Flux. Certified Argo Project Associate (CAPA) suits Argo CD teams: the exam covers Argo Workflows, Argo CD, Argo Rollouts and Argo Events. The Argo CD workshop covers only Argo CD and Argo Rollouts; the bookable workshops do not systematically prepare you for exams. Preparation is on request; book and pay for exams separately with the Linux Foundation.

    • SPECIALIZATIONOptionalDEPTH
      Observability

      Configure metrics, logs and alert rules, then interpret the operational signals they capture.

      This optional extension goes beyond the software delivery focus of this path and is for teams that also operate their applications and monitor their behaviour.

    • DEPTH COMPETENCYOptionalDEPTH
      Metrics, logs and alerting

      Prometheus, Grafana, Loki, dashboards, alerting

      With Prometheus, Grafana and Loki, you collect and analyse metrics and logs from Kubernetes. You create dashboards, configure alerts and define measurable service objectives. During incidents, you combine signals and also investigate data gaps and resource problems in the monitoring stack.

      Afterwards, you can analyse Kubernetes metrics and logs with Prometheus, Grafana and Loki, configure dashboards and alerts and investigate incidents systematically.

      The advanced monitoring course with Prometheus, Grafana and Loki requires Kubernetes administration experience, Linux command line skills and YAML; Kubernetes Advanced alone is not enough. The Argo CD or Flux workshops already cover notifications and basic monitoring of these tools.

      4 learning moves
      1. Collect metrics and logs

        You collect metrics with Prometheus and logs with Loki to understand measurements and events as different sources of information.

      2. Query and combine data

        With PromQL and LogQL, you select relevant data and combine it in Grafana dashboards to examine anomalies in context.

      3. Define alerts and service objectives

        You formulate measurable service objectives and configure alert rules and recipients so that critical conditions become visible.

      4. Investigate incidents using signals

        You trace incidents from alerts through dashboards to logs, also checking data gaps and resource problems in the monitoring stack.

      2 more relationships
      • Optional further study: The observability specialization extends the path with this competency.
      • Optional further study: This extension covers configuring and interpreting metrics, logs and alerting; cluster administration experience is required.

Which workshops make up the GitOps and Continuous Delivery example route?

The example route includes DW2, DW14, choose between DW9 or DW22 and choose between DW27 or DW28. It covers these skills: Kubernetes basics, Manage manifests, Automate container image builds and Automate delivery.

EXAMPLE ROUTE (ROLE PATH: DELIVERY)

GitOps and Continuous Delivery

For development, DevOps and platform teams: practise traceable delivery through Git. Kubernetes is followed by Helm or Kustomize, GitLab CI/CD and Argo CD or Flux; preparation and advanced monitoring are optional.

Route scope
4
Training days
10–11
List price basis, per person, excl. VAT
€5,550–€6,105

Included in the totals: DW2, DW9 or DW22 (one workshop), DW14 and DW27 or DW28 (one workshop). Additional workshops are excluded.

Workshops in this example route

Each workshop shows its role, skills covered and planning details.

4 workshops, recommended technical sequence

Preparation

Preparation if needed

Excluded from the workshop count, days and price.
  • Git and collaboration

    If needed: 1 of 2

    GitLab CI/CD requires Git fundamentals; Argo CD and Flux also require collaboration through branches and pull requests. If you lack these skills, choose Git or Git with GitLab; with existing experience, the preparation course is optional.

  • Docker fundamentals

    If needed: 1 of 2

    • DW1 Introduction to Docker

      This optional preparation introduces container images and YAML. Container experience helps with the Kubernetes introduction but is not required; Helm and Flux expect YAML knowledge, while Kustomize also expects practice with simple Kubernetes manifests.

      2 days, €1,110 excluding VAT

      Content & dates for Introduction to Docker (DW1)
    • DW8 Introduction to Podman

      Choose Podman instead of Docker as optional preparation if your team already works with Podman or containers without root privileges.

      3 days, €1,665 excluding VAT

      Content & dates for Introduction to Podman (DW8)
  • DW3 Advanced Kubernetes

    In this optional extension, you learn more about applications with persistent data, Pod placement, resource allocation and automatic scaling.

    2 days, €1,110 excluding VAT

Core route

  1. STARTING POINT (KUBERNETES BASICS)

    DW2 Introduction to Kubernetes

    You learn to run an application on Kubernetes using Pods, Deployments and Services, inspect its state with kubectl and make changes.

    SKILLS COVERED

    Architecture, pods, deployments, deployment strategies, services, namespaces, CoreDNS, storage and CSI, ConfigMaps, secrets, kubectl

    3 days, €1,665 excluding VAT

    Choose a date

  2. CHOICE STEP

    Manage manifests

    Choose 1 of 2

    Helm or Kustomize remains required in the core route: you write and version charts or overlays, reusable configurations for test and production. The later Argo CD or Flux workshops show how the tools deploy these configurations.

    SKILLS COVERED

    Environment configuration, reuse, Helm or Kustomize

  3. ROLE COMPETENCY

    DW14 Introduction to GitLab CI/CD

    With GitLab CI/CD, you automatically build, scan and publish container images on Git changes. Workflow phases, tasks, execution services (runners), image builds and scans, and target environments transfer to other CI systems; you can take Argo CD or Flux without this course.

    SKILLS COVERED

    GitLab CI/CD: build, test and deliver, pipelines, runners for job execution, build outputs, security checks, test environments

    2 days, €1,110 excluding VAT

    Choose a date

  4. CHOICE STEP

    Automate delivery

    Choose 1 of 2

    Choose Argo CD or Flux: Git defines what should run in the cluster (declarative). The pipeline writes the new image reference to Git for Argo CD; Image Automation does this for Flux. You detect and correct drift, such as manual changes in the cluster that differ from Git.

    SKILLS COVERED

    Reconciliation, deviations, environments, secrets without plaintext in Git, Argo CD or Flux

Further study

Optional further study

Excluded from the workshop count, days and price.
  • Policy as code

    If needed: 1 of 2

    After the pipeline step, optionally choose Kyverno or OPA Gatekeeper if your GitOps team needs to test policies in pipelines and at cluster admission. The bookable workshops require Kubernetes practice, Git branches and continuous integration experience; this extension stays outside all totals. KCA preparation on request concerns Kyverno only.

  • DW10 Kubernetes Monitoring and Observability

    The advanced monitoring course with Prometheus, Grafana and Loki requires Kubernetes administration experience, Linux command line skills and YAML; Kubernetes Advanced alone is not enough. The Argo CD or Flux workshops already cover notifications and basic monitoring of these tools.

Why is this route structured this way?

The route follows learning questions: each station builds on the previous one. Here, we explain why the transitions make sense.

Recommended learning sequence, not formal exam eligibility.

The route principle

Each station answers a different learning question.

  1. Understand Kubernetes

    How does an application run in the cluster?

  2. Write and maintain manifests

    How do you write and maintain manifests for different environments?

  3. Automate container image builds

    How does GitLab CI/CD build and scan versioned container images?

  4. Automate delivery

    How does a checked image get from the pipeline via Git to the cluster?

The learning rationale in detail

Brief explanations clarify the transitions without repeating the route.

  1. DW2 then DW9 / DW22: Competence prerequisite

    Why do Kubernetes fundamentals precede Helm or Kustomize?

    Helm and Kustomize structure Kubernetes manifests: you need to understand the resources they describe, work with kubectl and use the terminal confidently. Helm requires YAML syntax knowledge; Kustomize also requires practice writing simple YAML manifests. Equivalent experience is sufficient; the fundamentals workshop is not a formal admission requirement.

  2. DW9 / DW22 then DW14: Recommended order

    Why do pipelines follow Helm or Kustomize?

    After manifests, you learn how GitLab CI/CD builds, scans and publishes their images. Later, the pipeline updates the configuration in Git for Argo CD; Image Automation does this for Flux. The beginner course needs Git fundamentals and Linux command line skills, neither Kubernetes nor Helm or Kustomize: you can take the stations in reverse order or split them between team members learning in parallel.

  3. DW14 then DW27 / DW28: Recommended combination

    How does the pipeline hand new images over to Argo CD or Flux?

    CI publishes images but does not change the cluster: in the Argo CD course, a prepared GitLab pipeline writes the image reference to Git; with Flux, Image Automation makes the commit. Afterwards, the tools reconcile the cluster with Git. You need solid Kubernetes skills and Git basics, plus Linux command line skills for Argo CD or YAML syntax for Flux; a CI course is not required, and another CI system is fine.

What is fixed, what is flexible?

The status shows which core stations contribute to the totals and where prior knowledge or learning goals allow flexibility. Optional additions count only when selected.

  • Included in this route

    This station is a fixed part of your route with a designated workshop.

  • Choice of equivalent workshops

    Here, choose a workshop to match your team’s tool: the options develop the same competence with different tools and areas of focus.

  • Equivalent alternative

    Podman is an alternative to Docker here if your team already uses Podman or containers without root privileges; both provide optional container preparation.

  • Optional

    The core total counts only the core route. If the finder shows missing Linux or Git skills, the personal total also counts that preparation; container preparation and further study stay outside every total.

  • On request

    Workshops and exam preparation on request: no public dates or prices, excluded from totals; scope, language, format and price agreed after a discovery call. Requests are not bookings or exam registrations; book and pay for exams separately with the Linux Foundation.

Sources for this route

Agenda · Reference · Practice lab · Exam body · checked on

View methodology and sources

How does the roadmap lead to practical experience?

The roadmap sets out competency goals and sequence; the workshop agenda shows the content. In practical workshops, you apply that knowledge in the browser-based Dojo. The certificate of attendance documents workshop participation and is not a certification.

From learning goal to application

4 clear steps

  1. Competency goal

    The learning goal describes a concrete task.

  2. Workshop agenda

    Content and sequence are clear.

  3. Dojo practice

    In practical workshops, you apply knowledge in Dojo exercises.

  4. Application & context

    The certificate of attendance documents participation, not certification.

What “covered” means and how we substantiate it

4 criteria: directly supported

  • Visible

    Content is transparent

    “Covered” is an editorial classification of the visible workshop agenda, not proof of assessed competence.

  • Structured

    The sequence is explained

    The agenda arranges topics in a clear learning sequence.

  • Applied

    Knowledge is applied in practice

    In practical workshops, you apply knowledge through exercises in the browser-based Dojo.

  • Distinguished

    Records remain separate

    The certificate of attendance and proof of passing an exam remain separate.

Reviewed by the expert team at DevNinjas GmbH

Sources checked on

Which Kubernetes learning path fits your goal?

Compare related paths by their skills and technical focus. Check each workshop’s prerequisites before booking.

For administrators and operations teams with Linux experience: you practise building and maintaining Kubernetes clusters and fixing faults. The path prepares you for the Certified Kubernetes Administrator (CKA) exam, booked separately with the Linux Foundation. Optional depth follows your team responsibilities.

  • ALTERNATIVE ROLE PATH
  • Core route 12 days
  • 4 workshops
  • ROLE PATH: OPERATIONS

A good fit if you want to build on the same foundations with a different technical focus.

Core routes compared

In both core routes

  • Kubernetes basicsStart

Only in this core route

  • Workloads and scaling
  • Networking, access and operations
  • Manage software with Helm
  • Cluster operations and troubleshooting

Frequently asked questions about the Kubernetes learning path

A learning path is a recommended sequence, with no obligation to book it all. The right workshops depend on your container knowledge, target role and practical experience. The displayed duration and price refer to the core route.

Do I need Helm experience for Argo CD or Flux?

The Argo CD and Flux workshops require no prior Helm or Kustomize knowledge; you learn the relevant aspects during training.

Argo CD training and Flux CD training require Kubernetes and Git practice. The learning-path overview explains how to book individual preparation steps. For a comparison of Argo CD and Flux, see the GitOps overview.

Can I join the GitLab CI/CD workshop without GitLab experience?

The GitLab CI/CD workshop requires no GitLab experience, but you need Git fundamentals. You should be able to work with commits, branches and merges, use a text editor and run basic Linux commands.

The GitLab CI/CD introduction introduces the platform and CI/CD; previous CI/CD or Docker knowledge is not required.

How deeply does the GitOps path cover canary and blue-green deployments?

The Argo CD workshop includes practical canary and blue-green exercises in the cluster; the Flux workshop covers progressive delivery as an outlook with Flagger.

Argo CD training has a dedicated practical block using Argo Rollouts. Flux CD training uses an example application for the Flagger outlook.

Vincent Sturm, Key Account Manager

Discuss your team’s learning path with Vincent

Discuss goals, roles, timing, format and suitable workshop sequences with Vincent. You can explore technical questions with our trainers afterwards if needed.
View public workshop dates