diff --git a/slides/exercises/healthchecks-brief.md b/slides/exercises/healthchecks-brief.md
new file mode 100644
index 00000000..2c72463e
--- /dev/null
+++ b/slides/exercises/healthchecks-brief.md
@@ -0,0 +1,11 @@
+## Exercise - Healthchecks
+
+- Add readiness and liveness probes to a web service
+
+  (we will use the `rng` service in the dockercoins app)
+
+- Observe the correct behavior of the readiness probe
+
+  (when deploying e.g. an invalid image)
+
+- Observe the behavior of the liveness probe
diff --git a/slides/exercises/healthchecks-details.md b/slides/exercises/healthchecks-details.md
new file mode 100644
index 00000000..cced2baa
--- /dev/null
+++ b/slides/exercises/healthchecks-details.md
@@ -0,0 +1,37 @@
+# Exercise - Healthchecks
+
+- We want to add healthchecks to the `rng` service in dockercoins
+
+- First, deploy a new copy of dockercoins
+
+- Then, add a readiness probe on the `rng` service
+
+  (using a simple HTTP check on the `/` route of the service)
+
+- Check what happens when deploying an invalid image (e.g. `alpine`)
+
+- Then, add a liveness probe on the `rng` service
+
+  (with the same parameters)
+
+- Scale up the `worker` service (to 15+ workers) and observe
+
+- What happens, and how can we improve the situation?
+
+---
+
+## Goal
+
+- *Before* adding the readiness probe:
+
+  updating the image of the `rng` service with `alpine` should break it
+
+- *After* adding the readiness probe:
+
+  updating the image of the `rng` service with `alpine` shouldn't break it
+
+- When adding the liveness probe, nothing special should happen
+
+- Scaling the `worker` service will then cause disruptions
+
+- The final goal is to understand why, and how to fix it
diff --git a/slides/exercises/helm-brief.md b/slides/exercises/helm-brief.md
new file mode 100644
index 00000000..b650c190
--- /dev/null
+++ b/slides/exercises/helm-brief.md
@@ -0,0 +1,9 @@
+## Exercise - Helm Charts
+
+- Create a Helm chart to deploy a generic microservice
+
+- Deploy dockercoins by instanciating that chart multiple times
+
+- Bonus: create a "meta" Helm chart to install the 5 components of dockercoins
+
+- Bonus: use an external chart for the redis component
diff --git a/slides/exercises/helm-details.md b/slides/exercises/helm-details.md
new file mode 100644
index 00000000..076177a3
--- /dev/null
+++ b/slides/exercises/helm-details.md
@@ -0,0 +1,82 @@
+# Exercise - Helm Charts
+
+- We want to deploy dockercoins with a Helm chart
+
+- We want to have a "generic chart" and instantiate it 5 times
+
+  (once for each service)
+
+- We will pass values to the chart to customize it for each component
+
+  (to indicate which image to use, which ports to expose, etc.)
+
+- We'll use `helm create` as a starting point for our generic chart
+
+---
+
+
+  (using `helm create` to get a generic chart and tweaking that chart)
+
+- Deploy dockercoins by instanciating that chart multiple times
+
+  (one time per service, so 5 times total)
+
+- Create a "meta" Helm chart to install the 5 components of dockercoins
+
+  (using chart dependencies and aliases)
+
+- Bonus: use Bitnami's redis chart for the dockercoins redis component
+
+---
+
+## Goal
+
+- Have a directory with the generic chart
+
+  (e.g. `generic-chart`)
+
+- Have 5 value files
+
+  (e.g. `hasher.yml`, `redis.yml`, `rng.yml`, `webui.yml`, `worker.yml`)
+
+- Be able to install dockercoins by running 5 times:
+
+  `helm install X ./generic-chart --values=X.yml`
+
+---
+
+## Hints
+
+- There are many little things to tweak in the generic chart
+
+  (service names, port numbers, healthchecks...)
+
+- Check the training slides if you need a refresher!
+
+---
+
+## Bonus 1
+
+- Create a "meta chart" or "umbrella chart" to install all 5 components
+
+  (so that dockercoins can be installed with a single `helm install` command)
+
+- This will require expressing dependencies, and using the `alias` keyword
+
+---
+
+## Bonus 2
+
+- Replace the `redis` component with an external chart
+
+  (e.g. Bitnami's redis chart)
+
+- This will require to pass extra values to that chart
+
+  (to disable persistence, replication, password authentication)
+
+- This will also require to either:
+
+  - import the chart and tweak it to change the service name
+
+  - add an ExternalName service pointing to the new redis component
diff --git a/slides/exercises/ingress-brief.md b/slides/exercises/ingress-brief.md
new file mode 100644
index 00000000..55f7e220
--- /dev/null
+++ b/slides/exercises/ingress-brief.md
@@ -0,0 +1,9 @@
+## Exercise - Ingress
+
+- Add an ingress controller to a Kubernetes cluster
+
+- Create an ingress resource for a web app on that cluster
+
+- Challenge: accessing/exposing port 80
+
+  (different methods depending on how the cluster was deployed)
diff --git a/slides/exercises/ingress-details.md b/slides/exercises/ingress-details.md
new file mode 100644
index 00000000..8da32fbc
--- /dev/null
+++ b/slides/exercises/ingress-details.md
@@ -0,0 +1,47 @@
+# Exercise - Ingress
+
+- We want to expose a web app through an ingress controller
+
+- This will require:
+
+  - the web app itself (dockercoins, NGINX, whatever we want)
+
+  - an ingress controller (we suggest Traefik)
+
+  - a domain name (`use \*.nip.io` or `\*.localdev.me`)
+
+  - an ingress resource
+
+---
+
+## Goal
+
+- We want to be able to access the web app using an URL like:
+
+  http://webapp.localdev.me
+
+  *or*
+
+  http://webapp.A.B.C.D.nip.io
+
+  (where A.B.C.D is the IP address of one of our nodes)
+
+---
+
+## Hints
+
+- Traefik can be installed with Helm
+
+  (it can be found on the Artifact Hub)
+
+- If using Kubernetes 1.22+, make sure to use Traefik 2.5+
+
+- If our cluster supports LoadBalancer Services: easy
+
+  (nothing special to do)
+
+- For local clusters, things can be more difficult; two options:
+
+  - map localhost:80 to e.g. a NodePort service, and use `\*.localdev.me`
+
+  - use hostNetwork, or ExternalIP, and use `\*.nip.io`
diff --git a/slides/exercises/k8sfundamentals-brief.md b/slides/exercises/k8sfundamentals-brief.md
new file mode 100644
index 00000000..63e1af7d
--- /dev/null
+++ b/slides/exercises/k8sfundamentals-brief.md
@@ -0,0 +1,7 @@
+## Exercise - Deploy Dockercoins
+
+- Deploy the dockercoins application to our Kubernetes cluster
+
+- Connect components together
+
+- Expose the web UI and open it in a web browser to check that it works
diff --git a/slides/exercises/k8sfundamentals-details.md b/slides/exercises/k8sfundamentals-details.md
new file mode 100644
index 00000000..2e2faf6e
--- /dev/null
+++ b/slides/exercises/k8sfundamentals-details.md
@@ -0,0 +1,47 @@
+# Exercise - Deploy Dockercoins
+
+- We want to deploy the dockercoins app
+
+- There are 5 components in the app:
+
+  hasher, redis, rng, webui, worker
+
+- We'll use one Deployment for each component
+
+  (see next slide for the images to use)
+
+- We'll connect them with Services
+
+- We'll check that we can access the web UI in a browser
+
+---
+
+## Images
+
+- hasher → `dockercoins/hasher:v0.1`
+
+- redis → `rng`
+
+- rng → `dockercoins/rng:v0.1`
+
+- webui → `dockercoins/webui:v0.1`
+
+- worker → `dockercoins/worker:v0.1`
+
+---
+
+## Goal
+
+- We should be able to see the web UI in our browser
+
+  (with the graph showing approximatiely 3-4 hashes/second)
+
+---
+
+## Hints
+
+- Make sure to expose services with the right ports
+
+  (check the logs of the worker; they indicate the port numbers)
+
+- The web UI can be exposed with a NodePort Service
diff --git a/slides/exercises/localcluster-brief.md b/slides/exercises/localcluster-brief.md
new file mode 100644
index 00000000..43332a0a
--- /dev/null
+++ b/slides/exercises/localcluster-brief.md
@@ -0,0 +1,9 @@
+## Exercise - Local Cluster
+
+- Deploy a local Kubernetes cluster if you don't already have one
+
+- Deploy dockercoins on that cluster
+
+- Connect to the web UI in your browser
+
+- Scale up dockercoins
diff --git a/slides/exercises/localcluster-details.md b/slides/exercises/localcluster-details.md
new file mode 100644
index 00000000..00709ff4
--- /dev/null
+++ b/slides/exercises/localcluster-details.md
@@ -0,0 +1,43 @@
+# Exercise - Local Cluster
+
+- We want to have our own local Kubernetes cluster
+
+  (we can use Docker Desktop, KinD, minikube... anything will do!)
+
+- Then we want to run a copy of dockercoins on that cluster
+
+- We want to be able to connect to the web UI
+
+  (we can expose the port, or use port-forward, or whatever)
+
+---
+
+## Goal
+
+- Be able to see the dockercoins web UI running on our local cluster
+
+---
+
+## Hints
+
+- On a Mac or Windows machine:
+
+  the easiest solution is probably Docker Desktop
+
+- On a Linux machine:
+
+  the easiest solution is probably KinD or k3d
+
+- To connect to the web UI:
+
+  `kubectl port-forward` is probably the easiest solution
+
+---
+
+## Bonus
+
+- If you already have a local Kubernetes cluster:
+
+  try to run another one!
+
+- Try to use another method than `kubectl port-forward`