Before I began learning about MLOps, I tried to understand the technologies behind LLMs and how they work. In this article, I’ll share my understanding of machine learning, deep learning, and generative AI, along with their potential applications.

Table of Contents

• Artificial Intelligence (AI)

• Machine Learning (ML): The Foundation

• Deep Learning: Adding Complexity

• Generative AI: Write New

• Summary of Differences Between Machine Learning vs Deep Learning vs Generative AI

• Conclusion

Artificial Intelligence (AI)

Artificial Intelligence (AI) is a form of technology that lets machines solve problems in a way that is identical to how people do it. It helps businesses make better decisions on a large scale by helping them recognize images, create content, and make predictions based on data. Artificial intelligence includes machine learning, deep learning, and generative AI.

Machine Learning (ML): The Foundation

When we give computers many examples, they learn how to make their own decisions or guesses. It's like teaching a kid to tell the difference between animals. You show them a lot of pictures of cats and dogs and say things like "This is a cat" and "This is a dog." In the end, they learn to tell the difference between cats and dogs on their own. Machine learning is similar in that you give a computer a lot of data with examples, and it learns how to make predictions about new data.

How Does Machine Learning Work?

Machine Learning (ML) is the process of teaching computers to find patterns in data and make decisions or predictions without being instructed what to do. There are usually six main steps in this process:

Data Collection: Get many examples, like thousands of emails, photos, or sales records. The more training data you have, the more accurate your predictions will be.

Data Preparation: At this stage, you clean the data by getting rid of mistakes and adding missing labels.

Selecting Algorithm (Models): It's like choosing the right tools for the job. Models can find patterns in data or make predictions. You can find machine learning models for your data here.

Training Phase: After you pick the right model for your cleaned-up data, you teach it. This is like getting ready for a test.

Evaluation: Use the test data to assess the model's performance and see if it can make accurate predictions on unseen data.

Deployment: Put the trained model to work in the real world.

Training Phase: Teach the computer with 10,000 house sales with details like size (2,000 sq ft), number of bedrooms (3), and location (downtown). Cost: $300,000.

Learning: The algorithm finds patterns, such as the fact that bigger houses cost more and places in the city center cost more. More bedrooms make a house worth more.

Prediction: Think about a new house with 1,800 square feet, two bedrooms, and a location in the suburbs. It guesses a figure based on what it has learned.

Types of Machine Learning

1. Supervised Learning: Give algorithms labeled and defined training data to look for patterns. The sample data tells the algorithm what to do and what to expect as an output. For instance, millions of X-ray reports that say someone is healthy or sick would need to be tagged. Then, machine learning programs could use this training data to guess if a new X-ray shows signs of illness.

2. Unsupervised Learning: Algorithms that use unsupervised learning learn from data that doesn't have labels. The algorithm must find patterns in untagged data without outside help. For instance, finding groups of people on Facebook or Twitter who have similar interests.

3. Reinforcement Learning: This technique is a kind of machine learning in which an agent learns how to make choices by interacting with the world around it. The agent receives points for doing things right and loses points for doing things wrong. Its goal is to get as many points as possible. For instance, cars learn how to drive safely by making mistakes in simulations. They get rewards for staying in their lane, following traffic rules, and not hitting other cars.

Machine Learning—Real-World Examples

Email Spam Detection

You can show the computer thousands of emails that say "spam" or "not spam." It learns patterns, like how emails with "FREE MONEY" are usually spam. It can now automatically sort your inbox.

Photo Recognition

Give the computer millions of pictures with labels that say what's in them. It learns that apples are likely to be round and have stems. Your phone can now tell what things are in your pictures.

Movie Recommendations

Netflix keeps track of the movies you've seen and rated. It finds people who like the same things you do. It suggests movies that other people like.

Deep Learning: Adding Complexity

Deep learning is a type of artificial intelligence. It helps computers understand data like humans do. Deep learning can identify complex images, text, sound, and other data patterns to make accurate predictions. It uses artificial neural networks that work like the human brain. Neural networks are connected nodes that handle information.

How Does Deep Learning Work?

Artificial neural networks are used in deep learning to learn from data. These networks consist of interconnected layers of nodes. Each node learns a different thing about the data.

For instance, when you show a computer a picture of a cat, the picture goes through a lot of steps. The first layer looks for shapes and edges. The second layer puts these shapes together to make ears, eyes, and whiskers. The last layers say things like "This picture looks like a cat." Deep learning can make a lot of mistakes when learning, but it gets better and better after each piece of feedback.

Deep Learning—Real-World Examples

• Tesla Autopilot: Processes eight cameras simultaneously to navigate roads, recognize traffic signs, and avoid obstacles.

• Google's DeepMind: Detects over fifty eye diseases from retinal scans with 94% accuracy.

• ChatGPT: Helps with writing, coding, and problem-solving.

Generative AI: Write New

Generative AI is a subset of deep learning that makes new things, like stories, pictures, music, or code, instead of just looking at or sorting through things that are already there. Generative AI systems learn patterns from a lot of training data and then use those patterns to make new content.

Real-World Examples

• Chatbots help institutions give better customer service by making product suggestions and answering questions.

• Automatically generate technical documents from the source code.

• Auto-generate quizzes, practice problems, and explanations

Summary of Differences Between Machine Learning vs Deep Learning vs Generative AI

Conclusion

To sum it up, anyone who is keen to learn more about artificial intelligence needs to know the differences between machine learning, deep learning, and generative AI.

Machine learning is the basis for this because it lets computers learn from data and make predictions. Deep learning takes this a step further by using neural networks to process complicated data patterns in a way that is similar to how humans understand things.

Generative AI goes a step further by making new things, which shows how creative AI can be. As these technologies get better, they open up a lot of new opportunities in many fields, such as improving customer service, making medical diagnoses more accurate, and making new content. To maximize AI's benefits in your life, stay current on new developments.

Let’s pause for a moment: what are you trying to learn from your DevOps journey? Are you focusing on GitOps-style deployments, or promotions? This guide will help you tackle all of it – one step at a time.

As a DevOps engineer interested in creating a complete CI/CD pipeline, I wanted more than a basic "hello world" microservice. I was looking for a project where I could start from scratch – beginning with raw source code, writing my own Docker Compose and Kubernetes files, deploying locally, and then adding automation, environment promotion, and GitOps practices step by step.

In my search, I found several GitHub repositories. Most were either too simple to be useful or too complicated and already set up, leaving no room for learning. They often included ready-made Docker Compose files and Kubernetes manifests, which didn't help with learning through hands-on experience.

That’s when I discovered Craftista, a project maintained by Gourav Shah. This wasn’t just another training repo. As described in its documentation:

“Craftista is not your typical hello world app or off-the-shelf WordPress app used in most DevOps trainings. It is the real deal.”

Craftista stood out to me for several reasons:

• It’s a polyglot microservices application, designed to resemble a real-world platform.

• Each service uses its own technology stack – exactly like in modern enterprises.

• It includes essential building blocks of a real e-commerce system:

  • A modern UI built in Node.js

  • A Product Catalogue Service

  • A Recommendation Engine

  • A Voting/Review Service

By the end of this guide, you won’t just have a “hello world” demo – you’ll have a fully functioning CI/CD/GitOps pipeline modeled on a real-world microservices stack. You’ll understand how the pieces fit together, why each tool exists, and how to adapt this workflow to your own projects.

Ready to go beyond hello world and build a production-style pipeline from scratch? Let’s dive in.

Table of Contents

• Prerequisites and What You’ll Learn

• Topics Outside the Scope of This Guide

• What is GitOps?

  • Core Principles of GitOps

• Tools We Are Using in This Guide

  • GitHub Actions

  • Minikube

  • Argo CD

  • Kargo

• How to Structure Repositories for Microservice Applications

  • Why a Polyrepo Fits My Microservice-Service App

  • Git Branching is Anti Pattern to GitOps Principles

• How to Organize Kubernetes Manifests for GitOps

  • Argo CD Folders

  • 2. Argo CD Application Manifests (by Environment)

  • Env Folders

  • Kargo Folders

• How to Deploy and Promote Your Craftista Microservices Application

  • Prerequisites

  • 1. Start Minikube

  • 2. Install Argo CD

  • 3. Access the Argo CD UI

  • 4. Define a “Craftista” Argo CD Project

  • 5. Deploy the Development Environment

  • 6. Manual Promotion (Staging & Prod)

  • 7. Automated Promotion with Kargo

• Further Reading & Resources

• Conclusion

Prerequisites and What You’ll Learn:

Before you progress through this guide, ask yourself:

• Do I understand how semantic tagging improves traceability across environments?

• Can I replicate a multi-environment GitOps setup using Helm and Kubernetes?

• Am I confident in organizing Helm charts and manifests for scalable deployments?

• Do I know how Kargo and Argo CD work together to automate promotions and approvals?

This guide will help you confidently answer those questions by walking you through:

• ✅ An optimized Git branching strategy: using feature branches and a single main branch

• ✅ Semantic Docker image tagging for clean version tracking

• ✅ Helm chart and Kubernetes manifest structuring for multi-environment GitOps

• ✅ CI pipelines using GitHub Actions for build → test → tag automation

• ✅ Full GitOps workflows with Kargo and Argo CD for seamless promotion and delivery

Topics Outside the Scope of This Guide

• Deployment to managed services like EKS, AKS, or GKE is not included. We’ll use Minikube for local development.

• I assume you are already familiar with writing basic Kubernetes manifests. I won’t explain Pods, Services, Deployments, and their YAML structures here.

• I also won’t discuss topics like logging, metrics, tracing, and security hardening.

• This guide does not cover Managing Secrets and ConfigMaps and Implementing Service Discovery.

• And finally, we won’t go over ArgoCD and Kargo installation.

What is GitOps?

GitOps is a modern way to manage applications and infrastructure using Git as the main source of truth. Developers have used Git for a long time to manage and work together on code. GitOps takes this further by including infrastructure setup, deployment processes, and automation.

By keeping everything – from Kubernetes files and Helm charts to infrastructure code and app settings – in Git, teams have a central, version-controlled system that can be tracked. Changes in Git are automatically updated and matched with the target environments by GitOps tools like Argo CD or Flux.

Core Principles of GitOps

• Git as the single source of truth

• Declarative systems

• Immutable deployments

• Centralized change audit

Tools We Are Using in This Guide

GitHub Actions

GitHub Actions is a platform for continuous integration and delivery (CI/CD) that helps automate your build, test, and deployment processes.

In our project, we’ll use it to store our microservice application code. We’ll use GitHub Actions workflows to build and push Docker images to Docker Hub as our Docker registry. We’ll rely on GitHub Actions for continuous delivery.

Minikube

We are deploying our application and ArgoCD locally on Minikube. To simulate promotion between different environments, I am using namespaces.

Argo CD

Argo CD is a declarative GitOps continuous deployment tool for Kubernetes that automates the deployment and synchronization of microservice applications with Git repositories. It follows GitOps principles and uses declarative configurations with a pull-based approach.

Here’s a summary of the flow depicted in the above image:

1. The developer modifies application code and changes are pushed to a Git repository.

2. The CI pipeline is triggered and builds a new container image and pushes it to a container registry.

3. Merge triggers a webhook to notify Argo CD of changes in the Git repository.

4. Argo CD clones the updated Git repository. Compares the desired state (from Git) with the current state in the Kubernetes cluster.

5. Argo CD applies the necessary changes to bring the cluster to the desired state.

6. Kubernetes controllers reconcile resources until the cluster matches the desired configuration.

7. Argo CD continuously monitors the application and cluster state.

8. Argo CD can automatically or manually revert the changes to match the Git configuration, ensuring Git remains the single source of truth.

Kargo

Kargo manages promotion by watching repositories (Git, Image, Helm) for changes and making the needed commits to your Git repository, while Argo CD takes care of reconciliation. Kargo is built to simplify multi-stage application promotion using GitOps principles, removing the need for custom automation or CI pipelines.

Kargo Components

1. Warehouse: Watches image registries and discovers new container images. Monitors DockerHub for new tags like v1.2.0, v1.2.1, etc., and stores metadata about discovered images.

2. Stage: Defines a deployment environment (Dev, Stage, Prod). When a new image is found by the warehouse, it updates the manifest under env/dev/ with the new image tag. This triggers Argo CD to sync the dev environment.

3. PromotionPolicy: Defines how promotion should happen between stages (for example, auto or manual).

4. Freight: An artifact version to be promoted (for example, a specific container image or Helm chart). When v1.2.1 is discovered by the warehouse, a new Freight is created.

Practical Examples

• A new v1.2.0 image is pushed to DockerHub.

• Kargo detects it via a warehouse and updates the dev environment.

• Once verified (either by tests or metrics), Kargo automatically updates Helm values in the Git repo for staging.

• Argo CD sees the Git change and syncs the new version to staging.

• Manual approval (via Slack or UI) is required to push to production.

Why Kargo is the Perfect Companion to Argo CD

Have you ever had to manually promote versions across environments and wished it were automated? How would integrating Kargo have saved time or prevented errors in your last deployment?

Argo CD excels at GitOps-driven continuous deployment – syncing your Kubernetes cluster with the desired state declared in Git. But it lacks native support for promotion workflows between environments (like dev → staging → production) based on image metadata, test results, or approval gates. This is where Kargo becomes the perfect companion.

Kargo doesn’t replace Argo CD – it extends it. You continue to use Argo CD for syncing and deploying apps, but Kargo adds promotion intelligence and automation.

How to Structure Repositories for Microservice Applications

My example application consists of 4 microservices (frontend, recommendation, catalogues, and voting). Designing your repository structure is very important to start your project. There is a lot of debate between monorepo and multi-service repo.

A monorepo is a unified repository that houses all the code for a project or a set of related projects. It consolidates code from various services, libraries, and applications into a single centralized location.

On the other hand, a polyrepo architecture comprises multiple repositories, each containing the code for a distinct service, library, or application component.

Why a Polyrepo Fits My Microservice-Service App

Imagine you're onboarding a new team to your app. Would you prefer giving them access to an entire monorepo or just the relevant service’s repo? What trade-offs are you willing to accept?”

Well, using a polyrepo approach,

• Teams can work independently on the frontend, recommendations, catalogs, and voting without stepping on each other’s toes.

• Sensitive services remain locked down without complex directory-level rules.

• CI runners operate on a smaller codebase, speeding up checkouts and reducing bandwidth.

• Each service has its own release cadence (for example, catalogues v2.1.0 and voting v1.7.3).

• As your organization grows, new teams can onboard to only the repos they care about.

• Shared libraries can be versioned and published to an internal package registry, then consumed by each service.

Git Branching is Anti Pattern to GitOps Principles

Many teams default to “GitFlow”-style branching – creating long-lived branches for dev, staging, prod, and more. But in a true GitOps workflow, Git is your control plane, and “environments” shouldn’t live as branches.

Instead, you can keep things simple with just:

• A long-lived master (or main) branch

• Short-lived feature branches for code work

How to Organize Kubernetes Manifests for GitOps

This repo shows how you can keep ArgoCD application manifests, environment-specific values, Kargo promotion tasks, Helm charts for each microservice, and CI/CD workflows all in one place. It is organized so that:

1. ArgoCD application manifests live under argocd/, split by environment (for example, dev/, staging/, prod/).

2. Environment-specific overrides (Helm values or Kustomize patches) go under env/.

3. Kargo promotion configurations are grouped under kargo/, defining how new images move between environments.

4. Service Helm charts reside in service-charts/, one chart per microservice.

/microservice-helmcharts/
├── argocd/                # ArgoCD application manifests
│   ├── application/       # Application definitions
│   │   ├── dev/           # Development environment applications
│   │   │   ├── catalogue.yaml
│   │   │   ├── catalogue-db.yaml
│   │   │   ├── frontend.yaml
│   │   │   ├── recommendation.yaml
│   │   │   ├── voting.yaml
│   │   │   └── kustomization.yaml
│   │   ├── staging/       # Staging environment applications
│   │   │   └── [similar structure as dev]
│   │   ├── prod/          # Production environment applications
│   │   │   └── [similar structure as dev]
│   │   └── craftista-project.yaml
│   ├── blog-post.md
│   ├── deployment-guide-blog.md
│   └── repository-structure.md
├── env/                   # Environment-specific configurations
│   ├── dev/               # Development environment values
│   │   ├── catalogue/
│   │   │   └── catalogue-values.yaml
│   │   ├── catalogue-db/
│   │   │   └── catalogue-db-values.yaml
│   │   ├── frontend/
│   │   │   └── frontend-values.yaml
│   │   ├── recommendation/
│   │   │   └── recommendation-values.yaml
│   │   ├── voting/
│   │   │   └── voting-values.yaml
│   │   └── kustomization.yaml
│   ├── staging/           # Similar structure as dev but with image files
│   └── prod/              # Similar structure as staging
├── kargo/                 # Kargo promotion configuration
│   ├── catalogue-config/  # Catalogue service promotion
│   │   ├── catalogue-promotion-tasks.yaml
│   │   ├── catalogue-stages.yaml
│   │   └── catalogue-warehouse.yaml
│   ├── frontend-config/   # Frontend service promotion
│   │   ├── frontend-promotion-tasks.yaml
│   │   ├── frontend-stages.yaml
│   │   └── frontend-warehouse.yaml
│   ├── recommendation-config/ # Recommendation service promotion
│   │   ├── recommendation-promotion-tasks.yaml
│   │   ├── recommendation-stages.yaml
│   │   └── recommendation-warehouse.yaml
│   ├── voting-config/     # Voting service promotion
│   │   ├── voting-promotion-tasks.yaml
│   │   ├── voting-stages.yaml
│   │   └── voting-warehouse.yaml
│   ├── kargo.yaml         # ArgoCD application for Kargo
│   ├── kustomization.yaml # Combines all Kargo resources
│   ├── project.yaml       # Kargo project definition
│   └── projectconfig.yaml # Project-wide promotion policies
├── service-charts/        # Helm charts for each microservice
│   ├── catalogue/         # Catalogue service chart
│   │   ├── templates/
│   │   │   ├── deployment.yaml
│   │   │   └── service.yaml
│   │   ├── Chart.yaml
│   │   └── values.yaml
│   ├── catalogue-db/      # Similar structure as catalogue
│   ├── frontend/          # Similar structure as catalogue
│   ├── recommendation/    # Similar structure as catalogue
│   └── voting/            # Similar structure as catalogue
├── .github/workflows/     # CI/CD workflows
│   └── docker-ci.yml      # Docker image build and push
└── README.md              # Repository documentation

Argo CD Folders

The argocd/ directory contains all of the manifests that Argo CD needs in order to track, group, and deploy your microservices. In this guide, we break that directory into two main pieces:

1. Argo CD Project Definition

2. Argo CD Application Manifests (organized by environment)

ArgoCD Projects

Before you can give Argo CD a set of Applications to manage, it’s often best practice to define a “Project.” A Project in Argo CD serves as a logical boundary around a group of Applications. It can control which Git repos those Applications are allowed to reference, which Kubernetes clusters/namespaces they can target, and even which resource kinds they can manage.

In our example repo, the file craftisia-project.yaml lives at the top of argocd/:

# argocd/craftisia-project.yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: craftisia
  namespace: argocd
spec:
  # 1) Which Git repos are we allowed to pull from?
  sourceRepos:
    - "https://github.com/nitheeshp-irl/microservice-helmcharts"
    # (Or you could use "*" to allow any repo, but this is less secure.)

  # 2) Which clusters/namespaces can these Apps be deployed to?
  destinations:
    - namespace: "*"
      server: "*"    # Allow deployment to any cluster (for a local Minikube demo, this is fine).

  # 3) Which kinds of Kubernetes resources may be created/updated?
  #    (For example, we want Pods, Services, Deployments, Ingresses, etc.)
  #    Argo CD will reject any manifest containing a disallowed kind.
  clusterResourceWhitelist:
    - group: ""            # core API group (Pods, Services, ConfigMaps, etc.)
      kind: Pod
    - group: "apps"        # deployments, statefulsets, etc.
      kind: Deployment
    - group: "networking.k8s.io"
      kind: Ingress
    # (You can list additional resource kinds as needed.)

  # 4) Optional: define role-based access control or sync policies at the project level.
  #    (Not shown here, but you could add roles, namespace resource quotas, etc.)

2. Argo CD Application Manifests (by Environment)

Inside argocd/, there is a subdirectory called application/. We use this to keep all of our Argo CD Application YAMLs, broken out by environment. The high-level layout looks like this:

rCopyEditargocd/
└── application/
    ├── dev/            # “Dev” environment Applications
    │   ├── catalogue.yaml
    │   ├── catalogue-db.yaml
    │   ├── frontend.yaml
    │   ├── recommendation.yaml
    │   ├── voting.yaml
    │   └── kustomization.yaml
    ├── staging/        # “Staging” environment Applications (same names/structure as dev/)
    │   └── […]
    └── prod/           # “Prod” environment Applications (same names/structure as dev/)
        └── […]

Each of those YAML files is a standalone Argo CD Application. An Application tells Argo CD:

1. Which project it belongs to (in our case, craftisia),

2. Where to find its manifests (a Git repo and path),

3. Which Kubernetes cluster and namespace to deploy into, and

4. How to keep itself up to date (that is, sync policies).

Below is a example of the frontend.yaml file for the dev environment:

yamlCopyEdit# argocd/application/dev/frontend.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: frontend-dev
  namespace: argocd
spec:
  project: craftisia

  # 1) Source: Where to find the Helm chart and which values file to use
  source:
    repoURL: https://github.com/nitheeshp-irl/microservice-helmcharts
    targetRevision: main
    path: service-charts/frontend       # Helm chart folder for the frontend service
    helm:
      valueFiles:
        - ../../env/dev/frontend/frontend-values.yaml

  # 2) Destination: Which cluster & namespace to deploy into
  destination:
    server: https://kubernetes.default.svc    # (Assumes Argo CD is running in-cluster)
    namespace: front-end-dev                   # A dedicated namespace for “dev” frontend

  # 3) Sync Policy: Automate synchronization and enable self-healing
  syncPolicy:
    automated:
      prune: true          # Delete resources that are no longer in Git
      selfHeal: true       # If someone manually changes live resources, revert to Git state
    syncOptions:
      - CreateNamespace=true  # If the namespace doesn’t exist, Argo CD will create it

You would repeat a similar pattern under argocd/application/staging/ and argocd/application/prod/ – each environment has its own frontend.yaml, catalogue.yaml, and so on, but each will point to a different values file under env/staging/… or env/prod/… and likely deploy into a different namespace (for example, front-end-staging, front-end-prod).

Env Folders

The /env directory is a critical part of our GitOps implementation, containing all environment-specific configurations for our microservices. Each environment (dev, staging, prod) has its own subdirectory containing service-specific configurations. These contain general Helm chart values like resource limits and replica counts and container image repository and tag.

image:
  repository: nitheesh86/microservice-frontend
  tag: 1.0.11

replicaCount: 2

resources:
  limits:
    memory: "512Mi"
  requests:
    cpu: "100m"
    memory: "128Mi"

Kargo Folders

Our Kargo setup is organized in the /kargo directory with several key components:

/kargo/
├── catalogue-config/           # Catalogue service promotion configuration
│   ├── catalogue-promotion-tasks.yaml  # Defines how to update catalogue images
│   ├── catalogue-stages.yaml           # Dev, staging, prod stages for catalogue
│   └── catalogue-warehouse.yaml        # Monitors catalogue image repository
├── frontend-config/            # Frontend service promotion configuration
│   ├── frontend-promotion-tasks.yaml   # Defines how to update frontend images
│   ├── frontend-stages.yaml            # Dev, staging, prod stages for frontend
│   └── frontend-warehouse.yaml         # Monitors frontend image repository
├── recommendation-config/      # Recommendation service promotion configuration
│   ├── recommendation-promotion-tasks.yaml  # Image update workflow
│   ├── recommendation-stages.yaml           # Environment stages
│   └── recommendation-warehouse.yaml        # Image monitoring
├── voting-config/              # Voting service promotion configuration
│   ├── voting-promotion-tasks.yaml     # Image update workflow
│   ├── voting-stages.yaml              # Environment stages
│   └── voting-warehouse.yaml           # Image monitoring
├── kargo.yaml                  # ArgoCD application for Kargo installation
├── kustomization.yaml          # This file - combines all resources
├── project.yaml                # Defines the Kargo project
└── projectconfig.yaml          # Project-wide promotion policies

Stage Configurations: Kargo uses the concept of "stages" to represent our deployment environments. Each stage defines:

• Which freight (container images) to deploy

• The promotion workflow to execute

• Environment-specific variables

Warehouse Configuration: The warehouse monitors our container registry for new images.

Promotion Tasks: Promotion tasks define the actual workflow for promoting between environments.

How to Deploy and Promote Your Craftista Microservices Application

Now I'll explain how to deploy your Craftista microservices application using Argo CD.

Prerequisites

• A local Kubernetes cluster: We’ll use Minikube for local development.

• kubectl and helm: Ensure both are installed and configured.

• Git Clone of the microservice-helmcharts Repo:

    git clone https://github.com/nitheeshp-irl/microservice-helmcharts.git
    cd microservice-helmcharts
  

1. Start Minikube

Start Minikube with the specified resources:

minikube start --memory=4096 --cpus=2
kubectl config use-context minikube

Adjust --memory and --cpus as needed for your machine.

2. Install Argo CD

Create a namespace:

kubectl create namespace argocd

Apply the official install manifest:

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

3. Access the Argo CD UI

Port-forward the server:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Login:

• Username: admin

• Password:

    kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
  

Open your browser at http://localhost:8080.

4. Define a “Craftista” Argo CD Project

Scope Repos, Clusters, and Namespaces:

kubectl apply -f argocd/application/craftista-project.yaml

You should see:

project.argoproj.io/craftista created

5. Deploy the Development Environment

Create Argo CD applications:

kubectl apply -f argocd/application/dev/

Argo CD will:

• Clone the microservice-helmcharts repo.

• Render each Helm chart with its env/dev/*-values.yaml.

• Create Deployment, Service, and so on in your dev namespaces.

• Continuously reconcile desired vs. actual state.

Monitor your progress:

argocd app list
argocd app get frontend-dev

6. Manual Promotion (Staging & Prod)

Edit the image tag or other values:

• env/staging/<service>/<service>-values.yaml

• env/prod/<service>/<service>-values.yaml

Commit and push the changes:

git add env/staging env/prod
git commit -m "Promote v1.2.0 → staging & prod"
git push

Argo CD will detect the Git change and automatically sync your staging and prod applications (if automated sync is enabled).

7. Automated Promotion with Kargo

First, install Kargo:

kubectl apply -f kargo/kargo.yaml

Configure promotion tasks, stages, and warehouse:

kubectl apply -k kargo/

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - project.yaml
  - projectconfig.yaml
  - catalogue-config/catalogue-warehouse.yaml
  - catalogue-config/catalogue-stages.yaml
  - catalogue-config/catalogue-promotion-tasks.yaml
  - frontend-config/frontend-warehouse.yaml
  - frontend-config/frontend-stages.yaml
  - frontend-config/frontend-promotion-tasks.yaml
  - recommendation-config/recommendation-warehouse.yaml
  - recommendation-config/recommendation-stages.yaml
  - recommendation-config/recommendation-promotion-tasks.yaml
  - voting-config/voting-warehouse.yaml
  - voting-config/voting-stages.yaml
  - voting-config/voting-promotion-tasks.yaml

How the GitOps Pipeline Works

1. Developer Opens a Pull Request: The journey begins when a developer opens a pull request on one of the microservice repos. This signals that new code (feature, bugfix, config change) is ready to be integrated.

2. CI (GitHub Actions)

   • CI: Lint → Test → Build & Tag: A single workflow job lints the code, runs unit/integration tests, builds the Docker image, and applies a semantic tag (for example, v1.2.0).

   • CI OK? (Decision):

     • If No, the pipeline stops and the developer is notified to fix errors.

     • If Yes, the newly built image is pushed to the container registry (DockerHub, ECR, and so on).

3. Kargo

   • Warehouse discovers new image tag: Kargo’s Warehouse component continuously watches your registry. As soon as it sees the new tag, it records that image metadata.

   • Update env/dev values → Git: Kargo automatically commits an update to env/dev/<service>/…-values.yaml, pointing the dev Helm values file to the new image tag. This Git commit will drive the next step.

4. GitOps (Argo CD)

5. • Argo CD sync dev: Argo CD sees the Git change in the dev values file and pulls it into the cluster, reconciling the actual dev namespace with the desired state.

     • Dev deployment healthy? (Decision):

       • If No, Argo CD can optionally roll back and notifies the team (via Slack, email, etc.) of the failed dev rollout.

       • If Yes, it’s time to promote to staging.

     • Update env/staging values → Git: Kargo (or you, if manual) commits the same image tag into env/staging/<service>/…-values.yaml.

     • Argo CD sync staging: Argo CD deploys that change to the staging namespace.

     • Staging approval granted? (Decision):

       • If No, Kargo waits (and optionally notifies) until a manual gate is lifted.

       • If Yes, the final promotion commit is made: updating env/prod/<service>/…-values.yaml.

     • Argo CD sync prod → End: Argo CD applies the production change, completing the pipeline from commit all the way to live production rollout.

Pipeline Summary

1. Developer opens PR → CI tests and builds → Docker image pushed

2. Kargo Warehouse detects new tag → Git commit to env/dev

3. Argo CD syncs dev → Health check → (if successful) commit to env/staging

4. Argo CD syncs staging → Approval → commit to env/prod

5. Argo CD syncs prod → Live deployment complete

Every stage must pass its health or approval check before the next begins, ensuring that only thoroughly tested and validated code makes it into production.

Conclusion

Building a real-world CI/CD pipeline isn’t just about getting code from your laptop into a Kubernetes cluster – it’s about creating a repeatable, auditable, and reliable system that scales with your team and your application complexity.

In this guide, we walked through how I built a complete GitOps-based promotion pipeline using GitHub Actions, Argo CD, and Kargo, all driven by a hands-on microservices project: Craftista. From the first code commit to automated environment promotion, we leveraged industry best practices like semantic versioning, declarative infrastructure, and environment-based GitOps directories.

What makes this approach powerful is not just the tools but also the principles. By treating Git as the single source of truth, and using Kargo to automate what was traditionally a manual and fragile promotion process, we gain predictability and control over our deployments. Argo CD ensures that what’s in Git is always what’s running in our clusters, while Kargo eliminates human error in multi-stage rollouts.

If you’re tired of overly abstract “hello world” DevOps tutorials and want to get your hands dirty with something that feels real, Craftista offers the perfect sandbox. This pipeline reflects how teams operate in production – polyglot services, independent deployments, environment promotion gates, and GitOps as the operational backbone.

Whether you're a DevOps engineer sharpening your skills, or a platform team setting standards for internal development, I hope this tutorial provided the clarity and inspiration to build your own commit-to-production pipeline – step by step, with confidence.

Further Reading & Resources

• Argo CD Documentation

• Kargo Docs

• GitHub Actions Docs

• How to Model Your GitOps Environments and Promote Releases between Them

• Craftista Repo

This arrangement might work well in early days, but as a company grows and their needs become more specialized, the simplicity of a single account might start to show its limitations. The demand for dedicated environments will start to increase, and soon, that company may need to create new AWS accounts for specific functions like security, DevOps, and billing.

With each new account, the complexity of managing security policies and logging across the entire infrastructure grows exponentially. The cloud architects for these companies will then realize that they need a more centralized and streamlined approach to manage this expanding digital presence.

Enter AWS Organizations

AWS Organizations is a service designed to streamline AWS account management. This powerful tool allows you to group multiple AWS accounts under a single umbrella. With AWS Organizations, you can easily create organizational units, apply service control policies, and manage permissions across all accounts. This not only simplifies the process but also enhances security and compliance.

The billing processes of AWS Organizations have also been optimized through the centralization of payments and the generation of comprehensive expense reports for each account. This improved clarity in financial management makes it easier for companies to allocate resources in a more efficient manner and strategize for future expansion.

AWS Organizations can help your team consistently enforce security policies, enable logging across all accounts, and streamline administrative tasks. Cloud infrastructure is now a well-organized, secure, and efficient machine, ready to support a company's ambitions for years to come.

In this article, we’ll discuss what it means to have a multi-account setup and how it works. I’ll walk you through everything from the deployment architecture to creating an Organizational Unit and beyond.

Table of Contents

• Components of Multi-Account Setup

• How to Automate a Multi-Account Strategy

• AWS Organization Structure

• Deployment Architecture

• OverView of CI/CD Components

• CI/CD Deployment Process Explained

• How to Automate Landing Zone Creation

• How to Create an Organizational Unit

• How to Automate Attaching Control Tower Control to the OU

• Conclusion

Components of Multi-Account Setup

First, let's take a detailed look at the various components that make up an AWS multi-account strategy:

• AWS Control Tower

• Landing zone

• AWS OU

• AWS SSO

• Control Tower Controls

• Service control policies (SCPs)

What is AWS Control Tower?

AWS Control Tower is a comprehensive service that enables you to set up and manage a multi-account AWS environment efficiently. It’s designed based on best practices from AWS experts and adheres to industry standards and requirements.

By using AWS Control Tower, you can ensure that your AWS environment is secure, compliant, and well-organized, facilitating easier management and scalability.

Features of AWS Control Tower:

• Cloud IT can be confident that all accounts are in line with company-wide regulations, and distributed teams may create new AWS accounts quickly.

• You can enforce best practices, standards, and regulatory requirements with preconfigured controls.

• You can automate your AWS environment setup with best-practice blueprints. These blueprints cover various aspects such as multi-account structure, identity and access management, as well as account provisioning workflow.

• It lets you govern new or existing account configurations, gain visibility into compliance status, and enforce controls at scale.

What is a Landing Zone in AWS?

A landing zone helps you quickly set up a cloud environment using automation, including preconfigured settings that follow industry best practices for ensuring the security of your AWS accounts.

The starting point serves as a foundation for your company to efficiently initiate and implement workloads and applications, ensuring a secure and reliable infrastructure environment.

There are two choices for creating a landing zone. First, you can use the AWS Control Tower dashboard. Second, you can build a custom landing zone. If you are new to AWS, I recommend using AWS Control Tower to create a landing zone.

If you opt for creating a landing zone via the Control Tower dashboard, the following will be implemented in your landing zone:

• A multi-account environment with AWS organizations.

• Identity management through the default directory in AWS IAM Identity Center.

• Federated access to accounts using IAM Identity Center.

• Centralized logging from AWS CloudTrail and AWS Config stored in Amazon Simple Storage Service (Amazon S3).

• Enabled cross-account security audits using IAM Identity Center.

What is an AWS Organizational Unit?

Using multiple accounts allows you to better support your security goals and company operations.

AWS Organizations enables policy-based management of multiple AWS accounts. When you create new accounts, you can arrange them in organizational units (OUs), which are groupings of accounts that provide the same application or service.

Advantages of Using OUs:

• Accounts are units of security protection. Potential hazards and security threats can be contained within one account without affecting others.

• Teams have different assignments and resource needs. Setting up different accounts prevents teams from interfering with one another, as they might do if they used the same account.

• Isolating data stores to an account reduces the number of people who have access to and can manage the data store.

• The multi-account concept allows you to generate separate billable items for business divisions, functional teams, or individual users.

• AWS quotas are set up per account. Separating workloads into different accounts gives each account an individual quota.

What is AWS IAM Identity Center?

The AWS IAM Identity Center provides a centralized solution for managing access to multiple AWS accounts and business applications.

This method offers a single sign-on feature that allows employees to access all assigned accounts and applications from a single credential.

The personalized web user portal provides a centralized view of the user's assigned roles in AWS accounts.

For a uniformed authentication experience, users can sign in using the AWS Command Line Interface, AWS SDKs, or the AWS Console Mobile Application with their directory credentials.

You can also set up and oversee user IDs in IAM Identity Center's identity store, or you can connect to your existing identity provider, such as Microsoft Active Directory, Okta, and so on.

Control Tower Controls (Guardrails)

Controls are predefined governance rules for security, operations, and compliance. You can select and apply them enterprise-wide or to specific groups of accounts.

Controls can be detective, preventive, or proactive and can be either mandatory or optional.

• First, we have detective controls (for example, detecting whether public read access to Amazon S3 buckets is allowed).

• Next, preventive controls establish intent and prevent deployment of resources that don’t conform to your policies (for example, enabling AWS CloudTrail in all accounts).

• Finally, proactive control capabilities use AWS CloudFormation Hooks to proactively identify and block the CloudFormation deployment of resources that are not compliant with the controls you have enabled. For example, developers cannot create S3 buckets that are capable of storing data in an unencrypted state at rest.

Service Control Policies (SCP)

SCPs are a feature of the organization that allows you to set the maximum permissions for member accounts within the organization.

There are many functions and features of an SCP:

• If an SCP denies an action on an account, no entity in the account can perform that action, even if its IAM permissions allow it.

• Prevents stopping or deletion of CloudTrail logging.

• Prevents deletion of VPC flow logs.

• Prohibits AWS accounts from leaving the organization.

• Prevents AWS GuardDuty changes.

• Prevents resource sharing using AWS Resource Access Manager (RAM) either externally or across environments.

• Prevents disabling the default Amazon EBS encryption.

• Prevents Amazon S3 unencrypted object uploads.

• And prevents IAM users and roles in the affected accounts from creating certain resource types if the request doesn't include the specified tags.

How to Automate a Multi-Account Strategy

Now that you’re familiar with the key concepts of a Multi-Account Strategy in AWS, let’s dive deeper into the practical parts.

In the coming subsections, we’ll cover how you can set up an AWS Control Tower, create a landing zone, and automatically create organizational units (OUs). I’ll also walk you through how to configure Control Tower controls—often known as guardrails—to uphold security, compliance, and governance over your AWS environment.

Once we finish this deployment, we will have a solution that includes the following components:

• Creates an AWS Organizations OU named Core within the organizational root structure.

• Creates and adds two shared accounts to the Security OU: the Log Archive account and the Audit account.

• Creates a cloud-native directory in IAM Identity Center, with ready-made groups and single sign-on access.

• Applies all required preventive controls to enforce policies.

• Applies required detective controls to identify configuration violations.

AWS Organization Structure

We will create and implement the following organizational structure. You can add or modify OUs as per your requirements.

Deployment Architecture

I will be using Terraform Cloud and GitHub Actions for automating the entire process. This architecture applies to all three components, including core accounts, landing zones, and organizational unit (OU) creation and controls.

Overview of CI/CD Components

1. GitHub Actions

GitHub Actions is a CI/CD platform that lets you automate your build, test, and deployment pipeline. You can create workflows that automatically build and test every pull request to your repository, ensuring code changes are verified before merging.

GitHub Actions also lets you deploy merged pull requests to production, streamlining the release process and reducing errors.

Using GitHub Actions enhances your development workflow, improves code quality, and speeds up the delivery of new features and updates.

2. Terraform Cloud

Terraform Cloud is a platform by HashiCorp for managing and executing your Terraform code. It offers tools and features that enhance collaboration between developers and DevOps engineers, making teamwork more efficient.

With Terraform Cloud, you can simplify and streamline your workflow, making it easier to handle complex infrastructure tasks and deployments. The platform also provides strong security features to protect your code and infrastructure, keeping your product secure throughout its lifecycle.

CI/CD Deployment Process Explained

DevOps engineers are responsible for writing the Terraform code and then creating a pull request. I have added several test cases for my Terraform code in the terraform-plan.yml file, which runs only on the feature branch.

• Check environment variables: Ensures all required environment variables are set.

• Checkout Code: Uses the actions/checkout action to check out the repository.

• Verify Checkout: Verifies that the checkout was successful.

• Validation: Verifies the Terraform code for any syntax errors. Pull requests contain proposed changes in code, allowing team members to review and merge them into the master branch. Once pull requests are merged with the master branch, all test cases are rerun, and the landing zone is created through Terraform Cloud

What to Know Before Setting up Control Tower

Before beginning the process of setting up for AWS Control Tower, it is important to have a clear understanding of what limitations are associated with Control Tower and consider some key points.

• When setting up a landing zone, it is important to choose your home region. Once you have made a selection, you won’t be able to change your home region.

• If you intend to establish a control tower on an existing AWS account that is already a part of an existing organizational unit (OU), you won’t be able to use it. In order to proceed, you’ll need to create a new AWS account that is not associated with any organizational Unit (OU).

• As part of the Control Tower creation process, you’ll need to create mandatory accounts such as the Log Archive Account and Audit Accounts. Account-specific emails are required.

• In order to set up the Landing Zone in the Management Account, it is essential to ensure that you have subscribed to the following services in the management account:

  • S3, EC2, SNS, VPC, CloudFormation, CloudTrail, CloudWatch, AWS Config, IAM, AWS Lambda

• The AWS Control Tower baseline covers only a few services with limited customization options: IAM Identity Center, CloudTrail, Config, some configuration rules, and some SCPs in AWS Organizations.

• Implementing IAM Identity Center is limited to the management account of an organization.

• AWS Control Tower implements concurrency limitations, allowing only one operation to be performed at a time.

• Note that certain AWS Regions do not support the operation of some controls in AWS Control Tower. This is because the specified Regions lack the necessary underlying functionality to support the required operations.

How to Create a Control Tower

Creating a Control Tower means setting up a landing zone. AWS landing zone requires creating two new member accounts: the Audit account and the Log Archive account. You will need two unique email addresses for these accounts.

We will manage this process using Terraform modules. To keep things simple and clear, we will divide the project into several modules. One module will create the two core accounts. Another module will handle the setup of the landing zone. The final module will create Organizational Units (OUs) and apply Control Tower controls to ensure governance and compliance.

How to Automate Landing Zone Creation

When you run this code, the Core OU and two accounts are created under the Core OU. I have mentioned two repositories for each component: one for deploying the AWS resources like the landing zone, OU, and Control Tower Controls and another for the Terraform module.

A Terraform module is a set of standard configuration files in a specific directory. Terraform modules group resources for a specific task, which reduces the amount of code needed for similar infrastructure components.

I have imported both the core account creation and landing zone creation modules into the same main.tf file. This is necessary because the landing zone creation depends on the core account module. Including them together ensures all dependencies are managed properly and the deployment process is efficient.

This method also simplifies the project structure and helps avoid potential issues from managing these components separately.

The AWS Control Tower CreateLandingZone API needs a landing zone version and a manifest file as input parameters. Below is an example LandingZoneManifest.json manifest.

{
   "governedRegions": ["us-west-2","us-west-1"],
   "organizationStructure": {
       "security": {
           "name": "CORE"
       },
       "sandbox": {
           "name": "Sandbox"
       }
   },
   "centralizedLogging": {
        "accountId": "222222222222",
        "configurations": {
            "loggingBucket": {
                "retentionDays": 60
            },
            "accessLoggingBucket": {
                "retentionDays": 60
            },
            "kmsKeyArn": "arn:aws:kms:us-west-1:123456789123:key/e84XXXXX-6bXX-49XX-9eXX-ecfXXXXXXXXX"
        },
        "enabled": true
   },
   "securityRoles": {
        "accountId": "333333333333"
   },
   "accessManagement": {
        "enabled": true
   }
}

This module sets up the AWS landing zone using landingzone_manifest_template. The landing zone version and admin account ID are given through variables. This module also creates several IAM roles required for the landing zone setup.

I defined a local variable landingzone_manifest_template, which is a JSON template for setting up the landing zone. This JSON template has several important settings:

provider "aws" {
  region = var.region
}

locals {
  landingzone_manifest_template = <<EOF
{
    "governedRegions": ${jsonencode(var.governed_regions)},
    "organizationStructure": {
        "security": {
            "name": "Core"
        }
    },
    "centralizedLogging": {
         "accountId": "${module.aws_core_accounts.log_account_id}",
         "configurations": {
             "loggingBucket": {
                 "retentionDays": ${var.retention_days}
             },
             "accessLoggingBucket": {
                 "retentionDays": ${var.retention_days}
             }
         },
         "enabled": true
    },
    "securityRoles": {
         "accountId": "${module.aws_core_accounts.security_account_id}"
    },
    "accessManagement": {
         "enabled": true
    }
}
EOF
}

module "aws_core_accounts" {
  source = "https://github.com/nitheeshp-irl/terraform_modules/aws_core_accounts_module"

  logging_account_email  = var.logging_account_email
  logging_account_name   = var.logging_account_name
  security_account_email = var.security_account_email
  security_account_name  = var.security_account_name
}

module "aws_landingzone" {
  source                  = "https://github.com/nitheeshp-irl/blog_terraform_modules/aws_landingzone_module"
  manifest_json           = local.landingzone_manifest_template
  landingzone_version     = var.landingzone_version
  administrator_account_id = var.administrator_account_id
}

• Governed Regions: Specifies the regions governed by the landing zone.

• Organization Structure: Defines the security structure with a dedicated security account.

• Centralized Logging: Configures logging, specifying the account ID and retention policies for logs.

• Security Roles: Specifies the account ID for security roles.

• Access Management: Enables access management.

• Core Accounts: The core accounts code, also defined in the same file, is what sets up essential AWS accounts for logging and security.

You can find the full code here: https://github.com/nitheeshp-irl/aws-landing-zone.

How to Create an Organizational Unit

When you run this code, different organizational units (OUs) are created according to the specifications in the variable file.

Once the landing zone setup is finished, we can create an OU as per our business requirements. This will take the OU name from the variable file and create the OU.

aws_region = "us-east-2"

organizational_units = [
  {
    unit_name = "apps"
  },
  {
    unit_name = "infra"
  },
  {
    unit_name = "stagingpolicy"
  },
  {
    unit_name = "sandbox"
  },
  {
    unit_name = "security"
  }
]

You can see the code here:

• AWS Organizational Units (OUs) Terraform Repo

• AWS Organizational Units Terraform Module Path

How to Automate Attaching Control Tower Control to the OU

Once you have created the OU units using the above repository, this repository will apply Control Tower controls to the OUs.

After creating the required objects, you can attach controls to the OU if you need them. Here is the main.tf file:

provider "aws" {
  region = var.region
}

module "aws_controls" {
  source = "https://github.com/nitheeshp-irl/blog_terraform_modules/awscontroltower-controls_module"

  aws_region = var.aws_region
  controls   = var.controls
}

We used Terraform modules to create AWS resources.

Here are the control variables:

aws_region = "us-east-2"


controls = [
  {
    control_names = [
      "AWS-GR_ENCRYPTED_VOLUMES",
      "AWS-GR_EBS_OPTIMIZED_INSTANCE",
      "AWS-GR_EC2_VOLUME_INUSE_CHECK",
      "AWS-GR_RDS_INSTANCE_PUBLIC_ACCESS_CHECK",
      "AWS-GR_RDS_SNAPSHOTS_PUBLIC_PROHIBITED",
      "AWS-GR_RDS_STORAGE_ENCRYPTED",
      "AWS-GR_RESTRICTED_COMMON_PORTS",
      "AWS-GR_RESTRICTED_SSH",
      "AWS-GR_RESTRICT_ROOT_USER",
      "AWS-GR_RESTRICT_ROOT_USER_ACCESS_KEYS",
      "AWS-GR_ROOT_ACCOUNT_MFA_ENABLED",
      "AWS-GR_S3_BUCKET_PUBLIC_READ_PROHIBITED",
      "AWS-GR_S3_BUCKET_PUBLIC_WRITE_PROHIBITED",
    ],
    organizational_unit_names = ["infra", "apps"]
  }
]

You can see the code here:

• Terraform Repo for Creating control tower controls

• Terraform Module for creating Control Tower Controls

Conclusion

Navigating a multi-account strategy in AWS can be challenging, but with AWS Control Tower and a structured approach, it becomes manageable.

Using AWS Control Tower, your team can ensure that their AWS environments are secure, compliant, and well-organized. The automated setup, governance at scale, and centralized management through AWS Organizations provide a strong foundation for cloud infrastructure.

Implementing a landing zone through AWS Control Tower offers a secure and standardized starting point, allowing for quicker deployment and better governance. Using organizational units (OUs) segregates accounts based on business needs, improving security and operational efficiency. AWS IAM Identity Center simplifies access management, providing a unified authentication experience across multiple accounts and applications.

Service Control Policies (SCPs) help keep things secure and compliant by making sure all resources follow the organization's rules. Terraform Cloud and GitHub Actions make it easier to deploy resources, offering a smooth CI/CD pipeline for managing infrastructure changes.

In this guide, I'll take you through my experience of preparing for and passing the AWS Certified Security Specialty exam. Rather than a comprehensive study guide, I'll present this as a collection of study notes and personal observations. My aim is to provide you with practical tips and strategies that helped me succeed.

For those seeking a more structured approach, I highly recommend the official AWS certification study guide and the excellent resources provided by TutorialsDojo. These were invaluable in my preparation and could be great resources for your own journey.

So, whether you're considering this certification or you’re just curious about AWS security, I hope you'll find value in the experiences and insights I'm about to share.

Should You Get Certified?

There are mixed opinions in the tech industry about the importance of certifications. Some people argue that the certificates you have don't matter – it's all about your real-world knowledge.

But not everyone has the chance to work with real-world projects. And certification questions are based on real-world scenarios. So if you haven't had an opportunity to work with AWS security much in practice, you can learn from this exam and apply your learnings on actual projects.

On the other hand, if you're already working with AWS, taking the exam is an excellent chance to test your knowledge and learn more about its internal workings.

For example, you might have been working with AWS for quite some time, but you haven't touched AWS security, or haven't been following best practices. The certification covers every aspect of AWS security, so you will learn how you can reduce your costs and follow best practices.

Exam Structure

• Exam Duration: 170 Mins

• Exam Format: 65 Questions. Multiple Choice, Multiple response

• Passing Score: The exam uses a scaled scoring system from 100 to 1,000. To pass, you need to achieve a minimum score of 750.

• Cost: $300 USD. Additional Tax may be $30.

• Delivery Method: Pearson VUE testing center or online proctored exam

It took me about 110 minutes to finish the questions, and I marked 25 for review. I then spent another 60 minutes reviewing those 25 questions.

In my case, the internet got disconnected, and my exam froze. Don't panic! Just launch the VUE software again—you are allowed to resume the exam. No snacking or restroom breaks are allowed, but you can have water.

My Study Approach

I used a structured method to prepare for the AWS Certified Security Specialty exam:

• Completed a comprehensive AWS security course on Udemy

• Practiced with multiple sets of exam questions:

  • Carefully analyzed incorrect answers

  • Consulted AWS documentation and AWS YouTube videos for a deeper understanding

• Used additional practice resources:

  • TutorialsDojo practice exams

  • WhizLabs mock tests

This approach helped me gain both theoretical knowledge and practical problem-solving skills essential for the exam.

Key Topics and Concepts

AWS IAM Credential Report

Understanding how to review the AWS IAM credential report is crucial. Here are some key points:

1. Multi-Factor Authentication (MFA) Enforcement: Identify users who haven't enabled MFA and enforce its usage.

2. Root Account Monitoring: Monitor usage of the root account to ensure it's not being used for day-to-day operations.

3. Track user creation and last activity dates to manage user lifecycles effectively.

4. Access Key Usage Monitoring: Identify unused access keys that could pose a security risk.

5. Find users with old passwords or access keys that might be compromised.

6. Understand Report Format: AWS Documentation

AWS S3 Object Lock

AWS S3 Object Lock is a feature that helps prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely. It's particularly useful for scenarios requiring data immutability, such as regulatory compliance or protection against accidental or malicious deletion.

• Compliance Mode: Prevents anyone, including the root user, from overwriting or deleting an object version.

• Governance Mode: Allows users with special permissions to overwrite or delete protected object versions.

Integrating On-Premise Active Directory with IAM

It's important to know the steps involved in integrating on-premise Active Directory with IAM for single sign-on. For more details, refer to this AWS Blog Post.

AWS Service Control Policies (SCPs)

Study AWS SCP examples. Service Control Policies (SCPs) are organization-level policies that manage permissions across your AWS organization. They provide centralized control over the maximum available permissions for IAM users and roles within your organization's accounts.

For SCP examples, refer to the AWS Documentation.

Serving Private Content through CloudFront

Learn how to serve private content through CloudFront. The AWS CloudFront Developer Guide provides detailed information on this topic.

• Using signed URLs is beneficial when you want to restrict access to individual files, for example, an installation download for your application.

• Using signed cookies is beneficial when you want to provide access to multiple restricted files, and don't want to change your current URLs.

Understanding Ephemeral Ports

Understand why it's important to set the range for ephemeral ports in outbound rules. Ephemeral ports are temporary ports used in network and internet communications, managed by the machine's operating system.

Check out this Medium article on NACL and ephemeral ports.

Securing Access to Websites through CloudFront

To ensure that users can only access your website through the CloudFront URL while completely restricting access via the Application Load Balancer (ALB) URL, you’ll need to know how to do the following:

1. Configure ALB Security Group: Restrict access to your ALB by only allowing traffic from CloudFront IP ranges.

2. Implement Custom Headers: Set a custom header in CloudFront and configure your ALB to only accept requests with this header.

AWS KMS and Envelope Encryption

AWS KMS can directly encrypt data up to 4 KB in size. For files larger than 4 KB, you need to use Envelope Encryption. Here are the steps:

• Generate a data key using AWS KMS

• Use the data key to encrypt your large data

• Encrypt the data key with KMS

• Store the encrypted data key with your encrypted data

KMS Policy Conditions

Learn how conditions work in AWS KMS policy. Refer to the AWS KMS Developer Guide for detailed information.

IAM Policy Conditions

• Get to know important IAM policy conditions. The AWS IAM User Guide offers detailed information.

• I strongly suggest watching these two videos to understand IAM policy conditions with examples:

  • Video 1

  • Video 2

Lambda Function Assuming IAM Role in Another AWS Account

Understand how to configure a Lambda function to assume an IAM role in another AWS account. Refer to this AWS Knowledge Center article for details.

KMS Key Rotation

Understand which types of keys can be rotated automatically and which require manual rotation.

• Symmetric encryption KMS keys can be rotated automatically.

• Asymmetric KMS keys, HMAC KMS keys, and custom key stores require manual rotation.

• KMS keys with imported key material also require manual rotation.

For more information, see the AWS KMS Developer Guide.

Amazon ECR Image Scanning

You can scan Amazon Elastic Container Registry (ECR) images for vulnerabilities. There are two types of scanning available in ECR:

• Enhanced scanning—Amazon ECR integrates with Amazon Inspector to provide automated, continuous scanning of your repositories. Enhanced scanning provides the following:

  • OS and programming languages package vulnerabilities.

  • Two scanning frequencies: Scan on push and continuous scan.

• Basic scanning—Amazon ECR provides two versions of basic scanning that use the Common Vulnerabilities and Exposures (CVEs) database:

  • The current GA version, which uses the open-source Clair project

  • An improved version that uses AWS native technology

Basic scanning offers:

• OS scans

• Two scanning frequencies: manual and scan-on-push

Implementing End-to-End Encrypted Traffic

Know when you have a use case that requires implementing end-to-end encrypted traffic. Steps are listed below:

1. Configure your CloudFront distribution to require HTTPS for all viewer requests.

   • Use a custom SSL/TLS certificate (from AWS Certificate Manager or imported) for CloudFront.

   • Use a third-party SSL/TLS certificate on your Application Load Balancer (ALB) or EC2 instances.

   • Ensure you use the same certificate on your EC2 instances as on your ALB for consistency.

Securely Storing RDS Credentials

Learn how to securely store RDS credentials. AWS Secrets Manager is the recommended service for storing and managing sensitive information like database credentials. It is not wise to hard-code database credentials in your code or store them in Lambda as environment variables.

CloudTrail: Data Events vs Management Events

Understand the differences between data events and management events in CloudTrail.

• Management Events

  • Provide information about management operations performed on resources in your AWS account.

  • Examples include:

    • IAM AttachRolePolicy operations

    • Amazon EC2 CreateSubnet operations

    • AWS CloudTrail CreateTrail operations

• Data Events

  • Provide information about resource operations performed on or within a resource.

  • Examples include:

    • Amazon S3 object-level API activity

    • AWS Lambda function execution activity

    • Amazon DynamoDB object-level API activity on tables

  • Data events are not logged by default.

GuardDuty: Suppression Rules, Trusted IP Lists, and Threat Lists

Expect questions about suppression rules and how to add known IPs to trusted IP lists and threat lists during penetration testing.

• GuardDuty Suppression Rule Documentation

• GuardDuty Upload Lists Documentation

Understand which logs are analyzed by AWS GuardDuty. These include AWS CloudTrail management event logs, VPC Flow Logs, DNS logs, EKS audit logs, S3 data events, and runtime activity from EKS, EC2, and ECS workloads.

AWS Abuse Email

Know how to respond to an AWS abuse email.

• Review the abuse notice carefully to understand what content or activity was reported. The report typically includes logs or other evidence implicating the abusive activity.

• Investigate the reported issue within your AWS resources.

• Verify and understand the cause of the reported abuse.

• Take immediate action to stop or prevent the abusive activity. This may involve:

  • Removing or modifying offending content

  • Securing compromised resources

  • Updating security settings

  • Revoking unauthorized access

Inspector

You need to know which AWS services are scanned by AWS Inspector.

• Amazon Inspector can evaluate:

  • EC2 instances

  • Container images in Amazon ECR

  • Lambda functions for vulnerabilities and security issues

The following AWS services integrate with Amazon Inspector:

• AWS Security Hub for a centralized view of security findings

• Amazon EventBridge for automated responses to findings

• AWS Systems Manager for patch management based on Inspector findings

• Amazon Elastic Container Registry (ECR) for container image scanning

AWS Config

Learn these important AWS Config rules:

• encrypted-volumes: Checks if attached EBS volumes are encrypted.

• s3-bucket-public-read-prohibited: Ensures that your S3 buckets do not allow public read access.

• iam-user-no-policies-check: Verifies that IAM users don't have policies directly attached to them (best practice is to use group policies).

• root-account-mfa-enabled: Checks if the root account has Multi-Factor Authentication (MFA) enabled.

• ec2-instances-in-vpc: Ensures that all EC2 instances are launched within a VPC.

• cloudtrail-enabled: Verifies that CloudTrail is enabled in your account.

• rds-instance-public-access-check: Checks if RDS instances are not publicly accessible.

• iam-password-policy: Ensures that the account password policy meets specified complexity requirements.

• restricted-ssh: Checks if security groups allow unrestricted incoming SSH traffic.

• cloudwatch-alarm-action-check: Verifies if CloudWatch alarms have at least one alarm action, one INSUFFICIENT_DATA action, or one OK action enabled.

For more details, refer to the AWS Config Managed Rules documentation.

Trusted Advisor

Be aware of the checks performed by AWS Trusted Advisor:

• Security Groups - Specific Ports Unrestricted: Identifies security groups that allow unrestricted access to specific ports, potentially exposing your resources to security risks.

• IAM Use: Ensures that you're following security best practices by using IAM users, groups, and roles to control access to your AWS resources, rather than using your root account credentials.

• MFA on Root Account: Verifies if multi-factor authentication (MFA) is enabled on your AWS account's root user, significantly enhancing security.

• EBS Public Snapshots: Identifies EBS snapshots that are publicly accessible, which could lead to unintended data exposure.

• RDS Public Snapshots: Similar to the EBS check, identifies RDS snapshots that are publicly accessible.

• S3 Bucket Permissions: Checks for S3 buckets with open access permissions or those that allow access to any authenticated AWS user.

• CloudTrail Logging: Verifies if CloudTrail is enabled for all regions, crucial for maintaining an audit trail of actions taken on your AWS account.

• IAM Password Policy: Checks if your IAM password policy aligns with security best practices, such as minimum length and complexity requirements.

• Exposed Access Keys: Identifies if any of your AWS access keys have been exposed publicly on code repositories or other public sites.

• Security Groups - Unrestricted Access: Checks for security groups that allow unrestricted access (0.0.0.0/0) to specific ports.

S3 Encryption

Learn about the different use cases for S3 encryption options.

• Server-Side Encryption (SSE)

  • This is the default encryption method for all new buckets and objects.

  • Amazon S3 handles key management and encryption/decryption automatically.

  • Uses AES-256 encryption algorithm.

  • Each object is encrypted with a unique key, and the key itself is encrypted with a regularly rotated master key.

• SSE-KMS (Server-Side Encryption with AWS KMS-Managed Keys)

  • Uses AWS Key Management Service (KMS) for managing encryption keys.

  • Provides additional control and audit trail for your keys.

  • Allows you to use customer-managed keys (CMKs) or AWS managed keys.

  • Enables you to set key rotation policies and control key usage through IAM policies.

• SSE-C (Server-Side Encryption with Customer-Provided Keys)

  • You manage your own encryption keys.

  • S3 performs the encryption/decryption, but you provide the key with each request.

  • Keys are not managed by AWS; you must provide the correct key to access the object.

• Client-Side Encryption

  • Data is encrypted before sending it to S3.

  • You can use the Amazon S3 Encryption Client or implement your own client-side encryption.

  • Provides end-to-end encryption, as data is encrypted before leaving your application.

For more information, watch this video.

CloudFormation and Secrets

Using secrets in AWS CloudFormation is a great way to manage sensitive information securely. CloudFormation supports dynamic references to secrets stored in AWS Secrets Manager.

In the example below, MySecret:{{resolve:secretsmanager:SecretName:SecretKey:VersionStage:VersionId}} retrieves the 'password' field from the secret 'MySecretName' in Secrets Manager.

MySecret:
  Type: AWS::SecretsManager::Secret
  Properties:
    Name: MySecretName
    Description: "This is my secret"
    SecretString: '{"username":"myuser","password":"mypassword"}'

VPC FlowLog

Understand the use cases for using VPC flow logs.

• Identify unusual traffic patterns or unexpected denied connections.

• Detect potential security threats by identifying suspicious IP addresses or unusual port activity.

• You can set up automated alerts using CloudWatch Alarms for specific traffic patterns.

2 123456789010 eni-1234567890abcdef0 10.0.1.5 10.0.0.220 39812 80 6 20 4249 1418530010 1418530070 ACCEPT O

Let's break down this log entry:

1. Version number (2)

2. AWS account ID (123456789010)

3. Network interface ID (eni-1234567890abcdef0)

4. Source IP address (10.0.1.5)

5. Destination IP address (10.0.0.220)

6. Source port (39812)

7. Destination port (80)

8. Protocol (6 = TCP)

9. Packets transferred (20)

10. Bytes transferred (4249)

11. Start time (1418530010)

12. End time (1418530070)

13. Action (ACCEPT)

14. Log status (0)

S3 Glacier Vault Lock Policies and Archival Retrieval Options

S3 Glacier Vault Lock policies are a powerful feature for enforcing compliance controls on your Amazon S3 Glacier vaults. These policies allow you to create and lock down rules that control access to your archives, ensuring that your data retention and deletion policies are strictly enforced.

When initiating a job to retrieve an archive, you can specify one of the following retrieval options, based on your access time and cost requirements.

• Expedited: Expedited retrievals allow you to quickly access your data that's stored in the S3 Glacier Flexible Retrieval storage class or the S3 Intelligent-Tiering Archive Access tier when occasional urgent requests for restoring archives are required. For all but the largest archives (more than 250 MB), data accessed by using Expedited retrievals is typically made available within 1–5 minutes. Provisioned capacity ensures that retrieval capacity for Expedited retrievals is available when you need it.

• Standard: Standard retrievals allow you to access any of your archives within several hours. Standard retrievals are typically completed within 3–5 hours. Standard is the default option for retrieval requests that do not specify the retrieval option.

• Bulk: Bulk retrievals are the lowest-cost S3 Glacier retrieval option, which you can use to retrieve large amounts, even petabytes, of data inexpensively in a day. Bulk retrievals are typically completed within 5–12 hours.

RDS Copying Encrypted Snapshots

• You can’t share snapshots that are encrypted with the default AWS managed key. You can only share snapshots that are encrypted with a customer-managed key.

• You can share only unencrypted snapshots publicly.

• When you share an encrypted snapshot, you must also share the customer-managed key used to encrypt the snapshot.

• Since you cannot share a snapshot that is encrypted with the default AWS managed key, you can copy the snapshot first. When you copy a snapshot, you can encrypt the copy or you can specify a KMS key that is different than the original, and the resulting copied snapshot uses the new KMS key.

• Also, you cannot enable encrypt snapshots on existing RDS.

WAF Protections

Understand which layer AWS WAF operates on. AWS WAF (Web Application Firewall) mainly works at the application layer (Layer 7) of the OSI (Open Systems Interconnection) model.

AWS Config Aggregator

You can expect questions about AWS Config Aggregator. This feature lets you gather configuration and compliance data from multiple accounts and regions into one account, giving you a complete view of your AWS resources.

For more information, refer to the AWS Config Aggregator documentation.

AWS Macie

Learn how to categorize your data using Amazon Macie.

• Macie can automatically scan your S3 buckets to identify sensitive data such as personally identifiable information (PII), financial data, or intellectual property.

• Macie helps assess and monitor the security posture of your S3 buckets, identifying misconfigurations or overly permissive access policies.

• Automatically classify data based on its sensitivity, helping organizations manage and protect data according to its importance.

AWS CloudFront OAI

Learn how to restrict user access to content directly from S3.

To limit user access to content directly from S3 when using Amazon CloudFront, you can use Origin Access Identity (OAI). An OAI is a special CloudFront user that lets you restrict access to your S3 bucket content. When you create an OAI, CloudFront connects it to your distribution, and you can configure your S3 bucket to only allow access from that OAI.

AWS CloudHSM

Use AWS CloudHSM instead of KMS when you want complete control over key management hardware and keys.

AWS CloudHSM lets you manage and use your keys on FIPS-approved hardware. It uses customer-owned, single-tenant HSM instances that operate in your own Virtual Private Cloud (VPC). If you need full control over the Hardware Security Module (HSM) that stores and manages your cryptographic keys, CloudHSM is the better choice.

AWS KMS Key Types

Learn about the available KMS key types:

1. Symmetric Keys

   • AWS Managed Keys

   • Customer Managed Keys

2. Asymmetric Keys: These consist of a public and private key pair.

3. HMAC Keys: Used for generating and verifying Hash-based Message Authentication.

4. Multi-Region Keys: A set of interoperable keys that can be replicated across multiple AWS Regions. These are useful for encrypting data across multiple Regions or for disaster recovery scenarios.

5. Keys with Imported Key Material: Allows you to import your own key material into KMS.

6. Keys in Custom Key Stores: Enables you to create and manage KMS keys in an AWS CloudHSM cluster.

A Few Notes on AWS CloudTrail

1. Enable CloudTrail in all regions: To ensure thorough logging, activate CloudTrail in every AWS region. This gives you a complete record of activities across your entire AWS infrastructure.

2. Use a dedicated S3 bucket: Store CloudTrail logs in a specific S3 bucket with strict access controls. This helps prevent unauthorized access and ensures the integrity of your audit logs.

3. Enable log file integrity validation: This feature uses industry-standard algorithms to ensure that your log files haven't been tampered with after delivery to S3.

4. Encrypt log files: Use server-side encryption with AWS KMS managed keys (SSE-KMS) to secure your CloudTrail log files while they are stored. This provides an additional layer of security for your audit data.

5. For the S3 bucket that stores CloudTrail logs, enable Multi-Factor Authentication (MFA) Delete. This helps prevent unauthorized deletion of log files.

6. Use AWS Config rules to make sure CloudTrail is always turned on and set up correctly across all your accounts.

7. Regularly review and analyze your CloudTrail logs. Consider using AWS services like Amazon Athena or third-party SIEM tools for log analysis.

8. If you're using AWS Organizations, consider setting up organization-wide trails to centralize logging for all accounts in your organization.

S3 Replication

Learn how to replicate encrypted S3 objects across regions.

• Versioning must be enabled on both source and destination buckets.

• Create a replication role: Create an IAM role that allows S3 to assume the role and perform replication tasks.

• Attach a policy to the replication role: This policy should grant permissions to read from the source bucket and write to the destination bucket.

• You can set up replication using the AWS Management Console, AWS CLI.

• KMS Key Permissions: If you're using AWS KMS for encryption, you need to grant the replication role permission to use the KMS key in both the source and destination regions.

AWS Service Catalog

Learn about the use cases for AWS Service Catalog.

You can use AWS Service Catalog to standardize your applications and distribute them to your teams. For example, if you want to set restrictions on encryption and AMIs, you can create a complete application stack and share it with your team.

MFA for Active Directory Users

You can enable multi-factor authentication (MFA) for your AWS Managed Microsoft AD directory to increase security when your users specify their AD credentials to access supported Amazon Enterprise applications.

When you enable MFA, your users enter their username and password (first factor) as usual, and they must also enter an authentication code (the second factor) they obtain from your virtual or hardware MFA solution.

AWS IAM Access Analyzer

• Cross-Account Access Analysis: Helps identify resources that are shared with external AWS accounts, ensuring only intended cross-account access exists.

Conclusion

Getting the AWS Certified Security Specialty certification was a great experience that helped me learn more about AWS security. By studying and applying what I learned, I gained useful knowledge about keeping AWS environments secure.

This certification proved my skills and gave me the tools to use best practices in real situations. Whether you're new to AWS security or want to improve your skills, going for this certification can be an important part of your career growth.

I hope my experiences encourage and help you on your certification path. Keep in mind that ongoing learning and being active in the community are important to stay updated in the fast-changing world of cloud security.

However, have you ever attempted to troubleshoot your network by applying the OSI Model? Through the use of a bottom-to-top methodology that is based on the Open Systems Interconnection (OSI) architecture, we will uncover the complexities of network troubleshooting, providing you with the knowledge and tools that are essential for effectively addressing a wide variety of networking difficulties.

What is the OSI Model (Open Systems Interconnection)?

The Open Systems Interconnection (OSI) model is a conceptual framework that categorizes the functions of network communications into seven distinct levels. To put it simply, the OSI standardizes how various computer systems can communicate with one another.

seven layers of the OSI model

How to Troubleshoot a Website by Applying the OSI Model Principles

Consider the following example of troubleshooting a website hosted on your server that is not working. We'll use Linux as our operating system. I believe that the divide and rule is a better technique for debugging.

The OSI model is one method for efficiently breaking down an issue so that you can methodically simplify the environment in order to discover a solution and conquer it.

Physical Layer

As I previously stated, when it comes to debugging, it is usually preferable to begin from the bottom. The physical layer is the bottom layer in the OSI Model. The key components in this layer consist of ethernet cables, hubs, and switches. At this level, you should check the power supply and the status of devices, as well as examine interface statistics.

• The "ifconfig" tool provides a detailed overview of all the ethernet cards present in your system.
• In addition, you have a choice of using the "IP link show" commands. If the result shows "down," it suggests that layer1 is not functioning.
• Sometimes, ethernet connections may be physically connected to the server but not activated by default. To enable, use the command below.

IP link set eth0 up

• If you're looking for more detailed information, the ethtool utility can be quite helpful. This utility provides the ability to query and modify settings. It allows you to adjust parameters such as speed, port, auto-negotiation, PCI locations, and checksum offload.

Data Link Layer

The data link layer enables the transmission of data between two devices that are connected to the same network. There are two components in this layer. The first component is the medium access control (MAC) layer, which includes the operation of hardware addressing and access control.

The second layer is the logical link layer, which enables the creation of a logical connection between different media. A common issue in this layer is the inability of two servers to establish connectivity. Tools such as ping, traceroute, arp, macof, and Wireshark are utilized for testing the data link layer.

This may help in verifying correct transmission and reception of data frames among devices within the same network group.

Network Layer

The network layer's job is to make it easy for data to move between two networks. Network devices that work at Layer 3 of the OSI model are routers. A router's main job is to make it easier for networks to talk to each other. Working with IP addresses is part of this layer.

In this stage, you should mostly look for problems with IP addresses. You can type "ip -br address show" to see the address. You can see if your network card has been given an IP address. You might not be getting dynamic IP addresses from DHCP if you use it to get them.

One common problem that often comes is the lack of an upstream gateway for a specific route or the absence of a default route. When an IP packet is transmitted to a different network, it needs to be directed to a gateway for additional processing.

Understanding the routing of packets to their final destinations is crucial for the gateway. The routing table contains the list of gateways for various routes and can be managed using the “ip route” commands. We can also check connectivity by sending pings to the default gateway or beyond gateway.

Transport Layer

Protocols like Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are used by the transport layer to control network traffic between systems and make sure that data flows efficiently.

The transport layer is in charge of sending data packets, looking for errors, controlling the flow of data, and putting them in the right order. You may run into problems in this layer, like ports that aren't listening. Your service might not start because the port is already being used. You can see what ports are open by running "commad "netstat -antlp | grep "LISTEN"".

One problem that often occurs is related to remote connectivity. Consider a scenario where your local system is unable to establish a connection with a distant port, specifically HTTP on port 80. The telnet command tries to create a TCP connection with the specified host and port. This capability is ideal for conducting remote TCP connectivity testing.

To check a remote UDP port, you can utilize the "netcat" utility.

Session Layer

This layer is responsible for facilitating the initiation and termination of communication between the two devices (for example: authentication). The period of time during which communication is initiated and terminated is referred to as the session.

In this layer you should be investigating credentials, certificates of the servers, the session ID and cookies of the clients

Presentation Layer

The presentation layer of the OSI model is responsible for formatting and transforming data in a way that allows it to be presented to the user.

SSL or TLS encryption methods are key parts of this layer. Here, you should be examining for encryption and decryption issues.

Application Layer

The system takes input from the user and transmits output back to the user. The Bellow Protocols function at this level.

You should verify the configuration files on your server for any wrong settings. Additionally, it is essential to look at the log files on the servers to get more detailed information about the issues.

• File Transfer Protocol (FTP)
• Simple Mail Transfer Protocol (SMTP)
• Secure Shell (SSH)
• Internet Message Access Protocol (IMAP)
• Domain Name Service (DNS)
• Hypertext Transfer Protocol (HTTP).

Conclusion

Troubleshooting network issues in Linux can be a daunting task, but by applying the principles of the OSI model, you can systematically diagnose and resolve problems with greater efficiency.

Starting from the bottom layer and working your way up, we've explored various tools and techniques tailored to each level of the OSI model.

Beginning with the physical layer, we inspected hardware components and used tools like ifconfig and ip link show to verify connectivity. Moving up to the data link layer, we focused on MAC addresses and used utilities like ping and Wireshark for testing. At the network layer, we delved into IP addressing and routing, employing commands such as ip route and ping to diagnose issues.

Transitioning to the transport layer, we addressed TCP and UDP related problems, utilizing commands like netstat and telnet to check for open ports and establish connections. Further up the stack, we discussed the importance of session management and encryption at the session and presentation layers respectively.

Finally, at the application layer, we examined specific protocols like FTP, SMTP, SSH, and HTTP, emphasizing the significance of configuration files and log analysis in resolving issues.

The term "greenfield software project" refers to the development of a system for a new product that requires development from scratch with no legacy code.

This is a method you use when you are beginning from scratch and have no constraints or dependencies. You have a fantastic opportunity to build a solution from the ground up. The project is open to new tools and architectures.

I've been looking around the internet for ideas on how to put up a CI/CD pipeline for terraforming deployment. But I couldn't find a comprehensive end-to-end terraform deployment instruction.

The majority of the guides and blog posts I discovered discuss the deployment pipeline for single (Prod) environments. So I've chosen to build my personal lab project and turn it into a blog post.

In this article, I will discuss the entire Terraform deployment workflow from Development to Production environments. I will also present topics and techniques that I will be using in my lab assignment.

There are two reasons why I choose Terraform as my infrastructure as code tool. The first is that I've been using cloud formation for a long time and have a lot of experience with it, so I wanted to get some experience with Terraform.

The second reason I chose Terraform is that this is a greenfield DevOps project, so I can pick a modern technology and play with it.

I will go over some of the features of Terraform in this article. Let's get started.

Deployment Tools

Before we get into deployment patterns, I'd like to go over the tools I'll be using.

Terraform

Terraform is an open-source provisioning framework. It's a cross-platform application that can operate on Windows, Linux, and macOS.

You can use Terraform in three ways.

• Terraform OSS (Free)
• Terraform Cloud (Paid - Saas Model)
• Terraform Enterprise (Paid - Self Hosted)

What is Terraform Cloud?

For my lab project, I'm utilizing Terraform Cloud. Terraform OSS is fantastic for small teams, but as your team expands, so does the difficulty of administering Terraform. HashiCorp's Terraform Cloud is a commercial SaaS offering.

Terraform Cloud Offerings

• Remote Terraform workflow for teams.
• VCS Connection (GitHub, GitLab, Bitbucket) State Management (Storage, History, and Locking)
• Okta-integrated single sign-on (SSO) with a full user interface
• Terraform Cloud serves as your Terraform state's remote backend.
• Terraform Cloud incorporates the Sentinel policy-as-code framework, which lets you establish and enforce specific policies for how your business provisions infrastructure. You can limit the number of compute VMs, restrict important upgrades to predefined maintenance times, and perform a variety of other tasks.
• Terraform Cloud can show an estimate of its entire cost as well as any cost change caused by the proposed modifications.

GitHub Actions (CI/CD)

You can use Terraform CLI or Terraform console to deploy infrastructure from your laptop.

If you are a single team member, this may work for a while. But this strategy will not be scalable as your team grows in size. You must deploy from a centralized location where everyone has visibility, control, and rollback capabilities.

There are numerous technologies available for deployment from a centralized location (CI/CD). I intended to try Terraform pipeline deployment using the "GitOps" technique.

A Git repository serves as the single source of truth for infrastructure definitions in GitOps. For all infrastructure modifications, GitOps use merge requests as the change method. When new code is integrated, the CI/CD pipeline updates the environment. GitOps automatically overwrites any configuration drift, such as manual modifications or errors.

For my deployment, I'll be using GitHub Actions.

GitHub Actions lets you automate tasks throughout the software development lifecycle. GitHub Actions are event-driven, which means you can run a series of commands in response to a specific event.

For example, you can run a command that executes a testing script, plan script, and apply script every time someone writes a pull request for a repository. This allows you to incorporate continued integration (CI) and continuous deployment (CD) capabilities, as well as a variety of other features, directly in your repository.

Github Actions Features

• Github Actions are fully integrated into Github and can be controlled alongside your other repository-related features like pull requests and problems.
• They have Docker container support
• Github Actions are available for free for all repositories and feature 2000 free build minutes per month for all private repositories.

Check out this link to get more information about the actions available on GitHub.

So far, I've introduced the tools and services that I'll use in my deployment pipeline. Now I'll look into the Terraform directory structure.

To summarize, I will be using Terraform Cloud and GitHub Actions. Another thing to note is that I will not go into great length about writing Terraform code in this article. I'll be using code from the Terraform Registry. Thank you very much, Anton Babenko.

Setting Up the Project

Assume you've just started a new job and your first assignment is to create VPCs. They want you to set up three VPCs for them (Dev—>Stage—>Prod VPC). You've decided to use Terraform to deploy VPCs.

Terraform Directory Structure

Your first step should be to create Terraform's directory structure. You don't need to establish a directory structure if you've previously used cloud-formation because you don't need to handle state files or modules. But while using Terraform, it is critical to define the directory structure.

First, I'll provide several samples of commonly used directory structures, followed by information about the directory I'll be using in my project.

Basic Directory Structure

In this arrangement, you will have three files. Your major file is main.tf. This is the file in which all of the resources are defined.

{
  resource "aws_vpc" "this" {

  cidr_block = var.cidr
 }
}

variables.tf is where you define your input variables:

variable "cidr" {
 description = "The CIDR block for the VPC"
 type        = string
 default     = "10.0.0.0/16"
}

outputs.tf output values are defined in this file:

output "vpc_id" {
  description = "The ID of the VPC"
  value       = concat(aws_vpc.this.*.id, [""])[0]
}

If you're working on a modest project with a small team, this structure will work well. But as you use modules and work on larger projects, this structure will not be able to scale as well.

Complex and Scalable Directory Structure

You will not be able to scale your project or team with the basic directory structure.

Multiple habitats and areas will be required for the broader project. You'll need a decent directory structure to transfer infrastructure from development to production environments using a CI/CD solution. You can use Terraform Modules in this structure.

Modules are reusable Terraform configurations that can be called and configured by other configurations.

├── enviournments
│   ├── dev
│   │   ├── compute.tf
│   │   ├── dev.tfvars
│   │   ├── outputs.tf
│   │   ├── rds.tf
│   │   ├── s3.tf
│   │   ├── variables.tf
│   │   └── vpc.tf
│   ├── prod
│   │   ├── compute.tf
│   │   ├── outputs.tf
│   │   ├── prod.tfvars
│   │   ├── rds.tf
│   │   ├── s3.tf
│   │   ├── variables.tf
│   │   └── vpc.tf
│   └── stage
│       ├── compute.tf
│       ├── outputs.tf
│       ├── rds.tf
│       ├── s3.tf
│       ├── stage.tfvars
│       ├── variables.tf
│       └── vpc.tf
└── modules
    ├── compute
    │   ├── main.tf
    │   ├── outputs.tf
    │   └── variables.tf
    ├── rds
    │   ├── main.tf
    │   ├── outputs.tf
    │   └── variables.tf
    ├── s3
    │   ├── main.tf
    │   ├── outputs.tf
    │   └── variables.tf
    ├── security-group
    │   ├── main.tf
    │   ├── outputs.tf
    │   └── variables.tf
    └── vpc
        ├── main.tf
        ├── outputs.tf
        └── variables.tf

I've noticed a lot of projects use this structure. In this case, the contents of each environment will be nearly identical.

But in my opinion, content should be the same across all environments. For all environments, we should use the same main.tf file. Variables can be used to adjust the number of servers or number of subnets.

variable "instance_count" {
  description = "Numbers of servers count"
}

variable "instance_type" {
  description = "Instance Size (t2.micro,t2.large"
}

Proposed Directory Structure

Having a separate folder and separate configuration file, as I described in the prior section, makes little sense. You can get in touch if you believe there is an advantage to having a different folder for each setting.

As a result, below is my proposed directory layout for VPC deployment.

VPC: github.com/nitheesh86/network-vpc

Security Group: github.com/nitheesh86/network-sg

Compute-ASG: github.com/nitheesh86/compute-asg

You may be wondering how you will reference resources from multiple repositories. This is where Terraform cloud workspace will come in handy. I'll go through this in more detail later in the article.

If you look at the above directory, you might assume it looks like a "Basic Directory Structure." You may also be asking where module directories are. Yes, directories seem the same, but the magic happens within the configuration files.

terraform {
  required_version = "~> 0.12"
  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "xxxxxxxx"
    workspaces { prefix = "vpc-" }
  }
}

provider "aws" {
  region = "ap-south-1"
}


module "vpc" {
  source = "github.com/nitheesh86/terraform-modules/modules/vpc"

  name = var.name
  cidr = "10.0.0.0/16"

  azs             = ["ap-south-1a", "ap-south-1b", "ap-south-1c"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]

  enable_nat_gateway = true
  enable_vpn_gateway = true

  tags = {
    Terraform   = "true"
    Environment = var.env
  }
}

I maintained modules separate from setups. My modules are all placed in a separate repository. I'll refer to that module by its Git repo URL.

The source argument in a module block tells Terraform where to find the source code for the desired child module.

Terraform supports sources in the following modules:

• Local paths
• Terraform Registry
• GitHub
• Bitbucket
• Generic Git, Mercurial repositories
• HTTP URLs
• S3 buckets
• GCS buckets

We can use the Terraform registry as a module source because we are using Terraform Cloud. However, each module needs its own git repository. If you're publishing vpc modules (terraform-aws-vpc), for example, you can only provide code for those vpc resources that are relevant to the module. Another repo is needed for the security group module (terraform-aws-sg).

One module per repository. The registry cannot use combined repositories with multiple modules.

However, it is worth considering this structure if your organization has a separate network, security, and compute team. Each team can handle their modules independently.

Terraform Cloud Components

Organizations

Organizations are a shared place in Terraform Cloud for teams to collaborate on workspaces. Remote state setups can be shared between organizations.

You can, for example, build companies based on a project or a product. Like if you are attempting to create an Apple product, you can name it "apple." "nitheeshp" is the name I gave to my project.

WorkSpaces

Instead of directories, Terraform Cloud maintains infrastructure collections using workspaces. A workspace is related to contexts such as dev, staging, and prod.

Terraform configurations, variable values, and state files connected with an environment are all stored in the workspace. Each workspace keeps backups of earlier state files.

In my project, I set up a workspace for each Amazon Web Services service. Each workspace can be linked to a Git branch or Git repo.

When you create a workspace, you have three options for designing your Terraform workflow:

• Version Control Workflow
• CLI-Driven Workflow
• API-Driven Workflow

If you look at my Terraform directory structure below, you'll notice that I haven't set any default values for my variables. Variables have been related in Terraform workspace settings.

If you look at main.tf, you'll notice that all environments use the same Terraform cloud-config. You may be curious as to how I go about making modifications to a certain workspace. The workspace prefix is what I'm using.

terraform {
  required_version = "~> 0.12"
  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "nitheeshp"
    workspaces { prefix = "vpc-" }
  }
}

When you add a workspace to your configuration, it will prompt you to choose a workspace. As an example:

$ terraform init

Initializing the backend...

Successfully configured the backend "remote"! Terraform will automatically
use this backend unless the backend configuration changes.

The currently selected workspace (default) does not exist.
  This is expected behaviour when the selected workspace did not have an
  existing non-empty state. Please enter a number to select a workspace:

  1. dev
  2. stage
  3. prod

  Enter a value:

Set the TF WORKSPACE environment variable to the workspace name you want to be selected when using Terraform in CI/CD.

export TF_WORKSPACE="dev"`

How to Deploy Security Groups

As previously stated, I deploy security groups using a separate repo and workspace. A VPC id is required for the deployment of security groups. This is where Terraform data sources come in.

Data sources allow data to be fetched or computed for use elsewhere in Terraform configuration. The use of data sources allows a Terraform configuration to make use of information defined outside of Terraform, or defined by another separate Terraform configuration.

data "terraform_remote_state" "vpc" {
  backend = "remote"

  config = {
    organization = "nitheeshp"
    workspaces = {
     name = "vpc-${var.env}"
    }
  }
}

provider "aws" {
  region = "ap-south-1"
}


module "elb_sg" {
  source = "terraform-aws-modules/security-group/aws"

  name        = "${var.env}-elb-sg"
  description = "elb security group."
  vpc_id      = data.terraform_remote_state.vpc.outputs.vpc_id

  egress_with_cidr_blocks = [
    {
      from_port   = 0
      to_port     = 65535
      protocol    = "all"
      description = "Open internet"
      cidr_blocks = "0.0.0.0/0"
    }
  ]

As you can see, I'm getting the VPC id from the vpc-dev workspace.

vpc_id      = data.terraform_remote_state.vpc.outputs.vpc_id

GitHub Actions

As we discussed above, we'll also use GitHub Actions in our deployment pipeline.

GitHub Actions makes it simple to automate all of your CI/CD workflows. You can build, test, and deploy code directly from your GitHub repository. You can also make code reviews, branch management, and issue triaging the way you want them to function. Github Actions offers free plans.

GitOps and Terraform WorkFlow

• Each service has its own repository (Network-VPC, Network-Security Groups, Compute-ASG, Compute-EC2)
• I've made three branches (Develop, Stage and Prod). Each branch reflects one of our actual infrastructure environments or workplace terraforms.
• Workflow begins when the DevOps engineer begins to make modifications to the infrastructure.
• A DevOps engineer develops a feature branch from the master (production) branch
• Make your changes and submit a pull request to the branch's development team.

I made a separate workflow for each branch (terraform-develop.yml,terraform-stage.yml,terraform-prod.yml). The workflow is a procedure that you add to your repository.

Workflows consist of one or more jobs that can be scheduled or triggered by an event. You can use the workflow to create, test, package, release, or deploy a GitHub project.

GitWorkFlow will:

• Check out feature branch code.
• Check for syntax.
• Initialise Terraform.
• Generate a plan for every pull requests.
• When a pull request is merged with the develop branch, it deploys the resources to the development environment.
• Deploy the changes Development Branch.
• Again create pull requests to stage branch and same to prod branch.

Here are the GitHub repos for this project if you want to take a look:

• github.com/nitheesh86/network-vpc
• github.com/nitheesh86/network-sg
• github.com/nitheesh86/terraform-modules

I would love to learn more about your Terraform deployment methods. Please get in touch with me if you'd like to share them and discuss further.

I recently passed my certified Kubernetes administrator exam, and I would like to share my learning experience and resources with you.

Should You Get Kubernetes Certified?

There are mixed opinions in the tech industry about the importance of certifications. Some people argue that the certificates you have doesn't matter – it's all about your real-world knowledge.

But not everyone has the chance to work with real-world projects. And certification questions are based on real-world scenarios. So if you haven't had an opportunity to work with Kubernetes much in practice, you can learn from this exam and apply your learnings on actual projects.

On the other hand, if you're already working with Kubernetes, taking the exam is an excellent chance to test your knowledge and learn more about its internal workings.

For example, you might have beren working with AWS for quite some time, but you haven't touched AWS costing, or haven't been following best practices. The certification covers every aspect of Kubernetes, so you will learn how you can reduce your cost or follow best practices.

In this study guide, I will not explain Kubernetes architecture or Kubernetes objects (Pods, Deployments, Services, Config, Secrets, and so on) in detail. If you want to dig into those topics, here are some helpful Kubernetes learning resources:

• Learn Kubernetes in 3 hours
• The Kubernetes Handbook

What is the Certified Kubernates Administor?

The CKA is a product of the Cloud Native Computing Foundation (CNCF). It launched this certification collaboration with the Linux Foundation. Other certifications offered by CNCFcf are:

• Kubernetes and Cloud Native Associate (KCNA)
• Certified Kubernetes Application Developer (CKAD)
• Certified Kubernetes Security Specialist (CKS)

As per the CNCF foundation,

"The purpose of the Certified Kubernetes Administrator (CKA) program is to provide assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators."

Here's what we'll cover in this study guide:

• Exam Details
• Exam Tips
• Exam Modules
• Cluster Architecture, Installation, and Configuration
• Workloads and Scheduling
• Services and Networking
• Storage
• Troubleshooting

Alright, let's dive in.

Certified Kubernetes Administrator Exam Details

Here's some helpful information to get you started preparing and planning for the exam.

First, keep in mind that this is an online proctored exam, which means you can take it from your home or office. There are no exam centers.

Exam fees are $375, but the Linux foundation offers discount vouchers from time to time. Keep watching this space to find them.

The CKA exam is a problem-based exam, and you'll solve those problems right in command line or by writing manifesto files.

It is a 2 hours exam, and you need solve 17 questions. A passing score is 66%. Each question will have different weights, like 4%, 5%, 7%, 13% and so on.

Some questions will have two parts. If you just get the first part correct, those points for the correct part will still be added to your score.

The CKA exam is an open-book exam. You have access to the below resources:

• https://kubernetes.io/docs/
• https://github.com/kubernetes
• https://kubernetes.io/blog/

If you don't pass on your first try, you get one retake.

The CKA certification is valid for three years.

Certified Kubernetes Administrator Exam Tips

To get you started, here's a handy kubectl cheat sheet you can use during the exam.

You can create an alias for it so that you don't need to type the full command. For example, if you create an alias like "alias k=kubectl," you can type "k" instead of "kubectl."

During the exam, avoid creating Kubernetes resources using YAML files, as this takes too much time. Instead, use an imperative command to create resources.

For example, to ceate a pod use this command:

kubectl run nginx --image=nginx

If you still want to create a resource using YAML files, use dry-run=client.

Make sure you study the basis of curl and systemctl, as they'll show up on the exam.

Finally, there are around 6 or 8 different clusters setup for the exam. Make sure you switch contexts before solving the problem. The context switch command will be provided at the start of each question.

Certified Kubernetes Administrator Exam Modules

There are five modules in the exam:

• Cluster Architecture, Installation, and Configuration
• Workloads and Scheduling
• Services and Networking
• Storage
• Troubleshooting

We'll look at each of them in a bit more detail, and cover some other important and related info along the way.

Impertive vs Declarative statements

You need to know the difference between imperative and declarative statements so you can decide when to use each of them.

Deploying the Kubernetes resource imperatively means running kubectl commands, for example, kubectl run nginx --image=nginx. Deploying declaratively means writing manifests using YAML, for example kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml.

Deploying resources using the imperative method helps during the exam and saves you time.

Cluster Architecture, Installation & Configuration Module

You can expect 25% of questions on the exam to come from this section. If you want to get a good score on this section, make sure you review these topics thoroughly.

This module mostly focuses on authentication, upgrading your cluster version, backing up Kubernetes data, and setting up a cluster using kubeadm.

Role-based access control (RBAC)

Understanding role-based access control (RBAC) is essential. RBAC restricts access to computers or networks based on the individual's role. Roles include policies or rules defining who can do what within the Kubernetes cluster.

Here's a relevant section on ClusterRole and CluserRole Binding you can check out.

Example questions will be like this:

Create a new service account named "sa" in the development namespace. Create a cluster role called "pod-reader," having permission to get pod and list pods. "sa" should be able to get pod and list pods.

So how would you tackle a question like this?

First, you need to create a namespace called "development" and create a service called "sa" in the development workspace:

kubectl create namespace development
kubecrl create serviceaccount sa -n development
kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
kubectl create clusterrolebinding pod-reader --clusterrole=pod-reader --serviceaccount=development:sa

You can test if the sa is allowed to read pods using the below command:

kubectl auth can-i list pods --development target --as system:serviceaccount:development:sa

How to install and configure a Kubernetes cluster using kubeadm

Kubeadm automates the installation and configuration of Kubernetes components like Control Manager, API server, and KubeDNS.

If you have time, I highly recommend building a Kubernetes cluster using the Kubernetes the Hard Way guide designed by Kelsey Hightower.

If you don't have time to go through the complete guide, from the exam point of view just study certification location and Kubernetes Config Path.

How to Upgrade Your Kubernetes Cluster Version

It's very likely you will get this question, as it is specifically mentioned in the exam syllabus.

Below are steps to upgrade the cluster version from 1.22.21 to 1.22.22. You might be also asked to upgrade Kubelet and Kube proxy versions too.

• Check the current version of cluster, kubeadm, and kubelet:

kubectl get nodes -o wide
kubeadm version
kubectl version

• Upgrade the control plane nodes first:

apt-get update && apt-get install -y kubeadm=1.2.22-00

• Verify the upgrade plan. Use the below command to see if the cluster can be upgraded:

kubeadm upgrade plan

• Apply the upgraded version:

sudo kubeadm upgrade apply v1.22.0

Once the command finishes, you should be able to see "upgrade/successful SUCCESS! Your cluster was upgraded to "v1.22.0". Enjoy!"

• Prepare the node for maintenance by marking it unschedulable and evicting the workloads:

kubectl drain node01 --ignore-daemonsets

• Next upgrade the kubelet and kubectl:

apt-get update && apt-get install -y kubelet=1.22.0-00 kubectl=1.22.0-00

• At last restart the kubelet and check if the desired version was upgraded:

sudo systemctl daemon-reload
sudo systemctl restart kubelet
kubectl get nodes -o wide
kubeadm version
kubectl version

• Bring the node back online by marking it schedulable:

  kubectl uncordon node01
  

How to Backup and Restore an ETCD Cluster

ETCD is a consistent, distributed key-value store that provides a reliable way to store data that a distributed system or cluster of machines needs to be accessed.

Kubernetes uses etcd to keep all its config and data. You can think of it as a database of Kubernetes. When you run "kubectl get pods", the results are fetched from etcd. In the exam the certification name and path are provided

• Login to the master node and run the below command to backup the etcd:

etcdctl snapshot save /tmp/etcd-backup.db  --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key

• Test your backup file:

ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshotdb

• Restore etcd from a backup file:

ETCDCTL_API=3 etcdctl snapshot restore tmp/etcd-backup.db  --data-dir /var/lib/etcd-backup --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key

Workloads & Scheduling Module

In this section you will get questions about deploying a Kubernetes application, creating daemonsets, scaling the application, configuring health checks, multi-container pods, and using config maps and secrets in a pod.

How to deploy an application and expose the app using a service

Example questions for deploying an app and creating a service might look like this:

Create a deployment as follows: Name: nginx Exposed via a service nginx using CluserIP Ensure that the service & pod are accessible within the cluster

• Manifesto file for creating deployment:

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  name: nginx-deployment
  labels:
    app: nginx
  spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  

Run kubectl get deployments to check if the Deployment was created. If the deployment is sucessfull "Ready" should show 3/3. Ready displays how many replicas of the application are available to your users.

If you need to expose your application outside the cluster or inside the cluster, you need to create a service. There are different options available to expose your application as per your needs.

• ClusterIP: Exposes application within cluster. For example exposing a database to a backend application.
• NodePort: Exposes application outside the cluster using node ip. For exmaple exposing your frontend application to the outside world.
• LoadBalancer: Exposes application outside the cluster using a load balancer.

How about an example of exposing your application using ClusterIP (within the cluster). You can create a service using the below manifesto file:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

You can use "kubectl get service" to see the IP address of the service.

Here's an example of exposing your application using NodePort (outside the cluster). You can create a service using the below manifesto file:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

You can use "kubectl get service" to see the IP address of the node.

Another sample question will be like this:

Schedule the pod on a node labeled with distype=ssd

Here you can use node-selector like this:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector:
    disktype: ssd

How to scale and update the deployments

If you need to scale the deployment after creating it, you can use the below command.

kubectl scale deployment/nginx-deployment --replicas=6

You can update the image of the existing deployment using the below command:

kubectl set image deployment/nginx-deployment nginx=nginx:1.8

How to configure healthcecks for your application

Once your application is deployed, you need to make sure that the app is running successfully. If an application crashes, you need to know how you can kill the container and bring in the new one.

Health checks help to achieve this use case. There the three different types of health checks you can perform:

• Readiness Probe: Kubernates uses readiness probes to know when a container is ready to start accepting traffic.
• Liveness Probe: Kubernates uses liveness probes to check when to restart a container. Once the application is deployed succesfully, if it crashes in between, a liveness probe will detect and restart the application.
• Startup Probe: Kubernates uses startup probes to know when a container application has started.

Example of configuring a livenss probe:

kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml

Example of configuring a readines probe:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

MultiContainer pod/sidecar containers

The primary purpose of a multi-container pod is to support a co-located helper container for the main program.

The standard logging method for containerized applications is writing to standard output and standard error streams.

There might be use cases where you also need to access these logs after a container crashes. For example, your NGINX designed for serving the web page is not suitable for shipping the logs to a centralized logging solution.

You can set up a sidecar container that specialises in log shipping. The sidecar container is designed as a logging agent, which is configured to pick up logs from an application container.

Example questions about this topic will be like this:

Create a Pod with the main container NGINX, which outputs logs to shared volume, and configure the sidecar container to stream those logs. Verify both containers are running.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-server
spec:
  volumes:
    - name: shared-logs
      emptyDir: {}

  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

    - name: sidecar-container
      image: busybox
      command: ["sh","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done"]
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

How to configure a pod to use a ConfigMap

ConfigMaps store data in key-value format. A possible usecase of ConfigMaps is keeping application code and configuration separate.

ConfigMaps are designed to store non-confidential data such as environment variables or properties of a game or application. If you want to store sensitive data, use secrets.

ConfigMaps help create separate config files for each environment (development, staging, prod).

You can create ConfigMaps from files, directories, and literal values. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume.

Example questions will be like this:

Create a ConfigMap called cfg-data with values var1=val1,var2=val2 and create a busybox pod with volume config-volume, which reads data from this ConfigMap cfg-volume and put it on the path /etc/cfg

kubectl create configmap cfg-data --from-literal=key1=val1 --from-literal=key2=val2 --from-literal=key3=val3
kubectl create -f https://github.com/nitheesh86/cka/blob/main/deployments-services/configmap.yml

How to configure a pod to use secrets

Secrets in Kubernetes can be used to store sensitive data such as passwords and tokens. Secrets are similar to ConfigMaps but are specifically designed to hold sensitive data. Pods can use secrets as an environment variable or as files in a volume.

• Example questions about secrets will be like this:

Create a secret named "db-secret" in namespace database. The secret should contain db_user=root and pass=1234. Mount it as ready only into the pod named "mysql-db" as an enviournment variable.

kubectl create namespace database
kubectl -n secret create secret generic db-secret --from-literal=username=db_user --from-literal=db_pass=1234 -n database

https://github.com/nitheesh86/cka/blob/main/deployments-services/mysql-secret.yml

Services and Networking Module

In this section you will get questions about creating networking polices, creating ingress controllers, and exposing apps through services (already covered in above)

How to creating networking policies

In Kubernetes, by default, communication between all pods is allowed. If you need to isolate pods, you need to apply a network policy.

Example questions about netowrking policies will be like this:

Allow traffic from production namespace only:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-traffic-from-namespace
spec:
  podSelector:
    matchLabels:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production

This policy will allow traffic to all pods from the production namespace.

How to create an ingress resource

An ingress controller is a type of load balancer. It accepts traffic from outside the cluster and loads the balance to pods. We can also configure rules like redirections.

• How to create an ingress using NGINX ingress controller:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ngress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /example
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

Storage Module

This section is all about creating persistence volume, persistence volume claims, and mounting into to a pod. It's helpful to study a lot about persistence and persistence volume.

A PersistentVolume (PV) is a storage in the cluster that has been provisioned by a stroage administrator or dynamically provisioned using Storage Classes like AWSElasticBlockStore, AzureDisk, and so on.

A PersistentVolumeClaim (PVC) is a request for storage by a user or Pod.

Example questions will be like this:

Create an NGINX Pod and mount index.html as PersistentVolume.

• ssh into the node and create a /mnt/data directory and then create an index.html file:

sudo mkdir /mnt/data
sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.htm

• Create PersistentVolume and PersistentVolume Claim:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

• Now, the config pod uses the PersistentVolume Claim

apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

Also, in the exam, you might be asked to expand PersistentVolume. Some storage classes support resizing the volume—for example, AWS-EBS, GCE-PD, Azure Disk, Azure File, Glusterfs.

If the storage class is not enabled, you need to set it to "allowVolumeExpansion: true."

Get the storage class name you want to expand with "kubectl get storage classes". Then edit the YAML file.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
parameters:
  type: pd-standard
provisioner: kubernetes.io/gce-pd
allowVolumeExpansion: true
reclaimPolicy: Delete

• Then edit PVC to request more space:

  kubectl edit pvc myclaim and update request parameter
  

  

• Once PVC is updated, you need to replace the pod to change to effect. You can check the new size by "kubectl get pvc. myclaim".

Troubleshooting Module

This part covers 30% of the exam. You can expect questions about how to troubleshoot nodes.

Example questions will be like this:

One of the worker nodes in cluster is not in a ready state. Troubleshoot the node and bring it online.

To Troubleshoot a worker node, you need to know what components are running. Worker nodes consist of kubelet and kube-proxy. Typically, one of these services will have issues.

First, check if the service is running and try restarting. If restarting the service is not working, check the logs.

• var/log/kubelet.log - Kubelet, responsible for running containers on the node
• /var/log/kube-proxy.log - Kube Proxy, responsible for service load balancing

You can refer to the below link for a detailed trooubleshooting guide:

https://kubernetes.io/docs/tasks/debug-application-cluster/debug-cluster/

How to Verify Your Answers on the Exam

It is very important verify your answers on the exam questions. Here are the ways to verify your answers:

Check your pods

After you create a pod, make sure it's in the ready state with the command kubectl get pod nginx.

If your pods are not in a ready state, run kubectl desribe pod nginx to see the events. You can also check the pod logs by running kubectllogs nginx.

Check deployment status

Once you create a deployment you can get the deployment status by running kubectl get deployments nginx-deployment.

If your depoyment is in pending state you can view events by running kubectl deployment deployment nginx-deployment.

Verify services

You can verify that your service endpoints are working by launching helper pods with the image "busybox".

You can ssh into the helper pod with the command kubectl exec --stdin --tty busybox -- /bin/bash and then query the endpoint curl http://ipaddress/.

You can get the service endpoint by running kubectl get svc my-service. Here's a reference where you can study more about logging into the container.

And that's it!

Good luck studying for the exam! I hope this guide helps you prepare and pass.

These are the main sources and references I used to study and to write this article:

• https://kubernetes.io/
• https://www.cncf.io/
• https://github.com/ahmetb/kubernetes-network-policy-recipes
• https://www.katacoda.com/courses/kubernetes
• https://jenciso.github.io/personal/manage-tls-certificates-for-kubernetes-users

Thank you for reading, and happy learning.