Module 11 Exercises: Automating Everything

Module 11 Exercises: Automating Everything

Build the machine. Practice creating dynamic Helm charts, auditing your CI/CD pipelines, and implementing GitOps syncing.

Module 11 Exercises: Automating Everything

In Module 11, we moved from manually running commands to building automated systems. You learned about Helm, GitHub Actions, and GitOps. These exercises will guide you through the transition from "Static YAML" to "Dynamic Infrastructure."


Exercise 1: The "Environment-Aware" Chart

  1. Creation: Use helm create my-app.
  2. Task: Modify the values.yaml to include a variable environment: development.
  3. Templating: Modify the templates/deployment.yaml to include a label env: {{ .Values.environment }}.
  4. Verification:
    • Run helm template . and verify the label is set to development.
    • Run helm template . --set environment=production and verify the label changes.
  5. Challenge: Add a condition that ONLY creates a ServiceAccount if serviceAccount.create is true.

Exercise 2: Auditing the CI/CD Pipeline

  1. Scenario: You have a GitHub Action that pushes an image to ECR and runs helm upgrade.
  2. Question: If the docker push step succeeds but the helm upgrade step fails because of a typo in your YAML, what state is the cluster in? Does it still run the old code or the new code?
  3. Security Check: You accidentally committed your kubeconfig to the public repo. What is the immediate first step you must take? How can you prevent this using GitHub Environments?

Exercise 3: Defining an ArgoCD Application

  1. Task: Write the YAML for an ArgoCD Application that:
    • Watches a Git repo at https://github.com/example/ai-charts.
    • Watches the staging branch.
    • Deploys to the ai-staging namespace.
    • Has Self-Healing enabled.
  2. Simulation: If you manually delete a Service in the ai-staging namespace using kubectl delete, what will happen next? How long will it take for the service to return?

Exercise 4: Canary Strategy Design

  1. Scenario: You are deploying a new version of an AI agent that uses a much more expensive LLM (GPT-4 vs GPT-3.5).
  2. Task: Design a Canary strategy in text.
    • What is your initial traffic weight?
    • How long do you pause at each step?
    • What business metrics would you monitor in Prometheus to decide if the rollout is "Successful"? (Think about cost and performance).

Solutions (Self-Check)

Exercise 1 Answer:

  • You should see env: development and env: production respectively.
  • The condition uses {{- if .Values.serviceAccount.create }}.

Exercise 2 Solution:

  • The cluster runs the Old Code. K8s hasn't even started the rollout yet because the API request failed.
  • Security: You must immediately REVCKE the credentials and delete the repo history. Using "Repository Secrets" or OIDC (OpenID Connect) for AWS/Azure is the safest way to avoid commits of keys.

Exercise 3 Hint:

The service will return within ~3 minutes (the default poll interval), or instantly if you have Webhooks configured between GitHub and ArgoCD.

Exercise 4 Logic:

A good strategy: 5% initial weight -> 1 hour pause -> 20% -> 4 hour pause -> 100%. Metrics to watch:

  1. Cost per User Session (Did our bill skyrocket?).
  2. P99 Response Latency (Is the expensive model slowing everyone down?).
  3. User Conversion/Accuracy (Is the model actually 5x better as promised?).

Summary of Module 11

Congratulations! You have automated the most tedious parts of DevOps.

  • You can template complex apps with Helm.
  • You can build secure pipelines with GitHub Actions.
  • You can ensure consistency across environments with ArgoCD.
  • You can perform safe, high-stakes releases using Canary patterns.

In Module 12: Advanced Kubernetes Concepts, we will learn how to extend the cluster's very soul by building our own Custom Resources and Operators.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn