📖 Introduction

In the previous article, we learned how GitLab Runners execute CI/CD pipelines and how to configure Self-Hosted Runners.

Now it's time to learn one of the most important topics in GitLab CI/CD—Variables, Secrets, and Artifacts.

Instead of hardcoding sensitive information like API keys, passwords, or cloud credentials, GitLab provides a secure way to manage them using CI/CD Variables. You'll also learn how to store build outputs using Artifacts and follow best practices for building secure and maintainable pipelines.

By the end of this article, you'll be able to create more secure, production-ready GitLab CI/CD pipelines.

🎯 What You'll Learn

After completing this article, you'll understand:

• ✅ What are CI/CD Variables?

• ✅ Protected Variables

• ✅ Masked Variables

• ✅ Expanded Variables

• ✅ Secrets Management

• ✅ Artifacts

• ✅ Artifact Expiry

• ✅ Common CI/CD Errors

• ✅ CI/CD Best Practices

📚 Prerequisites

Before continuing, make sure you have:

• A GitLab account

• A GitLab repository

• A working GitLab CI/CD pipeline

• Basic knowledge of GitLab CI/CD

🔐 What are CI/CD Variables?

CI/CD Variables are key-value pairs used to store configuration values and sensitive information securely. Instead of hardcoding values inside the .gitlab-ci.yml file, you can store them as variables and use them during pipeline execution.

For example, instead of writing an API key directly in your pipeline, you can reference it as a variable.

variables:
  APP_NAME: "GitLab Practice"

build:
  script:
    - echo $APP_NAME

🛡️ Protected Variables

Protected Variables are only available to pipelines running on protected branches or protected tags.

They are commonly used for production credentials such as:

• Production API Keys

• Database Passwords

• Cloud Credentials

This prevents sensitive data from being exposed in feature branches.

🙈 Masked Variables

Masked Variables hide sensitive values from pipeline logs.

For example, if a variable contains an API key or password, GitLab replaces the actual value with **** in the job logs.

This helps prevent accidental exposure of secrets.

🔄 Expanded Variables

Expanded Variables allow one variable to reference another.

Example:

variables:
  APP_NAME: "gitlab-app"
  IMAGE_NAME: "$APP_NAME:v1"

GitLab automatically expands the referenced value during pipeline execution.

🔑 Secrets Management

Sensitive information such as passwords, API keys, AWS credentials, and database URLs should never be stored directly in your repository.

Instead, save them in Settings → CI/CD → Variables and reference them inside your pipeline.

deploy:
  script:
    - echo "$AWS_ACCESS_KEY_ID"

📦 Artifacts

Artifacts are files generated during a pipeline that can be stored and downloaded after a job completes.

Common examples include:

• Build output

• Reports

• Log files

• Test results

Example:

build:
  script:
    - mkdir dist
    - echo "Build Complete" > dist/output.txt

  artifacts:
    paths:
      - dist/

⏳ Artifact Expiry

Artifacts can be configured to expire automatically after a specific period.

artifacts:
  paths:
    - dist/
  expire_in: 7 days

⚠️ Common CI/CD Errors

Some common issues you may encounter include:

• Invalid .gitlab-ci.yml syntax

• Runner Offline

• Missing CI/CD Variables

• Permission Denied

• Pipeline Failed

Review the pipeline logs to identify and resolve these errors quickly.

✅ Best Practices

• Store secrets using CI/CD Variables.

• Never hardcode passwords or tokens.

• Use Protected Variables for production.

• Mask sensitive credentials.

• Configure artifact expiry.

• Validate your .gitlab-ci.yml before deployment.

🎯 Summary

Congratulations! 🎉 You have completed Day 6 of the GitLab learning series.

In this article, you learned how to securely manage CI/CD Variables, protect sensitive information using Protected and Masked Variables, use Artifacts to store build outputs, configure Artifact Expiry, and follow CI/CD best practices for production-ready pipelines.

🎉 Congratulations!

You have successfully completed the GitLab DevOps Learning Series.

You now have a solid understanding of GitLab fundamentals, repositories, CI/CD pipelines, GitLab Runners, Variables, Secrets, and Artifacts. These concepts provide a strong foundation for building secure and production-ready DevOps workflows using GitLab.

📖 Introduction

In the previous article, we created our first GitLab CI/CD pipeline and learned how pipelines, stages, and jobs work.

But one important question remains:

Who actually executes these pipeline jobs?

The answer is GitLab Runner.

A GitLab Runner is responsible for executing the jobs defined in your .gitlab-ci.yml file. Whenever a pipeline is triggered, GitLab assigns the jobs to an available runner, which performs the required tasks and reports the results back to GitLab.

In this article, you'll learn how GitLab Runners work, the difference between Hosted and Self-Hosted Runners, how to register a runner, use runner tags, and optimize pipelines with parallel jobs.

🎯 What You'll Learn

After completing this article, you'll understand:

• ✅ What is a GitLab Runner?

• ✅ Why GitLab Runners are Required

• ✅ How GitLab Runners Work

• ✅ GitLab Runner Architecture

• ✅ Hosted Runner vs Self-Hosted Runner

• ✅ Registering a GitLab Runner

• ✅ Runner Tags

• ✅ Pipeline Editor

• ✅ Parallel Jobs

📚 Prerequisites

Before continuing, make sure you have:

• A GitLab account

• A GitLab repository

• A working GitLab CI/CD pipeline (Day 4)

• Basic knowledge of Git and GitLab

🚀 What is a GitLab Runner?

A GitLab Runner is an application that executes the jobs defined in your .gitlab-ci.yml file.

Whenever a pipeline is triggered, GitLab sends the job to an available runner. The runner executes the commands, collects the results, and sends the status back to GitLab.

Without a GitLab Runner, a pipeline cannot execute any jobs.

❓ Why Do We Need a GitLab Runner?

GitLab is responsible for creating and managing pipelines, but it does not execute the jobs itself.

Whenever a pipeline is triggered, GitLab sends each job to an available GitLab Runner. The runner then executes the commands defined in the .gitlab-ci.yml file and returns the results to GitLab.

Without a runner, the pipeline will remain in a Pending state because there is no machine available to execute the jobs.

⚙️ How GitLab Runner Works

Whenever a developer pushes code, GitLab creates a pipeline based on the .gitlab-ci.yml file. It then assigns each job to an available GitLab Runner.

The runner executes the job, collects the output, and sends the execution status back to GitLab. The pipeline is updated automatically with the job results.

🏛️ GitLab Runner Architecture

GitLab Runner works as a bridge between GitLab and the machine where your jobs are executed.

When a pipeline is triggered, GitLab sends the job to an available runner. The runner uses an Executor (such as Docker or Shell) to execute the job and then sends the results back to GitLab.

The architecture looks like this:

🧩 Components of the Architecture

• GitLab Server → Creates and manages pipelines.

• GitLab Runner → Receives and executes jobs.

• Executor → Runs the job using Docker, Shell, Kubernetes, or another supported environment.

• Job → The commands defined in the .gitlab-ci.yml file.

☁️ Hosted Runner vs Self-Hosted Runner

GitLab provides two types of runners to execute CI/CD jobs: Hosted Runners and Self-Hosted Runners.

The main difference is where the runner is managed.

• Hosted Runners are managed by GitLab, so you don't need to install or maintain them.

• Self-Hosted Runners are installed and managed by you on your own infrastructure, such as a Virtual Machine, physical server, or Kubernetes cluster.

📊 Hosted Runner vs Self-Hosted Runner

🚀 Hosted Runner

Hosted Runners are ready to use and require no installation. GitLab automatically provisions the infrastructure needed to execute your pipeline jobs.

They are ideal for learning GitLab, personal projects, and small teams.

🖥️ Self-Hosted Runner

A Self-Hosted Runner is installed on your own machine or server. It gives you complete control over the execution environment, allowing you to install custom tools, access private networks, and optimize performance.

Most production environments use Self-Hosted Runners because they offer greater flexibility and security.

💼 Real-World Example

A startup building a portfolio website may use Hosted Runners because they're simple to set up.

A company deploying applications to a private Kubernetes cluster or AWS environment typically uses Self-Hosted Runners to securely access internal resources and customize the execution environment.

🛠️ Registering a GitLab Runner

To use a Self-Hosted Runner, you first need to register it with your GitLab project. During registration, the runner connects to GitLab and becomes available to execute pipeline jobs.

Step 1: Install GitLab Runner

Install GitLab Runner on your Linux server by following the official installation steps for your operating system.

Step 2: Get the Registration Token

In your GitLab project, navigate to:

Settings → CI/CD → Runners

Copy the Runner Authentication Token (or registration token, depending on your GitLab version).

Step 3: Register the Runner

Run the following command on your server:

sudo gitlab-runner register

During registration, you'll be asked to provide:

• GitLab instance URL

• Runner Authentication Token

• Runner name

• Executor (Docker, Shell, Kubernetes, etc.)

After successful registration, the runner will appear in your project's Runners section.

🏷️ Runner Tags

• What are Runner Tags?

• Why Runner Tags are used

• Assigning tags while registering a runner

• Using tags in .gitlab-ci.yml

• Practical example

build:
  tags:
    - docker
  script:
    - echo "Running on Docker Runner"

📝 Pipeline Editor

• What is Pipeline Editor?

• Where to find it

• Creating/editing .gitlab-ci.yml

• Validate CI/CD configuration

• Commit changes directly from GitLab

⚡ Parallel Jobs

Explain that multiple jobs in the same stage can run simultaneously.

stages:
  - test

unit_test:
  stage: test
  tags:
    - test
  script:
    - echo "Running Unit Tests"

integration_test:
  stage: test
  tags:
    - test
  script:
    - echo "Running Integration Tests"

🎯 Summary

Congratulations! 🎉 You have completed Day 5 of the GitLab learning series.

In this article, you learned how GitLab Runners execute CI/CD jobs, explored Runner Architecture, compared Hosted and Self-Hosted Runners, registered your first Self-Hosted Runner, configured Runner Tags, and executed jobs in parallel.

👨‍💻 About the Author

Hi, I'm Apurv Gujjar, a DevOps Engineer passionate about Cloud, AWS, Kubernetes, Docker, Terraform, GitLab, and Infrastructure Automation.

I share practical DevOps tutorials, real-world projects, certification guides, interview preparation, and cloud engineering best practices to help students and professionals build production-ready skills.

📬 Connect With Me

📧 Email: gujjarapurv181@gmail.com

🌐 Portfolio: https://www.apurv-gujjar.co.in

🐙 GitHub: https://github.com/ApurvGujjar07

💼 LinkedIn: https://www.linkedin.com/in/apurv-gujjar

If you enjoy DevOps, Cloud, and GitLab content, feel free to connect with me. I'm always happy to share knowledge and discuss modern cloud technologies.

📖 Introduction

In the previous articles, we explored GitLab fundamentals, repository management, and collaboration workflows. Now it's time to automate the software development lifecycle using GitLab CI/CD Pipelines.

Instead of manually building, testing, and deploying applications, GitLab can automate these tasks whenever changes are pushed to your repository. This automation helps teams deliver software faster, maintain consistent quality, and reduce human errors.

In this article, you'll learn the fundamentals of GitLab CI/CD, understand how pipelines work, create your first .gitlab-ci.yml file, and explore how GitLab executes jobs automatically from code commit to deployment.

By the end of this guide, you'll have a solid understanding of GitLab CI/CD and be ready to build your own automated pipelines.

🎯 What You'll Learn

After completing this article, you'll understand:

• ✅ What is Continuous Integration (CI)?

• ✅ What is Continuous Delivery (CD)?

• ✅ What is GitLab CI/CD?

• ✅ What is a Pipeline?

• ✅ Understanding .gitlab-ci.yml

• ✅ Stages

• ✅ Jobs

• ✅ Pipeline Execution Flow

• ✅ Build → Test → Push → Deploy Workflow

• ✅ Creating Your First GitLab CI/CD Pipeline

📚 Prerequisites

Before continuing, make sure you have:

• A GitLab account

• A GitLab repository

• Git installed on your system

• Basic knowledge of Git

• A sample project (optional)

🚀 What is Continuous Delivery (CD)?

Continuous Delivery (CD) is the practice of automatically preparing an application for deployment after it has been successfully built and tested.

Once the CI process completes without errors, the application is packaged and made ready for release. The final deployment to production may still require manual approval, giving teams complete control over when new features are released.

Continuous Delivery reduces deployment risks and ensures that software is always in a deployable state.

✅ Benefits of Continuous Delivery

• Faster software releases

• Reduced deployment risks

• Consistent deployment process

• Higher release confidence

• Applications remain deployment-ready

🔄 What is GitLab CI/CD?

GitLab CI/CD is GitLab's built-in automation platform that helps developers build, test, and deploy applications directly from their GitLab repositories.

Whenever code is pushed to a repository, GitLab automatically detects the .gitlab-ci.yml configuration file and starts a pipeline. Each pipeline consists of one or more stages, and each stage contains one or more jobs that execute predefined tasks.

This automation eliminates repetitive manual work, improves software quality, and accelerates the development lifecycle.

🔍 How GitLab CI/CD Works

A typical GitLab CI/CD workflow follows these steps:

1. A developer pushes code to a GitLab repository.

2. GitLab detects the .gitlab-ci.yml file.

3. A new pipeline is created automatically.

4. Jobs are executed stage by stage.

5. If all jobs succeed, the application is ready for deployment.

This process runs automatically for every new commit, ensuring that code is continuously validated.

⚙️ What is a Pipeline?

A Pipeline is the core component of GitLab CI/CD. It is a sequence of automated steps that GitLab executes whenever changes are pushed to your repository.

Instead of manually building, testing, and deploying your application, a pipeline performs these tasks automatically in a predefined order.

A pipeline is divided into Stages, and each stage contains one or more Jobs. GitLab executes the stages one by one, ensuring that the previous stage completes successfully before moving to the next.

📄 Understanding .gitlab-ci.yml

The .gitlab-ci.yml file is the heart of every GitLab CI/CD pipeline. It defines what should happen, when it should happen, and how GitLab should execute each job.

GitLab looks for this file in the root directory of your repository. Whenever a new commit is pushed, GitLab reads this configuration file and creates a pipeline based on its instructions.

Without a .gitlab-ci.yml file, GitLab has no instructions to create or execute a CI/CD pipeline.

📁 Creating Your First .gitlab-ci.yml File

Now that we understand the purpose of the .gitlab-ci.yml file, let's create our first GitLab CI/CD pipeline.

For this demonstration, I have created a simple GitLab repository named gitlab-practice, which we'll use throughout this article.

Step 1: Create the Configuration File

Inside the root directory of your repository, create a new file named:

.gitlab-ci.yml

GitLab automatically detects this file whenever new changes are pushed to the repository.

Step 2: Add Your First Pipeline

Open the .gitlab-ci.yml file and add the following configuration:

stages:
  - build

build_job:
  stage: build
  script:
    - echo "Hello from GitLab CI/CD!"
    - echo "Building the application..."

This is the simplest GitLab CI/CD pipeline.

Let's understand what each section does.

Understanding the Configuration

stages:
  - build

Here, we define a single stage named build.

A stage represents a phase of the pipeline. Every job assigned to this stage will execute when the pipeline runs.

build_job:

This is the name of our first job.

You can choose any meaningful name, such as:

build_app
compile_code
docker_build

The job name is only used to identify the task inside the pipeline.

stage: build

This tells GitLab that the job belongs to the build stage.

If multiple stages exist, GitLab executes them in the order they are defined.

script:

The script section contains the commands that GitLab Runner will execute.

In our example, it simply prints two messages to the job logs.

script:

echo "Hello from GitLab CI/CD!"


echo "Building the application..."

When the pipeline runs, the output will look similar to:

Hello from GitLab CI/CD!
Building the application...

Step 3: Commit and Push the Changes

After creating the .gitlab-ci.yml file, commit and push it to your GitLab repository.

git add .
git commit -m "Add first GitLab CI/CD pipeline"
git push origin main

As soon as the code is pushed, GitLab automatically starts a new pipeline.

🚀 Step 4: Watch Your First Pipeline in Action

After committing and pushing the .gitlab-ci.yml file, GitLab automatically detects the new configuration and creates a pipeline.

You don't need to start the pipeline manually. As soon as the changes are pushed to the repository, GitLab begins executing the pipeline based on the instructions defined in the .gitlab-ci.yml file.

🔍 Viewing Job Logs

Click on the pipeline, then select the build_job.

GitLab opens the job details page where you can see the complete execution log generated by the Runner.

🏗️ Understanding Stages

In our first pipeline, we created only one stage called build.

A Stage represents a phase of the CI/CD pipeline. GitLab executes stages sequentially, meaning the next stage starts only after the previous one completes successfully.

In real-world projects, pipelines usually contain multiple stages such as building the application, running tests, and deploying it.

For example:

stages:

build
test
deploy

This tells GitLab to execute the pipeline in the following order:

⚙️ Understanding Jobs

A Job is an individual task that runs inside a stage.

Every job performs a specific action, such as building the application, running tests, or deploying code.

In our example, the job is named build_job.

build_job:
  stage: build
  script:
    - echo "Hello from GitLab CI/CD!"
    - echo "Building the application..."

Here:

• build_job → Name of the job

• stage: build → Assigns the job to the build stage

• script → Commands executed by the GitLab Runner

When the pipeline runs, GitLab executes the commands listed under the script section.

🧩 Multiple Jobs in a Stage

A stage can contain more than one job.

stages:
  - build

build_app:
  stage: build
  script:
    - echo "Building Application"

build_docker:
  stage: build
  script:
    - echo "Building Docker Image"

🔄 Build → Test → Push → Deploy Workflow

A typical GitLab CI/CD pipeline follows four key stages. First, the application is built by compiling the code, installing dependencies, or creating a Docker image. Next, automated tests verify that the application works correctly. If all tests pass, the Docker image or build artifact is pushed to a container registry. Finally, the application is deployed to the target environment, such as a Virtual Machine, Kubernetes cluster, or cloud platform.

stages:
  - build
  - test
  - push
  - deploy

build:
  stage: build
  script:
    - echo "Building the application..."

test:
  stage: test
  script:
    - echo "Running tests..."

push:
  stage: push
  script:
    - echo "Pushing Docker image..."

deploy:
  stage: deploy
  script:
    - echo "Deploying application..."

🎯 Summary

Congratulations! 🎉 You have completed Day 4 of the GitLab learning series.

In this article, you learned GitLab CI/CD, created your first .gitlab-ci.yml file, understood pipelines, stages, and jobs, and explored the Build → Test → Push → Deploy workflow.

👨‍💻 About the Author

Hi, I'm Apurv Gujjar, a DevOps Engineer passionate about Cloud, AWS, Kubernetes, Docker, Terraform, GitLab, and Infrastructure Automation.

I share practical DevOps tutorials, real-world projects, certification guides, interview preparation, and cloud engineering best practices to help students and professionals build production-ready skills.

📬 Connect With Me

📧 Email: gujjarapurv181@gmail.com

🌐 Portfolio: https://www.apurv-gujjar.co.in

🐙 GitHub: https://github.com/ApurvGujjar07

💼 LinkedIn: https://www.linkedin.com/in/apurv-gujjar

If you enjoy DevOps, Cloud, and GitLab content, feel free to connect with me. I'm always happy to share knowledge and discuss modern cloud technologies.

Introduction

Docker has become the standard for building and deploying modern applications, but creating a container image is only the beginning. Every image includes operating system packages and application dependencies that may contain known vulnerabilities (CVEs), making container security a critical part of the software delivery lifecycle.

Modern DevOps teams don't just build containers—they scan, optimize, harden, and continuously improve them before deployment.

In this hands-on guide, you'll learn how to secure Docker images using Docker Scout, reduce image size with Multi-Stage Builds, generate SBOMs, build secure applications with Docker Hardened Images, run local AI models using Docker Model Runner, and troubleshoot Docker projects with Ask Gordon AI.

By the end of this tutorial, you'll have a practical understanding of building lightweight, secure, and production-ready Docker containers using modern Docker features.

What You'll Learn

After completing this guide, you'll be able to:

• Understand modern Docker security concepts.

• Scan images using Docker Scout.

• Analyze and prioritize CVEs.

• Generate Software Bill of Materials (SBOM).

• Build optimized images using Multi-Stage Builds.

• Secure containers with Docker Hardened Images (DHI).

• Debug containers without a shell.

• Apply production-ready container hardening techniques.

• Run local AI models using Docker Model Runner.

• Troubleshoot Docker projects with Ask Gordon AI.

• Follow Docker security best practices used in production.

Why Read This Guide?

Most Docker tutorials end after building an image. In production, that's where the real work begins.

Before deploying a container, every DevOps engineer should be able to answer questions like:

• Is the image vulnerable?

• Can the image be made smaller and more secure?

• Are secrets accidentally included?

• Is the container running as a non-root user?

• Can we generate an SBOM for compliance?

• How can AI simplify Docker development?

This guide answers all of these questions through practical examples, real-world scenarios, and production best practices.

Prerequisites

You'll need:

• Docker Desktop (latest version)

• Docker CLI

• Docker Hub account

• Basic Docker knowledge

• Familiarity with Dockerfiles

• Any sample application for practice

The concepts demonstrated in this guide apply to any Dockerized application, regardless of the programming language or framework.

Part 1 — Docker Scout

What is Docker Scout?

Building a Docker image is easy, but knowing whether it's secure is a completely different challenge.

A typical Docker image contains hundreds of operating system packages, libraries, and application dependencies. While these components make your application work, they can also introduce known security vulnerabilities (CVEs). Deploying an image without checking its security posture can expose your application to unnecessary risks.

This is where Docker Scout comes in.

Docker Scout is Docker's built-in security analysis tool that scans container images for known vulnerabilities, identifies outdated packages, recommends more secure base images, and helps developers improve the overall security of their containers before deployment.

Instead of waiting until production to discover security issues, Docker Scout allows you to identify and fix vulnerabilities early in the development lifecycle.

Why Should You Scan Docker Images?

Imagine you've built a Docker image using an older Ubuntu or Node.js base image. Even if your application code is perfectly secure, the base image itself may contain dozens of publicly disclosed vulnerabilities.

Without scanning, these issues remain hidden until they are exploited or discovered during a security audit.

Docker Scout helps answer important questions such as:

• Does my image contain known CVEs?

• Which vulnerabilities are the most critical?

• Are fixes available?

• Can Docker recommend a more secure base image?

• Which packages are responsible for these vulnerabilities?

This allows developers to make informed security decisions before releasing an application.

Hands-on Lab — Scan Your First Docker Image

Now it's time to perform our first security scan using Docker Scout.

We'll build a sample Docker image and analyze it for vulnerabilities.

Step 1 — Clone the Sample Application

We'll use a sample application throughout this guide.

Run the following command:

git clone https://github.com/LondheShubham153/devboard.git

Once the repository is cloned, navigate into the project directory.

cd devboard

Verify the project files.

ls

Step 2 — Build the Docker Image

Now let's build the Docker image.

Replace the image name with your preferred name.

Example:

docker build -t docker-security-demo:v1 .

Docker will begin downloading the required base image, installing dependencies, and building the final image.

Depending on your internet speed, this may take a few minutes during the first build.

Step 3 — Verify the Image

Before scanning, confirm that Docker created the image successfully.

Run:

docker images

You should see your newly created image in the list.

Scan Your First Docker Image with Docker Scout

Now that our Docker image has been built successfully, it's time to analyze its security posture.

Building an image doesn't guarantee that it's secure. Every image inherits packages and dependencies from its base image, and those packages may contain publicly disclosed vulnerabilities.

Docker Scout helps us identify these vulnerabilities before the image reaches production.

In this section, we'll perform our first vulnerability scan and learn how to interpret the security report generated by Docker Scout.

Step 4 — Perform Your First Docker Scout Scan

Docker Scout provides a quick security summary using the quickview command.

Run the following command:

docker scout quickview local://docker-security-demo:v1

Replace docker-security-demo:v1 with your own image name if you're using a different tag.

Docker Scout will analyze the image locally and display a summary of the detected vulnerabilities.

Unlike a detailed CVE report, QuickView focuses on giving you an overview of the image's security posture in just a few seconds.

Up Next → Detailed CVE Analysis

In the next section, we'll use:

docker scout cves local://docker-security-demo:v1

This command provides a detailed vulnerability report, including:

• The affected package

• CVE ID

• Severity level

• Installed version

• Fixed version (if available)

• Recommended remediation steps

We'll learn how to read a real CVE report like a security engineer and identify which vulnerabilities actually require immediate attention.

Part 2 — Analyze Vulnerabilities with Docker Scout CVE Reports

QuickView gives you a high-level overview of your image's security posture, but security engineers don't make decisions based on summary reports alone.

To understand exactly which packages are vulnerable, how severe the vulnerabilities are, and whether fixes are available, we need a detailed CVE report.

Docker Scout provides this information through the cves command, making it easier to identify the components that require immediate attention.

In this section, we'll generate a complete vulnerability report and learn how to interpret it like a DevSecOps engineer.

Step 5 — Generate a Detailed CVE Report

Run the following command:

docker scout cves local://docker-security-demo:v1

Replace docker-security-demo:v1 with your own image name if you're using a different image.

Docker Scout will scan every package inside your container image and display a detailed list of detected vulnerabilities.

Unlike quickview, this report shows exactly where each vulnerability exists and whether an update is available.

What is a CVE?

A Common Vulnerabilities and Exposures (CVE) is a globally recognized identifier assigned to publicly disclosed security vulnerabilities.

Each CVE has its own unique ID, making it easy for developers, vendors, and security teams to discuss the same vulnerability without confusion.

For example:

CVE-2025-12345

A CVE record typically includes:

• Vulnerability description

• Affected software versions

• Severity score

• References

• Available fixes

Think of a CVE as a tracking number for a known security issue.

💡 Pro Tip

Don't rush to fix every vulnerability immediately.

Instead, focus on vulnerabilities that:

• Have an available fix.

• Affect packages exposed to external users.

• Are marked as Critical or High severity.

• Exist in your runtime image rather than build-only dependencies.

This approach helps you prioritize security work more effectively.

⚠️ Common Mistake

Many beginners assume that every reported CVE is equally dangerous.

In reality, vulnerability scanners report the presence of a vulnerable package—not necessarily that the vulnerability is exploitable in your application.

For example, a package used only during the build process poses much less risk than a vulnerable web server library exposed to incoming user requests.

Always evaluate vulnerabilities in the context of your application before deciding on remediation.

Prioritize Vulnerabilities with Docker Scout

Finding vulnerabilities is only the first step. In real-world environments, security teams don't fix every CVE immediately. Instead, they prioritize vulnerabilities based on severity, fix availability, and business impact.

Docker Scout makes this easier by highlighting which vulnerabilities are actionable.

Step 6 — Show Only Fixable Vulnerabilities

Instead of reviewing hundreds of CVEs manually, filter the report to display only vulnerabilities that already have an available fix.

Run:

docker scout cves local://docker-security-demo:v1 --only-fixed

This reduces noise and helps you focus on vulnerabilities that can actually be remediated.

Step 7 — Filter High and Critical Vulnerabilities

Production teams usually prioritize Critical and High severity issues first.

Run:

docker scout cves local://docker-security-demo:v1 --only-severity critical,high

This filters the report and displays only the vulnerabilities that require immediate attention.

Best Practices

• Prioritize Critical and High vulnerabilities.

• Fix vulnerabilities with available patches first.

• Update the base image regularly.

• Re-scan the image after every major dependency update.

Up Next → Compare Your Base Image with Recommended Alternatives

In the next section, we'll use Docker Scout's recommend feature to:

• Check whether a newer base image is available.

• Compare your current base image with recommended alternatives.

• Reduce vulnerabilities by simply changing the FROM image.

• Understand Docker Scout's remediation recommendations.

Part 3 Find a Better Base Image with Docker Scout

After identifying vulnerabilities, the next step is to check whether Docker Scout recommends a more secure base image.

In many cases, simply updating the base image can significantly reduce the number of vulnerabilities without changing your application code.

Step 8 — View Base Image Recommendations

Run the following command:

docker scout recommendations local://docker-security-demo:v1

Replace docker-security-demo:v1 with your image name if required.

Docker Scout analyzes your current base image and suggests newer or more secure alternatives.

Step 9 — Update the Base Image

Open your Dockerfile and replace the existing base image with the recommended version.

Example:

Before

FROM node:22-alpine

After

FROM node:24-alpine

Your recommended version may be different depending on Docker Scout's output.

Step 10 — Rebuild the Image

After updating the Dockerfile, rebuild the image.

docker build -t docker-security-demo:v2 .

Step 11 — Scan the Updated Image

Run QuickView again to compare the results.

docker scout quickview local://docker-security-demo:v2

Compare the vulnerability count with the previous scan.

💡 Best Practice

Always use the latest stable and officially supported base image, then re-scan after every upgrade.

Part 4 — Generate an SBOM with Docker Scout

An SBOM (Software Bill of Materials) provides a complete inventory of all packages, libraries, and dependencies included in your container image. It's widely used for security audits, compliance, and software supply chain visibility.

Step 12 — Generate an SBOM

Run the following command:

docker scout sbom local://docker-security-demo:v2

Docker Scout will generate an SBOM and list all the packages included in your image.

output is too large that's why i mention only two snap's for your reference .

Step 13 — Export the SBOM

Instead of displaying it in the terminal, save it as a JSON file.

docker scout sbom local://docker-security-demo:v2 --format spdx-json > sbom.json

This creates an sbom.json file in your current directory.

Step 14 — Verify the SBOM File

Windows PowerShell:

cat sbom.json

You'll see package metadata in JSON format.

💡 Best Practice

Generate a fresh SBOM every time you release a new application version. It helps track dependencies, simplifies security audits, and improves software supply chain transparency.

Part 5 — Optimize Images with Multi-Stage Builds

A standard Docker image often includes build tools, source code, and temporary files that aren't needed at runtime. Multi-Stage Builds help create smaller, cleaner, and more secure production images by keeping only the required application files.

Step 15 — Build Using the Existing Dockerfile

First, build the application using the standard Dockerfile.

docker build -f Dockerfile -t docker-standard:v1 .

Check the image size.

docker images

Step 16 — Build Using the Multi-Stage Dockerfile

The project already contains a Dockerfile.multistage.

Build the image using it.

docker build -f Dockerfile.multistage -t docker-multistage:v1 .

After the build completes, verify the image size.

docker images

Step 17 — Compare the Image Sizes

Run:

docker images

Compare both images.

Step 18 — Verify the Application

Run the Multi-Stage image.

docker run -d -p 3000:4173 --name multistage-demo docker-multistage:v1

Verify it's running.

docker ps

Open the application:

http://localhost:3000

Part 6 — Optimize Build Context with .dockerignore

Even with Multi-Stage Builds, Docker may still send unnecessary files during the build process. A .dockerignore file excludes files that aren't required during the image build, resulting in faster builds, smaller build contexts, and preventing sensitive files from being included accidentally.

Step 19 — Check the Current Build Context

Build the image once without changing anything.

docker build -t docker-context:v1 .

During the build, notice the following line:

transferring context: XX MB

This shows the size of the build context sent to the Docker daemon.

Step 20 — Create a .dockerignore File

Create a new file named:

.dockerignore

Add the following entries:

node_modules
.git
.gitignore
README.md
Dockerfile*
.vscode
.env
.env.*
dist
coverage

Adjust this list based on your project if needed.

Best Practices

• Always include a .dockerignore file in every Docker project.

• Never include .env files or secrets in the build context.

• Exclude node_modules, .git, logs, cache, and IDE files.

• Review the build context after major project changes.

Part 7 — Secure Your Containers with Docker Hardened Images (DHI)

Docker Hardened Images (DHI) are production-ready base images designed to reduce the attack surface by including only the components required to run your application.

In this section, we'll pull a hardened image, compare it with a standard image, and analyze its security using Docker Scout.

Step 23 — View Available Docker Hardened Images

Open Docker Hub and navigate to the Docker Hardened Images catalog.

👉 Official Docker Hardened Images Catalog

https://hub.docker.com/catalogs/docker-hardened-images

Browse the available images and select the runtime that matches your application (Node.js, Python, Java, Go, .NET, etc.).

Step 24 — Pull a Hardened Image

Pull the Node.js Hardened Image.

docker pull dhi.io/node:22

Replace the image with the runtime you want to test.

After the download completes, verify the image.

docker images

Step 25 — Scan the Hardened Image

Run Docker Scout against the hardened image.

docker scout quickview dhi.io/node:22

Review the vulnerability summary and compare it with the standard Node image scanned earlier.

Step 26 — Compare Standard vs Hardened Image

Compare the results from both images.

✅ Best Practices

• Use Docker Hardened Images for production workloads.

• Keep the image updated regularly.

• Re-scan after every version upgrade.

• Combine Hardened Images with Multi-Stage Builds for maximum security.

Part 8 — Debug Docker Hardened Images with Docker Debug

Docker Hardened Images intentionally remove shells and debugging tools to reduce the attack surface. Instead of modifying the container, Docker provides Docker Debug, which lets you troubleshoot running containers without permanently changing them.

Step 27 — Verify Docker Debug

First, check whether Docker Debug is available.

docker debug --help

If Docker Debug is installed correctly, you'll see the available commands and options.

Part 9 — Run Local AI Models with Docker Model Runner

Docker Model Runner allows you to download and run AI models locally using Docker Desktop. The models run entirely on your machine, making it easy to experiment with AI without relying on external APIs.

Step 28 — Verify Docker Model Runner

First, check whether Docker Model Runner is available.

docker model --help

If Docker Model Runner is enabled, Docker will display the available model management commands.

Step 29 — List Available Models

Run:

docker model ls

This displays all AI models currently available on your system.

Step 30 — Pull Your First AI Model

Download a model from the Docker Model Registry.

Run:

docker model pull ai/smollm2

Docker will download the model and store it locally.

Step 31 — Verify the Downloaded Model

List the locally available models.

docker model ls

You should see the newly downloaded model.

Step 32 — Run the AI Model

Start an interactive session with the downloaded model.

docker model run ai/smollm2

The model will start locally and wait for your prompt.

Part 10 — Troubleshoot Docker Projects with Ask Gordon AI

Ask Gordon AI is Docker's built-in AI assistant that helps you understand Docker commands, explain errors, optimize Dockerfiles, and troubleshoot Docker projects directly from Docker Desktop.

Step 34 — Open Ask Gordon AI

Open Docker Desktop and navigate to the Ask Gordon section from the left sidebar.

Wait for the AI assistant to load.

or if you want to run on your terminal then you can run the below command :-

docker ai

Final Takeaways

Throughout this guide, you learned how to:

• Scan container images with Docker Scout.

• Analyze and prioritize vulnerabilities.

• Upgrade to recommended base images.

• Generate an SBOM.

• Reduce image size using Multi-Stage Builds.

• Optimize the build context with .dockerignore.

• Secure containers using Docker Hardened Images.

• Troubleshoot containers with Docker Debug.

• Run local AI models using Docker Model Runner.

• Improve Docker projects with Ask Gordon AI.

These practices help you build lighter, more secure, and production-ready Docker images while following modern DevSecOps workflows.

Conclusion

Building a Docker image is only the first step. A production-ready container should also be scanned, optimized, documented, and regularly maintained.

By combining Docker Scout, Multi-Stage Builds, Docker Hardened Images, SBOM generation, Docker Debug, Docker Model Runner, and Ask Gordon AI, you can create containers that are easier to maintain, more secure, and better prepared for real-world deployments.

Continue exploring new Docker features, keep your base images updated, and make security a regular part of your container development workflow.

👨‍💻 About the Author

Hi, I'm Apurv Gujjar, a DevOps Engineer passionate about Cloud, AWS, Kubernetes, Docker, Terraform, GitLab, and Infrastructure Automation.

I share practical DevOps tutorials, real-world projects, certification guides, interview preparation, and cloud engineering best practices to help students and professionals build production-ready skills.

📬 Connect With Me

📧 Email: gujjarapurv181@gmail.com

🌐 Portfolio: https://www.apurv-gujjar.co.in

🐙 GitHub: https://github.com/ApurvGujjar07

💼 LinkedIn: https://www.linkedin.com/in/apurv-gujjar

If you enjoy DevOps, Cloud, and GitLab content, feel free to connect with me. I'm always happy to share knowledge and discuss modern cloud technologies.

📖 Introduction

In the previous articles, we learned the fundamentals of GitLab, created projects, and configured secure authentication using SSH Keys and Personal Access Tokens.

Now it's time to start working with GitLab repositories.

In this guide, you'll learn how to migrate existing repositories from GitHub, keep repositories synchronized using mirroring, understand the difference between Merge Requests and Pull Requests, and follow repository management best practices used by professional DevOps teams.

By the end of this article, you'll know how to manage GitLab repositories efficiently in both personal and enterprise environments.

🎯 What You'll Learn

After completing this article, you'll understand:

• ✅ Import a GitHub repository into GitLab

• ✅ Repository Mirroring

• ✅ Push Mirroring vs Pull Mirroring

• ✅ Merge Request vs Pull Request

• ✅ Repository Management Best Practices

📚 Prerequisites

Before continuing, make sure you have:

• A GitLab account

• A GitHub account

• Basic knowledge of Git

• An existing Git repository (optional)

📥 Importing a GitHub Repository into GitLab

Many developers and organizations already host their source code on GitHub. If you decide to use GitLab for its powerful CI/CD, security features, or DevOps platform, you don't need to recreate your repositories from scratch.

GitLab provides a built-in Import Project feature that allows you to migrate an existing GitHub repository—including its commit history—to GitLab in just a few steps.

This makes migration simple while preserving your existing development history.

🔍 Why Import a Repository?

Importing a repository saves time and ensures that your existing project history remains intact.

Common reasons to import a repository include:

• Migrating from GitHub to GitLab

• Using GitLab CI/CD with an existing project

• Consolidating repositories into one platform

• Moving company projects to GitLab

🚀 Steps to Import a GitHub Repository

Follow these steps to import your repository into GitLab.

Step 1: Sign in to GitLab

Log in to your GitLab account and click Project.

Step 2: Choose Import Project

Select Import Project, then choose GitHub as the import source.

Step 3: Authorize GitHub

GitLab will ask you to authorize access to your GitHub account.

Grant the required permissions so GitLab can read your repositories.

Step 4: Select the Repository

Choose the repository you want to import and click Import.

GitLab will automatically copy the repository, including its commit history.

Step 5: Verify the Import

Once the import is complete, open the repository in GitLab and verify that:

• Source code is available

• Commit history is preserved

• Branches are imported successfully

Your project is now ready to use in GitLab.

🔄 Repository Mirroring

Repository Mirroring is a feature that automatically synchronizes repositories between GitLab and another Git hosting platform, such as GitHub, Bitbucket, or another GitLab instance.

Instead of manually pushing or pulling changes, GitLab keeps the repositories synchronized based on the configured mirroring direction.

Repository mirroring is especially useful for organizations managing projects across multiple Git platforms or maintaining backup repositories.

🤔 Why Use Repository Mirroring?

Repository mirroring helps keep code synchronized across different platforms without requiring manual intervention.

Common use cases include:

• Migrating from GitHub to GitLab gradually

• Maintaining a backup repository

• Synchronizing code across multiple Git platforms

• Supporting teams working on different Git hosting services

🔀 Types of Repository Mirroring

GitLab supports two types of repository mirroring:

• Pull Mirroring

• Push Mirroring

The difference lies in the direction in which changes are synchronized.

⬇️ Pull Mirroring

In Pull Mirroring, GitLab periodically pulls changes from another remote repository and updates the local GitLab repository automatically.

Whenever new commits are pushed to the source repository, GitLab fetches those changes during the next synchronization.

Example

GitHub Repository
        │
        │ Pull Changes
        ▼
GitLab Repository

Best Use Cases

• Migrating repositories from GitHub

• Keeping GitLab updated from another platform

• Read-only synchronization

⬆️ Push Mirroring

In Push Mirroring, GitLab automatically pushes changes from its repository to another remote repository whenever new commits are added.

This ensures that both repositories remain synchronized.

Example

GitLab Repository
        │
        │ Push Changes
        ▼
GitHub Repository

Best Use Cases

• Maintaining backup repositories

• Publishing code to multiple Git platforms

• Disaster recovery strategies

⚖️ Pull Mirroring vs Push Mirroring

🔀 Merge Request vs Pull Request

If you've worked with GitHub before, you've probably heard the term Pull Request (PR). In GitLab, the same concept is called a Merge Request (MR).

Both are used to propose code changes, review them, discuss improvements, and merge them into the main branch. The primary difference is the terminology used by each platform.

🤔 What is a Merge Request?

A Merge Request (MR) is a GitLab feature that allows developers to propose changes from one branch to another before merging.

Instead of directly pushing code to the main branch, developers create a Merge Request so teammates can review the changes, suggest improvements, run CI/CD pipelines, and approve the code.

This review process helps maintain code quality and reduces the chances of introducing bugs into production.

🤔 What is a Pull Request?

A Pull Request (PR) is GitHub's implementation of the same workflow.

After completing work on a feature branch, developers open a Pull Request to request that their changes be merged into another branch, usually the main or develop branch.

Like Merge Requests, Pull Requests support code reviews, comments, approvals, and automated CI/CD checks.

💼 Real-World Example

Imagine you're developing a new login feature.

Instead of committing your changes directly to the main branch, you create a separate feature branch.

After completing the feature, you open a Merge Request (or Pull Request in GitHub).

Your teammates review the code, provide feedback, and approve the changes. Once all checks pass, the feature is merged into the main branch.

This workflow helps teams collaborate safely while maintaining high code quality.

📂 Repository Management Best Practices

A well-managed repository is easier to maintain, collaborate on, and scale as your project grows. Following repository management best practices helps improve code quality, reduces conflicts, and makes collaboration more efficient.

Whether you're working on a personal project or contributing to an enterprise application, adopting these practices from the beginning will save time and effort in the long run.

✅ 1. Use a Clear Repository Structure

Organize your project with a consistent folder structure so developers can easily navigate the codebase.

✅ 2. Write a Good README

A README.md file is often the first thing contributors see. It should explain:

• Project overview

• Installation steps

• Usage instructions

• Prerequisites

• Contribution guidelines

A well-written README helps new developers get started quickly.

✅ 3. Use Meaningful Branch Names

Avoid generic branch names like:

test
new
abc

Instead, use descriptive names such as:

feature/user-authentication
bugfix/login-error
hotfix/payment-api

Meaningful branch names make collaboration easier and improve project organization.

✅ 4. Protect Important Branches

Protect critical branches like main and develop to prevent accidental changes.

Instead of pushing directly, require developers to submit Merge Requests for review and approval.

This helps maintain code quality and reduces the risk of introducing bugs.

✅ 5. Keep Commit Messages Clear

Write commit messages that describe what changed.

✅ Good Examples:

Add user authentication API

Fix Docker build issue

Update Kubernetes deployment configuration

❌ Avoid:

update

fix

changes

Clear commit messages make it easier to understand project history.

✅ 6. Review Code Before Merging

Always review code through a Merge Request before merging it into the main branch.

Code reviews help:

• Identify bugs early

• Improve code quality

• Share knowledge across the team

• Maintain coding standards

✅ 7. Keep Documentation Updated

As the project evolves, update your documentation regularly.

Important files include:

• README.md

• CHANGELOG.md

• CONTRIBUTING.md

• Project Wiki

Up-to-date documentation makes onboarding and maintenance much easier.

🎯 Summary

Congratulations! 🎉 You have successfully completed Day 3 of the GitLab learning series.

In this article, you learned how to import existing GitHub repositories into GitLab, synchronize repositories using Repository Mirroring, understand the difference between Merge Requests and Pull Requests, and follow repository management best practices used by professional development teams.

These concepts form the foundation of an efficient Git workflow and prepare you for collaborating on real-world software projects using GitLab.

👨‍💻 About the Author

Hi, I'm Apurv Gujjar, a DevOps Engineer passionate about Cloud, AWS, Kubernetes, Docker, Terraform, GitLab, and Infrastructure Automation.

I share practical DevOps tutorials, real-world projects, certification guides, interview preparation, and cloud engineering best practices to help students and professionals build production-ready skills.

📬 Connect With Me

📧 Email: gujjarapurv181@gmail.com

🌐 Portfolio: https://www.apurv-gujjar.co.in

🐙 GitHub: https://github.com/ApurvGujjar07

💼 LinkedIn: https://www.linkedin.com/in/apurv-gujjar

If you enjoy DevOps, Cloud, and GitLab content, feel free to connect with me. I'm always happy to share knowledge and discuss modern cloud technologies.

Learn how GitLab organizes repositories using Groups and Projects, and understand how to securely authenticate using Personal Access Tokens (PAT), SSH Keys, and Single Sign-On (SSO).

📖 Introduction

In the previous article, we explored the fundamentals of GitLab, including its architecture, deployment models, and how it compares with GitHub and Bitbucket.

Now that we have a solid understanding of GitLab, it's time to learn how repositories are organized and how developers securely access them.

Whether you're working individually or as part of a large development team, understanding Groups, Projects, and authentication methods is essential. These concepts help organizations manage repositories efficiently while ensuring secure collaboration across teams.

In this article, we'll explore how GitLab organizes projects, how authentication works, and how to securely connect to GitLab repositories using Personal Access Tokens (PAT) and SSH Keys. We'll also learn how to configure an AWS EC2 instance to communicate with GitLab using SSH authentication.

By the end of this guide, you'll be able to organize projects like a professional DevOps engineer and securely interact with GitLab repositories.

🎯 What You'll Learn

After completing this article, you'll understand:

• ✅ What are GitLab Groups?

• ✅ What are GitLab Projects?

• ✅ Difference between Groups and Projects

• ✅ GitLab Project Structure

• ✅ Git Authentication

• ✅ Personal Access Tokens (PAT)

• ✅ SSH Keys

• ✅ Single Sign-On (SSO)

• ✅ SSH Authentication Setup

• ✅ Cloning a Repository using SSH

📚 Prerequisites

Before continuing, make sure you have:

• A GitLab Account

• Git Installed on your system

• Basic knowledge of Git commands

• A Linux machine or AWS EC2 instance (optional for practice)

👥 What are GitLab Groups?

As organizations grow, managing hundreds of repositories individually becomes difficult. To solve this problem, GitLab provides Groups.

A Group is a container that helps organize multiple related projects under a single team or organization. Instead of managing users and permissions separately for each repository, administrators can manage everything at the group level.

For example, if a company has separate repositories for a frontend application, backend API, Kubernetes manifests, and Terraform configurations, all of them can be placed inside a single group.

This approach makes collaboration easier, simplifies permission management, and keeps projects well organized.

Example

Imagine your company is called ABC Technologies.

Inside the company, there's a DevOps Team responsible for managing cloud infrastructure and application deployments.

The DevOps team may create a single GitLab Group called DevOps-Team, which contains multiple projects.

Why Use Groups?

Using Groups provides several advantages:

• Better project organization

• Easier permission management

• Improved collaboration

• Simplified administration

• Centralized access control

Groups are especially useful for organizations managing multiple teams and repositories.

📁 What are GitLab Projects?

A Project is the place where your actual application or source code is stored in GitLab. Every project contains everything related to a specific application, service, or repository, including its source code, branches, commits, Merge Requests, issues, and CI/CD pipelines.

In simple terms, if a Group represents a team or organization, then a Project represents the actual application or repository that the team is working on.

For example, a company may have different applications such as a frontend website, backend API, Kubernetes manifests, and Terraform code. Each of these would typically be created as a separate project within the same GitLab Group.

Example

Let's continue with the previous example.

Suppose your organization has a Group named DevOps-Team.

Inside this Group, you can create multiple projects, each serving a different purpose.

Why Use Projects?

Projects help organize your work efficiently by keeping each application or service in its own dedicated repository.

Some benefits of using Projects include:

• Store source code securely

• Manage Git branches and commits

• Collaborate using Merge Requests

• Automate CI/CD pipelines

• Track issues and bugs

• Maintain project documentation

Whether you're developing a simple application or managing enterprise infrastructure, every repository in GitLab is created as a Project.

🔄 Groups vs Projects

One of the most common questions beginners ask is:

"What is the difference between a Group and a Project?"

The answer is simple.

A Group is used to organize and manage multiple related projects, whereas a Project is where the actual application or source code resides.

Think of a Group as a company department and a Project as the individual applications that department is responsible for.

For example, a DevOps team may manage several applications, infrastructure code, and automation scripts. Instead of creating everything separately, they organize all related repositories under a single Group.

🎯 When Should You Use a Group?

Create a Group when:

• You have multiple related repositories.

• Multiple developers work on different projects.

• You want centralized permission management.

• You're managing projects for a team or organization.

🎯 When Should You Use a Project?

Create a Project when:

• You're starting a new application.

• You need a separate Git repository.

• You want an independent CI/CD pipeline.

• You need to track issues and manage code for a specific application.

🔐 Git Authentication in GitLab

Before you can clone, push, or pull code from a GitLab repository, GitLab must verify your identity. This process is known as Git Authentication.

In the past, many Git hosting platforms allowed users to authenticate using their account password. However, this approach was not secure because passwords could be exposed or misused.

To improve security, GitLab no longer supports using your account password for Git operations over HTTPS. Instead, it uses more secure authentication methods such as Personal Access Tokens (PAT), SSH Keys, and Single Sign-On (SSO).

These authentication methods help protect repositories while ensuring that only authorized users can access and modify the source code.

🔑 Authentication Methods in GitLab

GitLab provides three primary authentication methods:

1️⃣ SSH Keys

SSH authentication uses a public-private key pair to securely connect your system with GitLab. Once configured, you can clone, pull, and push repositories without entering your credentials every time.

Best for: Developers and DevOps Engineers who work with Git repositories regularly.

2️⃣ Personal Access Token (PAT)

A Personal Access Token acts as a secure replacement for your account password when performing Git operations over HTTPS.

Instead of entering your GitLab password, you use the generated token.

Best for: HTTPS-based Git operations and API integrations.

3️⃣ Single Sign-On (SSO)

Large organizations often use Single Sign-On (SSO) to allow employees to log in using their company identity providers, such as Microsoft Entra ID (Azure AD), Okta, or Google Workspace.

This simplifies user management while improving security and enforcing organizational policies.

Best for: Enterprise environments.v

🎫 Personal Access Token (PAT)

A Personal Access Token (PAT) is a secure authentication credential used instead of your GitLab account password for Git operations over HTTPS.

Earlier, users could clone, push, and pull repositories using their GitLab username and password. However, this method was less secure and increased the risk of credential exposure.

To improve security, GitLab now recommends using a Personal Access Token (PAT) for HTTPS authentication instead of your account password.

Think of a PAT as a temporary password that is generated specifically for Git operations. Unlike your account password, a PAT can be limited to specific permissions and revoked at any time without affecting your account login.

📌 Why Use a Personal Access Token?

Using a PAT provides several security benefits:

• Secure alternative to account passwords.

• Can be revoked anytime without changing your account password.

• Permissions can be restricted using scopes.

• Commonly used for Git over HTTPS and API access.

• Reduces the risk of exposing your actual login credentials.

📍 Where Can You Create a PAT?

🔧 Common Use Cases

A Personal Access Token is commonly used when:

• Cloning a repository over HTTPS.

• Pushing code to GitLab.

• Pulling the latest changes.

• Accessing the GitLab REST API.

• Integrating GitLab with third-party tools.

🔑 SSH Keys

An SSH Key is one of the most secure and recommended ways to authenticate with GitLab. Instead of entering your username and password every time you interact with a repository, SSH uses a public-private key pair to verify your identity.

Once your SSH key is configured, you can clone, pull, and push code securely without repeatedly entering your credentials.

This is why most DevOps Engineers and software developers prefer SSH authentication for their daily workflow.

🔍 How SSH Authentication Works

SSH authentication works using two keys:

• Private Key – Stored securely on your local machine. Never share this key with anyone.

• Public Key – Uploaded to your GitLab account so GitLab can verify your identity.

When you connect to GitLab, it verifies your private key against the stored public key. If they match, access is granted without asking for your password.

🚀 Why Use SSH Keys?

SSH authentication offers several advantages over password-based authentication:

• More secure than passwords

• No need to enter credentials repeatedly

• Faster Git operations

• Ideal for developers and DevOps engineers

• Widely used in production environments

🛠️ Basic SSH Setup

Setting up SSH authentication involves four simple steps:

Step 1: Generate an SSH Key Pair

Run the following command on your local machine or server.

ssh-keygen

This command generates both the private key and the public key.

Step 2: View the Public Key

Display the public key using:

cat ~/.ssh/id_rsa.pub

Copy the entire output.

Step 4: Clone the Repository Using SSH

After adding your SSH key, copy the repository's SSH URL.

Example:

git@gitlab.com:group-name/project-name.git

Now clone the repository:

git clone git@gitlab.com:group-name/project-name.git

Once configured, Git will authenticate automatically using your SSH key.

🏢 Single Sign-On (SSO)

Single Sign-On (SSO) is an authentication method that allows users to access GitLab using their organization's existing identity provider instead of creating and managing a separate GitLab password.

In most enterprise environments, employees already have company accounts managed by services such as Microsoft Entra ID (Azure AD), Okta, Google Workspace, or other identity providers. With SSO, users can sign in to GitLab using these existing accounts, making authentication both secure and convenient.

Instead of remembering multiple usernames and passwords for different applications, users authenticate once through their organization's identity provider and gain access to GitLab based on the permissions assigned by the organization.

🔍 How SSO Works

When a user attempts to log in to GitLab, they are redirected to the organization's identity provider. After successful authentication, the identity provider securely verifies the user's identity and grants access to GitLab.

🚀 Benefits of Using SSO

Organizations prefer SSO because it improves both security and user management.

Some key benefits include:

• Users log in with their company credentials.

• No need to remember multiple passwords.

• Centralized user and permission management.

• Improved security through Multi-Factor Authentication (MFA).

• Faster onboarding and offboarding of employees.

• Reduced risk of unauthorized access.

🏢 Where is SSO Commonly Used?

SSO is primarily used in large organizations and enterprises where hundreds or even thousands of employees need secure access to GitLab.

Some common use cases include:

• Large software companies

• Banking and financial institutions

• Government organizations

• Healthcare companies

• Enterprises with centralized identity management

🎯 Summary

Congratulations! 🎉 You have successfully completed Day 2 of the GitLab learning series.

In this chapter, you learned how GitLab organizes repositories using Groups and Projects, explored different authentication methods, and configured secure access from an AWS EC2 instance.

👨‍💻 About the Author

Hi, I'm Apurv Gujjar, a DevOps Engineer passionate about Cloud, AWS, Kubernetes, Docker, Terraform, GitLab, and Infrastructure Automation.

I share practical DevOps tutorials, real-world projects, certification guides, interview preparation, and cloud engineering best practices to help students and professionals build production-ready skills.

📬 Connect With Me

📧 Email: gujjarapurv181@gmail.com

🌐 Portfolio: https://www.apurv-gujjar.co.in

🐙 GitHub: https://github.com/ApurvGujjar07

💼 LinkedIn: https://www.linkedin.com/in/apurv-gujjar

If you enjoy DevOps, Cloud, and GitLab content, feel free to connect with me. I'm always happy to share knowledge and discuss modern cloud technologies.

🚀 In this first lesson of the GitLab Mastery Series, you'll learn what GitLab is, why modern DevOps teams rely on it, and how it simplifies the complete Software Development Life Cycle (SDLC).

📖 Introduction

Welcome to the GitLab Mastery Series—your step-by-step guide to mastering GitLab from the basics to advanced DevOps workflows.

Whether you're aspiring to become a DevOps Engineer, Cloud Engineer, Platform Engineer, or Site Reliability Engineer (SRE), GitLab is one of the most valuable tools you can learn. It's widely adopted by startups and enterprises to streamline software development, automate deployments, and improve team collaboration.

Modern software development is no longer just about writing code. Teams need to collaborate efficiently, automate software delivery, maintain security, and deploy applications faster with confidence. Managing these responsibilities using multiple disconnected tools can quickly become complex, time-consuming, and difficult to maintain.

This is where GitLab makes a difference.

More than just a Git repository hosting platform, GitLab is a complete end-to-end DevOps platform that helps teams manage the entire Software Development Life Cycle (SDLC) from a single application. It combines source code management, collaboration, built-in CI/CD, security scanning, package management, and deployment into one unified platform.

In this first article of the GitLab Mastery Series, you'll build a strong foundation by learning what GitLab is, why it was created, why organizations choose it over other platforms, how it compares with GitHub and Bitbucket, and how it supports modern DevOps workflows.

By the end of this guide, you'll have a clear understanding of GitLab fundamentals and be ready to dive into hands-on GitLab workflows in the upcoming lessons.

🎯 What You'll Learn

After completing this article, you'll understand:

• ✅ What is GitLab?

• ✅ Why was GitLab created?

• ✅ GitLab Architecture

• ✅ GitHub vs GitLab

• ✅ GitHub vs Bitbucket

• ✅ Why enterprises choose GitLab

• ✅ GitLab Community Edition

• ✅ GitLab SaaS vs Self-Managed

• ✅ Creating a GitLab account

• ✅ GitLab account verification process

📚 Prerequisites

Before getting started, you should have a basic understanding of:

• Basic Git concepts

• Version Control System (VCS)

• Basic Linux commands (Optional)

Don't worry if you're completely new to GitLab. This series starts from absolute basics and gradually moves toward real-world DevOps implementations.

📖 What is GitLab?

GitLab is one of the most popular DevOps platforms that enables teams to manage the entire Software Development Life Cycle (SDLC) from a single application.

Unlike traditional Git repository hosting platforms, GitLab provides everything required to develop, test, secure, and deploy applications without relying on multiple third-party tools.

GitLab is an all-in-one DevOps platform that combines Git repository hosting, source code management, collaboration, built-in CI/CD, testing, security, and deployment tools into a single platform.

In simple terms, GitLab is much more than a place to store your source code. It allows development and operations teams to collaborate efficiently, automate software delivery, and continuously deploy applications using a unified platform.

Instead of using separate tools for version control, CI/CD, security scanning, and deployment, GitLab brings all these capabilities together, making software development faster, more secure, and easier to manage.

🚀 Why is GitLab So Popular?

Modern software development requires multiple teams to work together.

Developers write code, testers validate features, DevOps engineers automate deployments, and security teams ensure applications remain secure. Managing these workflows using different tools often leads to complex integrations, higher maintenance, and increased operational costs.

GitLab solves this challenge by providing a single platform where every stage of the DevOps lifecycle can be managed efficiently.

With GitLab, organizations can:

• Store and manage source code repositories.

• Collaborate using Merge Requests and Code Reviews.

• Automate Build, Test, and Deployment through CI/CD pipelines.

• Perform security and compliance scans.

• Deploy applications to cloud, virtual machines, or Kubernetes clusters.

• Monitor the complete software delivery process from one interface.

This unified approach is one of the biggest reasons why GitLab has become a preferred choice for startups, enterprises, and DevOps teams worldwide.

🔑 Key Features of GitLab

GitLab offers a wide range of built-in features that simplify the software development process.

Some of its most important capabilities include:

• Git Repository Hosting

• Source Code Management (SCM)

• Team Collaboration

• Merge Requests (MR)

• Built-in CI/CD Pipelines

• DevSecOps Integration

• Security Scanning

• Container Registry

• Package Registry

• Issue Tracking

• Project Management

• Deployment Automation

• Monitoring & Observability

Because all these capabilities are available within a single application, GitLab is often referred to as an All-in-One DevOps Platform.

🔄 How GitLab Fits into the DevOps Lifecycle

As shown above, GitLab acts as the central platform that connects developers, testing, security, CI/CD, and deployment into a single automated workflow.

Instead of manually managing different tools for each phase, GitLab streamlines the complete software delivery process from code commit to production deployment.

💡 Real-World Example

Imagine a company developing an e-commerce application.

Every day:

• Developers write new features.

• Testers verify application quality.

• DevOps engineers automate deployments.

• Security teams scan the application for vulnerabilities.

Without GitLab, the company might need different tools such as GitHub, Jenkins, SonarQube, Docker Registry, and several deployment utilities.

With GitLab, all these activities can be managed from a single platform, reducing operational complexity while improving collaboration, automation, and software delivery speed.

❓ Why Was GitLab Created?

Before GitLab became popular, software development teams relied on multiple tools to manage different stages of the Software Development Life Cycle (SDLC).

For example, developers used one platform to host their source code, another tool to automate builds and deployments, a separate application for security scanning, and yet another tool for project management. While these tools worked individually, integrating and maintaining them required significant effort, increased operational costs, and often led to workflow inefficiencies.

As software projects grew in complexity, organizations realized the need for a unified platform that could streamline the entire development process.

This is where GitLab changed the game.

GitLab was created with a simple yet powerful vision:

Provide a single application for the complete DevOps lifecycle.

Instead of switching between multiple tools, development, operations, QA, and security teams could collaborate on one platform—from writing code to deploying applications into production.

Today, GitLab enables organizations to manage their complete software delivery pipeline within a single interface, helping teams deliver software faster, improve collaboration, and maintain higher security standards.

🚧 Challenges Before GitLab

Before platforms like GitLab existed, a typical DevOps workflow looked something like this:-

Although each tool performed its job well, teams had to spend considerable time integrating, configuring, and maintaining these separate systems.

Some common challenges included:

• Managing multiple tools with different interfaces.

• Complex integrations between tools.

• Higher infrastructure and maintenance costs.

• Difficult user and permission management.

• Slower software delivery.

• Increased operational overhead.

As organizations scaled, these challenges became even more significant.

💡 How GitLab Solved These Problems

GitLab introduced an all-in-one DevOps platform that combines multiple capabilities into a single application.

Instead of using separate tools, teams can perform almost every DevOps activity directly within GitLab.

With GitLab, you can:

• Host and manage Git repositories.

• Collaborate using Merge Requests and Code Reviews.

• Automate Build, Test, and Deployment using built-in CI/CD.

• Store packages and container images.

• Perform security and vulnerability scanning.

• Manage projects, issues, milestones, and documentation.

• Deploy applications to cloud platforms, virtual machines, or Kubernetes clusters.

This unified approach simplifies software development while reducing operational complexity.

🌍 Real-World Example

Imagine a startup with a team of 20 developers building an e-commerce application.

Without GitLab, the team might use:

• GitHub for source code management.

• Jenkins for CI/CD pipelines.

• SonarQube for code quality analysis.

• Docker Hub for container images.

• Jira for project management.

• Confluence for documentation.

Managing permissions, integrations, updates, and authentication across all these platforms can quickly become difficult.

With GitLab, the same team can manage almost all these activities from a single platform.

This not only reduces maintenance effort but also improves collaboration, security, and deployment speed.

🎯 Key Takeaway

GitLab was created to eliminate the complexity of using multiple DevOps tools by providing a single, integrated platform for the entire Software Development Life Cycle.

Instead of managing separate tools for source code, CI/CD, security, and deployment, GitLab brings everything together—allowing teams to collaborate more efficiently, automate workflows, and deliver software faster with greater confidence.

🏗️ GitLab Architecture

To use GitLab effectively, it's important to understand how its core components work together. GitLab is designed around a simple yet powerful architecture that automates the entire software delivery process—from writing code to deploying applications into production.

Whenever a developer pushes code to a GitLab repository, GitLab can automatically trigger a CI/CD pipeline. The pipeline is then executed by a GitLab Runner, which performs tasks such as building the application, running tests, scanning for vulnerabilities, and deploying the application to the target environment.

This seamless workflow allows development teams to deliver software faster, reduce manual effort, and maintain consistent deployment processes.

⚔️ GitHub vs GitLab

If you've worked with Git before, you've probably heard about GitHub and GitLab. At first glance, both platforms may seem similar because they allow developers to host Git repositories and collaborate on code. However, they differ significantly in terms of features, DevOps capabilities, and overall workflow.

GitHub primarily focuses on Git repository hosting and collaboration, whereas GitLab is designed as a complete DevOps platform that supports the entire Software Development Life Cycle (SDLC) from development to deployment.

💡 Which One Should You Choose?

Choose GitHub if:

• You mainly host code repositories.

• You contribute to open-source projects.

• Your workflow already relies on GitHub Actions.

• You prefer a large developer community.

Choose GitLab if:

• You want an all-in-one DevOps platform.

• You need built-in CI/CD without additional setup.

• Your organization requires self-hosted deployments.

• You want integrated security, automation, and deployment features.

⚖️ GitHub vs Bitbucket

Along with GitHub and GitLab, Bitbucket is another popular Git repository hosting platform. While all three platforms use Git for version control, they are designed for different use cases.

GitHub is widely known for open-source collaboration, GitLab focuses on the complete DevOps lifecycle, whereas Bitbucket is primarily designed for teams already using Atlassian products such as Jira and Confluence.

🎯 Which Platform Should You Choose?

Choose GitHub if you work on open-source projects or need a large developer community.

Choose Bitbucket if your organization already uses Jira, Confluence, and other Atlassian products, as it integrates seamlessly with them.

🏢 Why Do Enterprises Choose GitLab?

Modern enterprises don't just need a platform to store source code—they need a solution that can manage the entire software delivery lifecycle.

GitLab provides a single platform for source code management, CI/CD, security, project planning, and deployment, reducing the need to maintain multiple tools. This integrated approach simplifies DevOps workflows, improves collaboration, and lowers operational overhead.

One of the biggest reasons enterprises choose GitLab is its Community Edition, which allows organizations to self-host GitLab on their own infrastructure without licensing costs. This gives companies greater control over their data, security, and compliance requirements.

🌐 GitLab SaaS vs Self-Managed

GitLab offers two deployment options: GitLab SaaS and GitLab Self-Managed. The right choice depends on your organization's infrastructure, security requirements, and operational needs.

If you simply want to start using GitLab without managing any servers, GitLab SaaS is the easiest option. On the other hand, organizations that require complete control over their infrastructure often choose the Self-Managed edition.

👤 Creating a GitLab Account

Before you can create repositories, collaborate with teams, or build CI/CD pipelines, you first need a GitLab account.

Creating an account is quick and completely free for learning and personal projects.

📝 Steps to Create a GitLab Account

1. Visit the GitLab website.

2. Click Register or Sign Up.

3. Enter your:

   • Name

   • Username

   • Email Address

   • Password

4. Accept the Terms and Conditions.

5. Click Continue to create your account.

📝 Summary

Congratulations! 🎉 You have successfully completed Day 1 of the GitLab series.

In this article, you learned:

• ✅ What GitLab is

• ✅ Why GitLab was created

• ✅ GitLab Architecture

• ✅ GitHub vs GitLab

• ✅ GitHub vs Bitbucket

• ✅ Why enterprises choose GitLab

• ✅ GitLab SaaS vs Self-Managed

• ✅ Creating a GitLab account

• ✅ GitLab account verification process

You now have a solid understanding of GitLab fundamentals and are ready to explore its practical features.

👨‍💻 About the Author

Hi, I'm Apurv Gujjar, a DevOps Engineer passionate about Cloud, AWS, Kubernetes, Docker, Terraform, GitLab, and Infrastructure Automation.

I share practical DevOps tutorials, real-world projects, certification guides, interview preparation, and cloud engineering best practices to help students and professionals build production-ready skills.

📬 Connect With Me

📧 Email: gujjarapurv181@gmail.com

🌐 Portfolio: https://www.apurv-gujjar.co.in

🐙 GitHub: https://github.com/ApurvGujjar07

💼 LinkedIn: https://www.linkedin.com/in/apurv-gujjar

If you enjoy DevOps, Cloud, and GitLab content, feel free to connect with me. I'm always happy to share knowledge and discuss modern cloud technologies.

📝 Abstract

In Terraform, the state file (terraform.tfstate) is the most critical component that connects your configuration with real infrastructure. However, storing it locally can lead to security risks, data loss, and team conflicts.

This blog explains how to securely manage Terraform state using AWS S3 (remote storage) and DynamoDB (state locking), which is the industry-standard approach for production environments.

🎯 Objectives

After completing this blog, you will be able to:

• Understand Terraform state and its importance

• Know why .tfstate should never be pushed to GitHub

• Handle state loss scenarios

• Understand state conflicts in team environments

• Implement remote backend using S3 + DynamoDB

• Test state locking in real scenarios

🔷 Step 1: What is Terraform State?

Terraform maintains a file:

terraform.tfstate

🧠 This file stores:

• Real infrastructure details

• Resource IDs and attributes

• Mapping between Terraform code ↔ AWS resources

🔷 Step 2: Should You Push .tfstate to GitHub?

👉 ❌ NO — Never do this

⚠️ Why?

Because it contains:

• Secrets (API keys, credentials)

• Resource IDs

• Internal infrastructure data

👉 This can lead to security breaches

✅ Add to .gitignore

*.tfstate
*.tfstate.backup

🔷 Step 3: What if .tfstate is Deleted?

👉 Terraform loses tracking of infrastructure

❗ Result:

• Terraform thinks → nothing exists

• Next terraform apply → tries to recreate everything ❌

✅ Solutions:

• Restore from backup (.tfstate.backup)

• Use remote backend (best practice)

🔷 Step 4: State Conflict (Very Important)

🔹 Scenario:

• Developer 1 → runs terraform apply

• Developer 2 → runs terraform apply

❗ What Happens?

• Both modify same state file

• File gets overwritten or corrupted

👉 This is called State Conflict

🔷 Step 5: Solutions

❌ Local Shared State

• Not safe

• Not scalable

✅ Remote Backend (Best Practice)

Use:

• S3 Bucket → Store state file

• DynamoDB → Lock state

🔷 Step 6: Architecture Flow

🧠 Working:

1. Terraform stores state in S3

2. Before update → checks DynamoDB

3. If no lock → creates LockID

4. While locked → ❌ no parallel execution

5. After completion → lock removed

🔷 Step 7: Practical Implementation

📁 Step 1: Create Project Folder

mkdir remote-infra
cd remote-infra

📄 Step 2: Create Files

touch provider.tf terraform.tf s3.tf dynamodb.tf

🔧 Step 3: Provider Configuration

provider "aws" {
  region = "us-east-2"
}

📦 Step 4: Terraform Block

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

🪣 Step 5: Create S3 Bucket

resource "random_id" "suffix" {
  byte_length = 2
}

resource "aws_s3_bucket" "remote_s3" {
  bucket = "dev-tf-state-${random_id.suffix.hex}"

  tags = {
    Name        = "tf-state-bucket"
    Environment = "dev"
  }
}

🔐 Step 6: Create DynamoDB Table

resource "aws_dynamodb_table" "state_lock" {
  name         = "apurv-table"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }

  tags = {
    Name        = "apurv-table"
    Environment = "Dev"
  }
}

🔑 Step 7: IAM Permissions

Ensure your AWS user/role has:

• S3 Full Access

• DynamoDB Full Access

🔷 Step 8: Run Terraform

terraform init
terraform validate
terraform plan
terraform apply

🔷 Step 9: Configure Remote Backend

Now go to your main project folder and update:

terraform {
  backend "s3" {
    bucket         = "bucket<name>"
    key            = "terraform.tfstate"
    region         = "us-east-2"
    dynamodb_table = "apurv-table"
  }
}

🔄 Reinitialize

terraform init

🔷 Step 10: Remove Local State

rm terraform.tfstate*

✅ Verify Remote State

terraform state list

👉 Resources will still appear
✔ Because state is now stored in S3

🔷 Step 11: Test State Locking

Terminal 1:

terraform apply

Terminal 2:

terraform apply

❗ Result:

• Terminal 2 → ❌ blocked / waits

• Reason → Lock exists in DynamoDB

✔ After Completion:

• Lock is removed

• Second execution proceeds

• After testing all the things you can destroy your resources

🚀 Conclusion

• Terraform state is critical for infrastructure tracking

• Never store state locally in production

• Use S3 for storage + DynamoDB for locking

• Prevents:

  • Data loss

  • State conflicts

  • Security risks

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

📝 Abstract

Terraform works by maintaining a record of infrastructure in a state file. This state file acts as the bridge between your Terraform configuration and real-world resources (like AWS EC2, Security Groups, etc.).

In this blog, we will understand how Terraform manages state, why it is important, how to handle state manually, and how to import existing resources into Terraform.

🎯 Objectives

After completing this blog, you will be able to:

• Understand what Terraform state is

• Know why state management is important

• Sync Terraform state with real infrastructure

• Use important state commands

• Understand terraform import

• Handle real-world interview scenarios

🔷 Step 1: What is Terraform State?

Terraform maintains a file called:

terraform.tfstate

🧠 This file stores:

• All created resources (EC2, Security Groups, etc.)

• Current status of resources (running, stopped, IDs, etc.)

• Mapping between Terraform config ↔ real infrastructure

🔷 Step 2: Why State Management is Required

Terraform uses the state file to:

• Know what resources are already created ✅

• Track infrastructure changes ✅

• Avoid recreating resources unnecessarily ✅

• Compare desired state vs actual state ✅

🔷 Step 3: Important Scenario (Very Important)

🔹 Situation:

• EC2 is running in Terraform state

• You manually stop it from AWS Console

❓ Will Terraform automatically update state?

👉 ❌ NO

Terraform does not auto-detect manual changes.

🔷 Step 4: How to Sync State

To update Terraform state:

terraform refresh

OR

terraform apply

✔ Result

• Terraform reads real infrastructure

• Updates state file

👉 Example:
running → stopped

🔷 Step 5: State Management Commands

1️⃣ List All Resources

terraform state list

2️⃣ Show Resource Details

terraform state show aws_instance.my_instance

3️⃣ Remove Resource from State

terraform state rm aws_key_pair.my_key

🔷 Step 6: Important Interview Question

❓ What happens if you run:

terraform state rm aws_key_pair.my_key

🔥 Answer

• ❌ Resource is NOT deleted from AWS

• ✅ Only removed from Terraform state

👉 The actual resource still exists in AWS

🔷 Step 7: How to Restore Resource (Import Back)

If you removed resource from state by mistake:

terraform import aws_key_pair.my_key <key-Name-in aws>

✔ Result

• Resource is added back to Terraform state

• Terraform starts managing it again

🔷 Step 8: Importing Existing EC2 Instance

🧩 Step 1: Create Resource Block

resource "aws_instance" "my_instance" {
  ami           = "ami-xxxx"   # placeholder
  instance_type = "t2.micro"
}

👉 Values can be temporary/dummy

🧩 Step 2: Run Import Command

terraform import aws_instance.my_instance <instance-id>

👉 Example:

terraform import aws_instance.demo-instance i-1234567890abcdef0

🧩 Step 3: Verify

terraform state show aws_instance.my_instance

🧩 Step 4: Fix Configuration (Important)

After import:

terraform plan

👉 Then:

• Update .tf file with correct values

• Match actual AWS configuration

⚠️ Important Notes

• Import updates only state, not Terraform code

• You must manually update .tf files

• If configuration does not match → Terraform will try to modify resource

🚀 Conclusion

• Terraform state is the core of infrastructure tracking

• Manual changes are not auto-detected

• Use terraform refresh/apply to sync

• terraform state commands help manage resources

• terraform import is useful for existing infrastructure

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

📝 Abstract

In real-world DevOps projects, infrastructure often needs to behave differently based on environments such as development, staging, and production. Instead of writing separate configurations, Terraform provides conditional expressions (ternary operators) to dynamically assign values.

This blog explains how to use conditional expressions in Terraform to make infrastructure more flexible, reusable, and environment-aware.

🎯 Objectives

After completing this blog, you will be able to:

• Understand conditional expressions in Terraform

• Use the ternary operator syntax

• Apply conditions in real resources (EC2 example)

• Configure infrastructure based on environment (dev, prod)

• Test and verify conditional logic

🔷 Step 1: What is a Conditional Expression?

A conditional expression (also called a ternary operator) is used to assign values based on a condition.

🧠 Syntax

condition ? true_value : false_value

👉 Meaning

• If condition is true → use true_value

• If condition is false → use false_value

🔷 Step 2: Real Example (EC2 Root Volume)

root_block_device {
  volume_size = var.env == "prod" ? 20 : var.ec2_root_default_storage_size
  volume_type = "gp3"
}

🧠 Logic Explained

• If env = "prod" → volume size = 20 GB

• Else → volume size = default value (10 GB)

👉 This helps in automatically adjusting infrastructure based on environment

🔷 Step 3: Variables Used

variable "env" {
  default = "dev" or # "prod"
  type    = string
}

variable "ec2_root_default_storage_size" {
  default = 10
  type    = number
}

🔷 Step 4: Testing the Conditional Expression

✅ Case 1: Production Environment

env = "prod"

🔍 Output Behavior

• Condition → true

• Volume Size → 20 GB

✔ Instance will be created with larger storage (production-ready)

✅ Case 2: Development Environment

env = "dev"

🔍 Output Behavior

• Condition → false

• Volume Size → 10 GB

✔ Instance will be created with default storage (cost-saving)

🔷 Step 5: Why Use Conditional Expressions?

Using conditional expressions helps in:

• Reducing duplicate code

• Managing multiple environments easily

• Improving infrastructure flexibility

• Writing clean and reusable Terraform code

🔷 Step 6: Best Practices

• Use conditions for environment-based configurations

• Keep values simple and readable

• Avoid overly complex nested conditions

• Combine with variables for better control

🚀 Conclusion

• Conditional expressions allow dynamic value assignment

• Syntax is simple: condition ? true_value : false_value

• Useful for handling prod vs dev differences

• Makes Terraform code clean, scalable, and reusable

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

📝 Abstract

In Terraform, managing multiple resources efficiently is a common requirement in real-world DevOps projects. While creating multiple instances may seem straightforward, choosing the right approach can significantly impact scalability, flexibility, and maintainability.

This blog explores Terraform meta arguments, specifically count and for_each, and demonstrates how they behave differently when creating multiple resources. It also covers how outputs change based on these approaches and when to use depends_on for explicit dependencies.

🎯 Objectives

After completing this blog, you will be able to:

• Understand what meta arguments are in Terraform

• Create multiple resources using count

• Identify limitations of count

• Use for_each for better flexibility

• Handle outputs correctly for both approaches

• Understand the use of depends_on

🔷 Step 1: Understanding Meta Arguments

Meta arguments are special Terraform keywords that control resource behavior.

Common Meta Arguments:

• count

• for_each

• depends_on

• lifecycle

👉 In this tutorial, we focus on:

• count

• for_each

🔷 Step 2: Creating Multiple Resources using count

✅ Code

resource "aws_instance" "my_instance" {
  count         = 2
  ami           = var.ec2_ami_id
  instance_type = var.ec2_instance_type
}

🔍 Explanation

• Terraform creates 2 EC2 instances

• Indexed as:

aws_instance.my_instance[0]
aws_instance.my_instance[1]

🔷 Step 3: Output using count

output "ec2_public_ip" {
  value = aws_instance.my_instance[*].public_ip
}

🧠 Concept

• [*] → Splat Expression

• Used to extract values from multiple resources

🔷 Step 4: Limitation of count

Using count has restrictions:

• Same configuration for all instances

• Cannot assign:

  • Different names ❌

  • Different instance types ❌

🔷 Step 6: Using for_each (Better Approach)

resource "aws_instance" "my_instance" {
  for_each = {
    Apurv-1 = "t2.micro"
    Apurv-2 = "t2.medium"
  }

  ami           = var.ec2_ami_id
  instance_type = each.value

  tags = {
    Name = each.key
  }
}

🧠 Explanation

• each.key → Instance Name

• each.value → Instance Type

👉 Each instance becomes unique and configurable

🔷 apply terraform and check output

terraform apply 

🔷 Step 7: Why Old Output Fails

❌ Old Code

aws_instance.my_instance[*].public_ip

❗ Reason

• count → returns list

• for_each → returns map

👉 So [*] does not work here

🔷 Step 8: Correct Output with for_each

✅ Public IP

output "ec2_public_ip" {
  value = [
    for instance in aws_instance.my_instance :
    instance.public_ip
  ]
}

✅ Public DNS

output "ec2_public_dns" {
  value = [
    for instance in aws_instance.my_instance :
    instance.public_dns
  ]
}

✅ Private IP

output "ec2_private_ip" {
  value = [
    for instance in aws_instance.my_instance :
    instance.private_ip
  ]
}

🔷 Step 9: Final Result

After applying for_each:

• Different instance names ✅

• Different instance types ✅

• Correct outputs fetched ✅

🔷 Step 10: Understanding depends_on

✅ Definition

depends_on is used to explicitly define dependencies

⚙️ Example

depends_on = [
  aws_security_group.my_groups,
  aws_key_pair.my_key
]

🧠 When to Use

• When Terraform cannot detect dependency automatically

• When using hardcoded values

• When dependencies are indirect

❌ When NOT to Use

key_name = aws_key_pair.my_key.key_name

👉 Terraform automatically handles this (implicit dependency)

🚀 Conclusion

• Use count → for simple, identical resources

• Use for_each → for flexible and scalable setups

• Understand difference between list vs map outputs

• Use depends_on only when required

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

Welcome back to our Terraform journey. In infrastructure as code, setting up a server is just the beginning. After your EC2 instance is running, you need to set it up, install what it needs, and start your apps. Doing this by hand goes against the idea of automation.

In this post, we will demonstrate how to completely automate your server bootstrapping process using Terraform and the AWS user_data feature.

🎯 Objective

By the end of this guide, you will learn how to automatically install and configure an Nginx web server on a newly provisioned AWS EC2 instance using a Terraform user_data script.

🧩 Step 1: Understanding the Power of user_data

The Problem with Manual Configuration

Imagine you just used Terraform to spin up a fresh EC2 instance. Without an automation script, your next steps would look like this:

1. SSH into the instance.

2. Manually run package updates.

3. Install Nginx.

4. Start the service.

5. Create a custom HTML page.

This approach is time-consuming, prone to human error, and most importantly, not scalable. If you need to spin up 100 web servers behind a load balancer, logging into each one manually is impossible.

The Solution: Bootstrap Scripts

AWS provides a feature called user_data that allows you to pass a script to your instance at launch.

• ✔️ Runs automatically the very first time the instance boots.

• ✔️ Fully automates software installation and configuration.

• ✔️ Scales infinitely across as many instances as you deploy.

In short: user_data is your EC2 bootstrapping engine.

📄 Step 2: Create the Bootstrapping Script (nginx.sh)

First, we need to define the commands we want our server to run on startup. We will create a simple bash script that installs Nginx and creates a custom landing page.

Create a new file named nginx.sh:3

touch nginx.sh

Add the following content to the file:-

#!/bin/bash

# Update package lists
sudo apt-get update

# Install Nginx silently (-y prevents the prompt)
sudo apt-get install nginx -y

# Start the Nginx service
sudo systemctl start nginx

# Enable Nginx to start automatically if the server reboots
sudo systemctl enable nginx

# Create a custom HTML landing page
echo "<h1> Terraform testing with scripting </h1>" > /var/www/html/index.html

🔗 Step 3: Attach the Script in Terraform

Now, we need to tell Terraform to pass this script to our EC2 instance during creation. We do this by utilizing the file() function within the user_data argument of our aws_instance resource.

Open your ec2.tf file and configure your instance block:-

resource "aws_instance" "my_instance" {
  ami           = var.ec2_ami_id
  instance_type = var.ec2_instance_type

  # Attach your SSH key pair
  key_name = aws_key_pair.my_key.key_name

  # Attach the security group (make sure port 80 is open!)
  vpc_security_group_ids = [aws_security_group.my_groups.id]

  # Inject the bootstrap script here
  user_data = file("nginx.sh")

  # Define root storage
  root_block_device {
    volume_size = var.ec2_root_storage_size
    volume_type = "gp3"
  }

  tags = {
    Name = "terraform-ec2-nginx"
  }
}

⚙️ Step 4: Execute the Pipeline

With the script created and Terraform configured, it's time to deploy. Run the following commands in your terminal:

Bash

terraform init
terraform apply -auto-approve

What happens internally?

Once you hit apply, an elegant automated workflow kicks off:

1. Infrastructure Provisioned: Terraform calls the AWS API to launch a new EC2 instance.

2. Script Passed: The contents of nginx.sh are passed to the instance metadata.

3. Bootstrapping Execution: As the EC2 instance boots up, the OS executes the script as the root user.

4. App Deployed: Packages are updated, Nginx is installed, the service is started, and your custom HTML page is generated.

Within minutes, you can grab the public IP of your new EC2 instance, paste it into your browser, and see your custom HTML page—zero SSH required.

🧪 Testing: Verify NGINX on EC2 Instance

After provisioning the EC2 instance using Terraform, we need to test whether NGINX is properly installed and running.

🔹 Step 1: Connect to EC2 via SSH

ssh -i "your-key.pem" ubuntu@<EC2-PUBLIC-IP>

✔ Replace:

• your-key.pem → your private key

• <EC2-PUBLIC-IP> → instance public IP

🔹 Step 2: Check NGINX Status

sudo systemctl status nginx

✔ Expected Output:

• active (running) → ✅ NGINX is working

• inactive / failed → ❌ issue needs fixing

🔹 Step 3: Test via Browser

Open your browser and hit:

http://<EC2-PUBLIC-IP>

✔ Expected:

• Default NGINX Welcome Page

🔹 Step 5: Test via Curl (CLI Testing)

curl http://localhost

OR from your local system:

curl http://<EC2-PUBLIC-IP>

✔ If HTML response comes → ✅ Server is working

🔹 Step 6: Check Port 80 (Important for DevOps)

sudo netstat -tulpn | grep :80

OR

sudo ss -tulpn | grep :80

✔ Confirms:

• NGINX is listening on port 80

💡 Key Takeaways

• No More Manual SSH: Bootstrapping completely eliminates the need to manually configure infrastructure after it is provisioned.

• Separation of Concerns: By using the file() function, you keep your shell scripts separate from your Terraform code, making both easier to maintain.

• Idempotency and Scale: A script guarantees that every server you provision will be configured exactly the same way, every single time.

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

In real-world DevOps, writing flexible and reusable code is very important.
Today, we will learn how to use Variables and Outputs in Terraform to make our infrastructure clean, dynamic, and production-ready.

Till now, we were writing Terraform code…
but there was one problem 👇

👉 Everything was hardcoded

And in real DevOps, hardcoding = BIG mistake ❌

So today we fix that 💡

🧩 Step 1: The Real Problem

Imagine this:

instance_type = "t2.micro"

Looks simple… but 👇

❌ Want to upgrade instance? Change everywhere

❌ Want reuse? Not possible

❌ Working in team? Becomes messy

👉 Basically: Not scalable

💡 Step 2: The Smart Solution → Variables

Instead of fixing values in code, we use variables

Think like this:
👉 “Keep values separate, keep code clean”

✔ Why Variables?

• Change once → Apply everywhere

• Clean & readable code

• Reusable infrastructure

• Industry-level practice

📌 In short:
Variables = Flexibility + Clean Code + DevOps Standard

📄 Step 3: Create variables.tf

variable "ec2_instance_type" {
  default = "t2.micro"
  type    = string
}

variable "ec2_root_storage_size" {
  default = 10
  type    = number
}

variable "ec2_ami_id" {
  default = "ami-0cb91c7de36eed2cb"
  type    = string
}

🧠 Simple Understanding:

• variable → variable name

• default → default value

• type → data type

👉 Values are now separated from the main code ✅

🔗 Step 4: Use Variables in ec2.tf

Now the real magic 🔥

# Create Key Pair
resource "aws_key_pair" "my_key" {
  key_name   = "terra-key-aws"
  public_key = file("terra-key-aws.pub")
}


# Default VPC
resource "aws_default_vpc" "default" {}

# Security Group
resource "aws_security_group" "my_groups" {
  name        = "my-group"
  description = "Security group for EC2"
  vpc_id      = aws_default_vpc.default.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow SSH"
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow HTTP"
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow all outbound"
  }

  tags = {
    Name = "automate-sg"
  }
}

# EC2 Instance
resource "aws_instance" "my_instance" {
  ami                    = var.ec2_ami_id
  instance_type          = var.ec2_instance_type
  key_name               = aws_key_pair.my_key.key_name
  vpc_security_group_ids = [aws_security_group.my_groups.id]

  root_block_device {
    volume_size = var.ec2_root_storage_size
    volume_type = "gp3"
  }

  tags = {
    Name = "terra-ec2"
  }
}

⚡ Important Line:

var.<variable_name>

👉 Example:

var.ec2_instance_type

🔄 Step 5: Real Power of Variables

Before:

instance_type = "t2.micro"

After:

default = "t3.micro"

✔ Change in one place

✔ Applied everywhere automatically

🔥 That’s the power

📤 Step 6: Now Let’s Talk About Outputs

Deployment is done… but now 👇

👉 How do you get EC2 Public IP?

😓 Problem

❌ You have to manually check AWS Console

💡 Solution → Outputs

Terraform will show it directly 🔥

📄 Step 7: Create outputs.tf

output "ec2_public_ip" {
  value = aws_instance.my_instance.public_ip
}

output "ec2_public_dns" {
  value = aws_instance.my_instance.public_dns
}

🧠 What Happens Now?

When you run:

terraform apply

👉 At the end, Terraform shows:

✔ Public IP

✔ Public DNS

Directly in terminal 🎯

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

In this hands-on, we will:

• Generate SSH key

• Create key pair using Terraform

• Configure VPC & Security Group

• Launch EC2 instance

• Connect via SSH

• Clean up resources

👉 This is your first real-world Terraform task

🧩 Step 1: Generate SSH Key

ssh-keygen

✔ This creates:

• terra-key-aws→ Private key

• terra-key-ec2.pub → Public key

👉 We will use this to access EC2

📄 Step 2: Create Terraform File

touch ec2.tf

🧱 Step 3: Add Terraform Code

# Create Key Pair
resource "aws_key_pair" "my_key" {
  key_name   = "terra-key-aws"
  public_key = file("terra-key-aws.pub")
}


# Default VPC
resource "aws_default_vpc" "default" {}

# Security Group
resource "aws_security_group" "my_groups" {
  name        = "my-group"
  description = "Security group for EC2"
  vpc_id      = aws_default_vpc.default.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow SSH"
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow HTTP"
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
    description = "Allow all outbound"
  }

  tags = {
    Name = "automate-sg"
  }
}

# EC2 Instance
resource "aws_instance" "my_instance" {
  ami                    = "ami-0cb91c7de36eed2cb"
  instance_type          = "t2.micro"
  key_name               = aws_key_pair.my_key.key_name
  vpc_security_group_ids = [aws_security_group.my_groups.id]

  root_block_device {
    volume_size = 10
    volume_type = "gp3"
  }

  tags = {
    Name = "terra-ec2"
  }
}

⚙️ Step 4: Initialize Terraform

terraform init

✔ Downloads AWS provider

✔ Prepares working directory

✅ Step 5: Validate Configuration

terraform validate

✔ Ensures syntax is correct

📊 Step 6: Plan Execution

terraform plan

✔ Shows resources to be created:

• Key Pair

• VPC

• Security Group

• EC2 Instance

🚀 Step 7: Apply (Create Infrastructure)

terraform apply

👉 Type yes to confirm

❌ Common Error: Not Authorized

👉 Reason:

• IAM user does not have required permissions

✔ Fix:

Go to AWS IAM → Attach Policy

• AdministratorAccess (easy way)

  OR

• EC2FullAccess

• VPCFullAccess

🖥 Step 8: Verify in AWS Console

Go to EC2 Dashboard:

✔ Instance running
✔ Security group attached
✔ Key pair created

🔐 Step 9: Fix Key Permission

chmod 400 terra-key-aws

👉 Required before SSH

🔗 Step 10: Connect to EC2

ssh -i terra-key-aws ubuntu@<your-public-ip>

👉 Now your server is live 🚀

🧹 Step 11: Destroy Resources (IMPORTANT)

terraform destroy

👉 Prevent unnecessary AWS charges 💸

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

In today’s Terraform journey, I explored one of the most fundamental concepts that every DevOps engineer must understand Providers and Resource Naming Structure.

These concepts are the backbone of Terraform because they define how Terraform communicates with real-world infrastructure.

🧠 1. Understanding Terraform Resource Structure

Every infrastructure component in Terraform is defined using a resource block.

📌 Syntax:

resource "<provider>_<resource_type>" "<name>" {
  arguments
}

📌 Example:

resource "aws_instance" "my_vm" {
  instance_type = "t2.micro"
}

🔍 Deep Breakdown:

• provider (aws)
  → Defines which platform you are using (AWS, GCP, Azure, etc.)

• resource_type (instance)
  → Specifies what you want to create (VM, bucket, network, etc.)

• name (my_vm)
  → A local identifier inside Terraform (you can name it anything)

• arguments
  → Configuration details (size, region, OS, etc.)

⚡ Important Insight:

👉 Terraform does not identify resources by name alone, but by:

provider + resource_type + name

This combination must always be unique.

🌐 2. What is a Provider in Terraform?

A provider is a plugin that allows Terraform to interact with external APIs.

👉 In simple words:

Provider = Bridge between Terraform and Cloud/Service

🔧 Why Providers are Needed?

Without providers:

• Terraform cannot talk to AWS, GCP, or any service

• No infrastructure can be created

📌 Popular Providers:

• AWS (Amazon Web Services)

• Google Cloud Platform (GCP)

• Azure

• Local (for files, local operations)

⚡ Real-Life Analogy:

Think of Terraform as a remote control
and providers as the signal system that connects it to devices.

Without signals → remote is useless ❌

⚙️ 3. Ways to Use Providers in Terraform

Terraform gives flexibility in how you define providers.

🔹 Method 1: Implicit Provider (Automatic Way) ✅

👉 The easiest and most beginner-friendly method.

You don’t explicitly define the provider — Terraform automatically detects it.

📌 Example:

resource "aws_instance" "my_vm" {
  ami           = "ami-0ec10929233384c7f"   # Example Ubuntu AMI (Mumbai)
  instance_type = "t2.micro"

  tags = {
    Name = "Terraform-VM"
  }
}

🔍 What Happens Behind the Scenes?

1. Terraform sees aws_instance

2. It understands provider = aws

3. During initialization, it automatically downloads the provider

▶️ Steps:

terraform init

✔ Provider gets installed automatically

✔ No manual configuration needed

👍 When to Use:

• Learning phase

• Small projects

• Quick testing

🔹 Method 2: Explicit Provider (Declarative Way) ✅

👉 This is the recommended approach for real-world projects.

You explicitly define:

• Provider source

• Version

📌 Step 1: Define Providers

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

# Configure the AWS Provider
provider "aws" {
  region = "us-east-1"
}

📌 Step 2: Initialize

terraform init

🔍 What Happens:

• Terraform downloads exact versions

• Ensures consistency across systems

• Prevents unexpected breaking changes

👍 When to Use:

• Production environments

• Team projects

• Version-controlled infrastructure

⚡ 4. Implicit vs Explicit (Quick Understanding)

Implicit:

• Automatic

• Less control

• Beginner-friendly

Explicit:

• Manual definition

• Full control

• Production-ready

🚀 5. Pro Tips (Important for DevOps)

✔ Always use explicit providers in real projects
✔ Lock provider versions to avoid errors
✔ Run terraform init after any provider change
✔ Keep provider configuration in a separate file (best practice)

📌 Final Summary

• Terraform uses providers to connect with cloud/services

• Resource naming follows:

  <provider>_<resource_type>
  

• Providers can be:

  • Automatically detected (Implicit)

  • Manually defined (Explicit)

• terraform init is required to install providers

🔥 Conclusion

Understanding providers is a game-changer in Terraform.

Once you master this concept, you unlock the ability to:

• Work with multiple cloud platforms

• Write scalable infrastructure code

• Build real-world DevOps projects

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

🧠 Before Starting (AWS Setup)

Before using Terraform with AWS, we first need to configure AWS access on our local machine.

👉 Steps:

• Install AWS CLI

• Configure AWS using:

aws configure

👉 It will ask for:

• AWS Access Key

• Secret Key

• Region

• Output format

✅ After this setup, Terraform can interact with your AWS account.

🎯 Objective

• Understand Terraform workflow

• Learn core commands

• Perform hands-on execution

🧱 Step 0: Create Terraform Configuration File

👉 Create a file:

main.tf

👉 This file contains your Terraform infrastructure code

⚙️ Step 1: Initialize Terraform

🔹 Command:

terraform init

🔹 Purpose:

• Initializes working directory

• Downloads required providers

• Prepares environment

✅ Step 2: Validate Configuration

🔹 Command:

terraform validate

🔹 Purpose:

• Checks syntax of .tf files

• Ensures configuration is valid

👉 “Check if your code is correct”

📊 Step 3: Review Execution Plan

🔹 Command:

terraform plan

🔹 Purpose:

• Shows what Terraform will do

• Lists resources to create/change/destroy

• Works as a dry run

👉 “Preview before execution”

🚀 Step 4: Apply Configuration

🔹 Command:

terraform apply

🔹 Purpose:

• Executes the plan

• Creates real infrastructure

👉 Type yes to confirm

🧨 Step 5: Destroy Infrastructure

🔹 Command:

terraform destroy

🔹 Purpose:

• Deletes all resources

• Avoids unnecessary cloud cost

⚡ Auto-Approve Option

terraform apply -auto-approve
terraform destroy -auto-approve

👉 Skips confirmation

👉 Useful in automation (CI/CD)

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

In Day 2, we installed Terraform.
Now, before writing real infrastructure code, we must understand how Terraform actually reads and executes configurations.

👉 Every Terraform file is built using 3 core concepts:

• Blocks

• Labels

• Arguments

🔹 1. What is a Block?

👉 A block is the main building unit in Terraform used to define infrastructure or configuration.

📌 Example:

resource "aws_instance" "my_vm" {
}

👉 Meaning:

• Block tells Terraform what you want to create

📌 Common blocks:

• resource

• provider

• variable

• output

🔹 2. What are Labels?

👉 Labels are identifiers of a block that define resource type and name.

📌 Example:

resource "aws_instance" "my_vm" {
}

👉 Meaning:

• aws_instance → resource type

• my_vm → resource name

👉 Used to uniquely identify resources

🔹 3. What are Arguments?

👉 Arguments are key-value pairs inside a block used to configure the resource.

📌 Example:

instance_type = "t2.micro"

👉 Meaning:

• Defines how the resource should be created

• Controls behavior and properties

🔗 Combined Example

resource "aws_instance" "my_vm" {
  instance_type = "t2.micro"
}

👉 Breakdown:

• Block → resource

• Labels → aws_instance, my_vm

• Argument → instance_type

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

In Day 1, we understood the fundamentals of Terraform and Infrastructure as Code (IaC).
Now, in Day 2, we will set up Terraform in real environments.

This guide covers installation on:

• AWS EC2 (Ubuntu)

• Local Ubuntu Machine

• Windows (using Chocolatey)

🎯 Objective

• Install Terraform in different environments

• Follow secure installation practices

• Verify installation properly

☁️ Part 1: Setup on AWS EC2 (Ubuntu)

🧱 Step 1: Create EC2 Instance

• Go to AWS EC2 Dashboard

• Click Launch Instance

• Select:

  • OS → Ubuntu

  • Instance Type → t2.micro (Free Tier)

• Create key pair

• Launch instance

🔐 Step 2: Connect via SSH

ssh -i your-key.pem ubuntu@your-ec2-public-ip

📦 Step 3: Update System

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common

🔑 Step 4: Add HashiCorp GPG Key

wget -O- https://apt.releases.hashicorp.com/gpg | \
gpg --dearmor | \
sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null

✅ Step 5: Verify GPG Key

gpg --no-default-keyring \
--keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \
--fingerprint

👉 Ensures authenticity and security

📁 Step 6: Add Repository

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/hashicorp.list

🔄 Step 7: Update Packages

sudo apt-get update

⚙️ Step 8: Install Terraform

sudo apt-get install terraform

🔍 Step 9: Verify Installation

terraform --version

💻 Part 2: Local Installation (Ubuntu)

👉 Follow the same steps as EC2

No changes required — works exactly the same.

🪟 Part 3: Terraform Installation on Windows

📦 Step 1: Install using Chocolatey

choco install terraform

👉 Make sure Chocolatey is installed on your system

🔍 Step 2: Verify Installation

Open a new terminal (CMD/PowerShell):

terraform -help

Expected output:

Usage: terraform [global options] <subcommand> [args]

👉 Shows all available Terraform commands

⚡ Enable Autocomplete (Optional but Recommended)

🐧 Bash

touch ~/.bashrc
terraform -install-autocomplete

🐚 Zsh

touch ~/.zshrc
terraform -install-autocomplete

👉 Restart terminal after this step

📘 Alternative Installation Method

You can also install Terraform using the official HashiCorp documentation depending on your OS and requirements.

Terraform official Documentation

👨‍💻 About the Author

“This Kubernetes series focuses on building a strong foundation by understanding real Kubernetes concepts step by step.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

In modern DevOps practices, managing infrastructure manually is no longer scalable or efficient. Organizations are rapidly shifting towards automation and Infrastructure as Code (IaC) to ensure consistency, speed, and reliability.

This is where Terraform plays a crucial role.

📌 What is Terraform?

Terraform is an Infrastructure as Code (IaC) tool developed by HashiCorp that enables you to define, provision, and manage infrastructure using code.

• Uses HCL (HashiCorp Configuration Language)

• Follows a declarative approach

• Automates infrastructure lifecycle

👉 Instead of manually creating resources, you define them in code and Terraform handles the execution.

🏢 About HashiCorp

HashiCorp is a technology company focused on building tools for:

• Infrastructure automation

• Security management

• Application deployment

👉 Founded in 2014
👉 By Mitchell Hashimoto and Armon Dadgar

Some popular tools by HashiCorp:

• Terraform

• Vault

• Consul

• Nomad

⚡ Why Terraform Matters in DevOps

In real-world environments, infrastructure needs to be:

• Consistent across environments

• Scalable based on demand

• Repeatable without errors

• Automated to reduce manual effort

Terraform enables all of this by:

• Eliminating manual provisioning

• Enforcing infrastructure consistency

• Supporting version control (Git-based workflows)

• Enabling multi-cloud deployments

🌍 Real-World DevOps Scenario

Consider a company managing multiple environments:

• Development

• Testing

• Production

Each environment requires:

• Virtual Machines

• Networking setup

• Load balancing

❌ Without Terraform

• Manual configuration

• Time-consuming process

• High probability of human errors

• Difficult to maintain consistency

✅ With Terraform

• Define infrastructure once

• Reuse configurations across environments

• Deploy with a single command

• Modify using variables and version control

👉 Result: Faster, reliable, and scalable infrastructure management

⚔️ Terraform vs Other Tools

🔹 Terraform vs Ansible

Terraform

• Focus: Infrastructure provisioning

• Creates resources such as:

  • Virtual Machines

  • Networks

  • Load Balancers

Ansible

• Focus: Configuration management

• Handles:

  • Software installation

  • System updates

  • Application setup

👉 In practice:
Terraform → Creates infrastructure
Ansible → Configures infrastructure

🔹 Terraform vs AWS CloudFormation

Terraform

• Supports multiple cloud providers:

  • AWS

  • Azure

  • GCP

• Enables multi-cloud strategy

AWS CloudFormation

• Limited to AWS ecosystem only

👉 Terraform provides flexibility, while CloudFormation is AWS-specific

🧠 Key Takeaways

• Terraform is a core DevOps tool for Infrastructure as Code

• It replaces manual infrastructure setup with automated workflows

• Supports multi-cloud environments

• Ensures consistency, scalability, and efficiency

👨‍💻 About the Author

“A complete Terraform series covering everything from fundamentals to advanced real-world infrastructure automation in a DevOps environment.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar

🟢 Interview Question 1: “Tell me about yourself.”

Answer I Gave :-

“Good morning/afternoon, and thank you for giving me this opportunity to introduce myself.

My name is Gujjar Apurv, and I am a final-year BE student in Electronics and Communication Engineering. Over the past two years, I have been actively learning and practicing DevOps and Cloud technologies with strong hands-on experience. To validate my technical skills, I appeared for and successfully cleared the AWS Associate Developer certification exam, which has strengthened my foundation in cloud concepts and AWS services.

Recently, I was completed a Cloud Internship as a Cloud Intern at Corextech IT Services, where I gained practical experience with AWS services such as EC2, VPC, IAM, RDS, Route 53, AWS Lambda, S3, and many more. During this internship, I assisted in the deployment and monitoring of cloud-based systems. Based on my performance, the company assigned me an additional one-month responsibility to work on their live projects.

I have worked on multiple hands-on projects, although I have highlighted only two major ones in my resume.

The first project is the Netflix Clone Project, where I built a complete CI/CD pipeline using Jenkins, Docker, GitHub Actions, monitoring tools, and security integrations. I also implemented DevSecOps practices with live monitoring.

The second project is an AWS Three-Tier Secure Application, where I designed a scalable architecture using EC2, VPC, Subnets, RDS, Route Tables, ALB, and various other AWS components.

Along with technical work, I have also written technical blogs to explain my projects and tools, which helped me demonstrate my technical understanding and documentation skills.

These experiences have helped me build confidence in automation, deployment, cloud monitoring, Linux server handling, and scripting skills that are essential in the DevOps industry.

Thank you.”

🟢 Interview Question 2: “Why did you choose DevOps, and what is DevOps?”

“I chose DevOps because I enjoy automation, cloud technologies, and improving system efficiency. DevOps matches my problem-solving mindset and gives me the opportunity to work end-to-end building faster, scalable, and reliable environments.”

“DevOps is a set of practices that helps teams build and deploy software faster using automation. It reduces errors, improves delivery speed, and enhances collaboration between development and operations teams.”

🟢 Interview Question 3: “Give one DevOps example which is related to the industry.”

“For example, when a developer pushes code to GitHub, a CI/CD pipeline automatically builds, tests, and deploys the application to the server. This removes manual steps, reduces errors, and speeds up software delivery.

🟢 Interview Question 4: “What is your strength and weakness?”

Answer I Gave:
✅ Strength:
“My strength is that I am a quick learner and I adapt to new technologies faster.
⚠️ Weakness:
“My weakness is that I am detail-oriented, and sometimes I over-polish my work.

🟢 Interview Question 5: “What is Cloud vs Cloud Computing?”

Answer I Gave:

☁️ Cloud:

“The cloud is a platform that stores and analyzes data over the internet instead of using a local system.”

💻 Cloud Computing:

“Cloud computing provides the delivery of computing resources like servers, storage, databases, and networking over the internet, without managing physical hardware.”

🟢 Interview Question 6: “Types of Cloud?”

Answer I Gave:

• Public Cloud: Open for all users publicly over the internet.
  Example: AWS, Azure, Google Cloud

• Private Cloud: Not publicly accessible; used by a specific organization.
  Example: VMware, OpenStack

• Hybrid Cloud: A combination of public and private cloud models.
  Example: AWS + VMware integration

🟢 Interview Question 7:(common for both interview )

“What are Cloud Service Models, and how do they compare with AWS services?”**

Answer I Gave:

Cloud services are divided into three main models:

1️⃣ IaaS – Infrastructure as a Service

Provides virtual infrastructure like servers, storage, and networking resources.

AWS Examples:

• EC2 (Compute)

• EBS (Storage)

• S3 (Object Storage)

• VPC (Networking)

• ELB (Load Balancing)

2️⃣ PaaS – Platform as a Service

Provides a platform to build, run, and manage applications without managing infrastructure.

AWS Examples:

• RDS (Database Platform)

• Lambda (Serverless Platform)

• ECS / EKS (Container Platforms)

3️⃣ SaaS – Software as a Service

Provides ready-to-use software or tools on the cloud.

AWS Examples:

• CloudWatch (Monitoring Tool)

• Amazon WorkMail (Email Service)

• AWS Chime (Communication Service)

🟢 Interview Question 8: -“What protocols do you know in cloud networking?”

Answer I Gave:

I mentioned the basic cloud networking protocols and explained each in one line with examples:

1️⃣ HTTP / HTTPS

Used for web communication between client and server.
Example: Accessing websites or APIs through browsers.

2️⃣ SMTP

Used for sending emails over the internet.
Example: Email delivery systems and notification services.

3️⃣ DNS

Used to translate domain names into IP addresses.
Example: Creating DNS records on Route 53.

4️⃣ TCP / UDP

Transport layer protocols used for sending data packets between devices.
Example: SSH uses TCP; streaming uses UDP.

5️⃣ POP3 (Post Office Protocol version 3)

Used to receive emails from a mail server.
Example: Inbox downloading in email clients.

🟢 Interview Question 9:- “How will you host a website on AWS? Explain for both static and dynamic websites.

Answer I Gave:

I asked whether the website is static or dynamic. The interviewer said both, so I explained each case separately:

1️⃣ Static Website Hosting on AWS

For a static website, I would:

• Use S3 to store static files like HTML, CSS, JS.

• Enable Static Website Hosting in S3.

• Use CloudFront CDN for caching and global delivery.

• Use Route 53 for DNS mapping to a domain name.

👉 Result: Fast, secure, scalable static website hosting.

2️⃣ Dynamic Website Hosting on AWS

For a dynamic website, I would:

• Use EC2 instance to run the backend application.

• Use Load Balancer (ALB/ELB) to distribute traffic.

• Use Auto Scaling Group to handle traffic load.

• Use RDS database for storage.

• Use VPC for secure networking.

• Use Route 53 to map the domain.

👉 Result: Highly available, secure and scalable dynamic website architecture.

🟢 Interview Question 10: (IMP)

“Difference Between static and dynamic hosting, why is it needed, and how does it work?”

Answer I Gave:

I explained that DNS is used in both static and dynamic hosting, because in both cases users access the website through a domain name, and DNS maps that domain to the correct server or endpoint.

Static website hosting serves fixed content directly from S3 via CloudFront, and DNS points to the CloudFront distribution.
Dynamic website hosting generates real-time content using EC2 (behind ALB) with a database like RDS, and DNS points to the ALB.

📌 Why DNS is needed?

DNS converts a domain name into an IP address or endpoint URL so browsers can locate the server or hosting resource.

📌 Type of DNS Records I Mentioned:

1️⃣ A Record (Address Record)

Maps a domain to an IP address.

• In static hosting → rarely needed, unless pointing to CloudFront IP via LB.

• In dynamic hosting → points to EC2 or Load Balancer IP.

Example:
example.com → 54.xx.xx.xx (EC2 public IP / LB IP)

2️⃣ CNAME (Canonical Name Record)

Maps one domain name to another domain name.
Used for endpoints instead of IP.

Example:
www.example.com → xyz.cloudfront.net
app.example.com → loadbalancer.aws.com

📌 Step-by-Step DNS Workflow I Explained:

1️⃣ User types domain name in browser
2️⃣ DNS checks domain record
3️⃣ If A Record → returns server IP
4️⃣ If CNAME → returns mapped domain → then endpoint resolves to IP
5️⃣ Browser connects to that IP
6️⃣ Website loads from static bucket / LB / EC2

🟢 Interview Question 11:

“If you have one EC2 instance running a website, can you host it using S3 or Route 53? If yes, how? What IP and record type will you assign?”

Answer I Gave:

“Yes, a website running on a single EC2 instance can be hosted using Route 53. Since it is a dynamic website, I will assign an Elastic IP to the EC2 instance and create an A record in Route 53 pointing the domain to that Elastic IP. S3 is not required because EC2 is directly serving the application.”

🟢 Interview Question 12:

“How do you create an EC2 instance? What are inbound/outbound rules? Can you launch multiple EC2s at once?”

Answer I Gave:

✔️ How to create EC2:

“Select AMI → select instance type → configure storage & network → add security group rules → launch → SSH connect.”

✔️ Inbound Rules:

“Allow traffic coming into EC2, like HTTP (80), HTTPS (443), SSH (22).”

✔️ Outbound Rules:

“Allow traffic going out from EC2, usually open to all by default.”

✔️ Multiple EC2 instances:

“Yes, we can launch multiple instances together by increasing instance count during launch or using Auto Scaling.”

🟢 Interview Question 13:

“What is VPC?”

Short Answer I Gave:-

“VPC stands for Virtual Private Cloud, and it is used as a secure and isolated network in AWS.”

🟢 Interview Question 14:

“How did you implement your 3-tier architecture project?”

Short Answer I Gave:

“First, I created a custom VPC. Then I created one public and two private subnets. After that, I attached an Internet Gateway for public access and configured a NAT Gateway for private subnet outbound access. Next, I configured route tables for public and private subnets. Then I launched EC2 instances for the web tier in the public subnet and app and database tiers in private subnets. Finally, I configured security groups to allow only required communication between the tiers.”

🟢 Interview Question 15:

“If your server gets millions of traffic, how will you handle it?”

Short Answer I Gave:

“To handle high traffic, I will use a Load Balancer to distribute requests across multiple servers. If the application needs more scalability and fault tolerance, I can migrate to Kubernetes, which automatically manages scaling, load distribution, and high availability.”

🟢 Interview Question 16:

“Which subnets use inbound and outbound rules, and what are inbound and outbound rules?”

Short Answer I Gave:-

Inbound Rules:
“Allow traffic coming into the instance like HTTP (80), HTTPS (443), SSH (22).”

Outbound Rules:
“Allow traffic going out from the instance usually open for internet access or updates.”

Subnet Preference:
“Public subnets allow inbound internet traffic; private subnets allow inbound only from internal networks.”

🟢 Interview Question 17:

“You have 1 VPC with 3 subnets (Subnet-1 Public, Subnet-2 Private, Subnet-3 Private). Subnet-1 has 3 EC2 instances and other subnets have 1 EC2 each. If you want EC2s inside the public subnet to communicate with each other, will you use Internet Gateway? If yes/no, why? And how will subnet communication happen?”

Answer I Gave:

✔️ Communication inside same subnet:

“No, Internet Gateway is not required because instances in the same subnet can communicate with each other privately using internal IPs.”

✔️ Communication between different subnets:

“To communicate across Subnet-1, Subnet-2, and Subnet-3, I will use the same VPC routing. All subnets inside a VPC are already connected by default, so instances can communicate using private IPs without Internet Gateway.”

✔️ Why Internet Gateway is not needed:

“Internet Gateway is only needed for public internet access, not for internal VPC communication.”

✔️ How Subnet-1 will communicate with Subnet-2 & Subnet-3:

“Since all subnets are in the same VPC, VPC routing table already allows internal communication. So EC2s can talk to each other using private IPs. No VPC peering or Internet Gateway is required.”

🟢 Interview Question 18:

“If each subnet is in a different VPC, how will you make EC2 instances communicate with each other?”

Short Answer I Gave:

“If each subnet is in a different VPC, I will use VPC Peering or Transit Gateway, then update route tables and security groups so EC2 instances can communicate privately without using the Internet Gateway.”

🟢 Interview Question 19:

“In VPC communication, do we use Internet Gateway or NAT Gateway for communication? Why not? And why do we use VPC Peering or Transit Gateway instead?”

Short Answer I Gave:

• We don’t use Internet Gateway or NAT Gateway for VPC-to-VPC communication, because they are used for internet access, not internal private communication.

• For connecting VPCs, we use VPC Peering or Transit Gateway because they allow private, secure communication between VPC networks.

🟢 Interview Question 20:

“What is internet access in EC2, why do we assign a public subnet, is EC2 public by default, and how do you access it?”

Answer I Gave:

✔️ What is internet access in EC2?

“Internet access means the EC2 instance can send and receive traffic from the internet using a public IP and Internet Gateway.”

✔️ Why do we assign a public subnet?

“To give EC2 internet access through the Internet Gateway. Public subnet allows the instance to be reachable from the outside network.”

✔️ Is EC2 public by default?

“No. EC2 becomes public only if:

• Public IP is enabled

• Subnet route points to Internet Gateway

• Security group allows traffic”

✔️ How do we access EC2?

“We can access EC2 using SSH with a public IP and key pair, or through EC2 Instance Connect from the AWS console.”

🟢 Interview Question 21:

“What is a Region in AWS? Explain with example. What is an Availability Zone?”

Answer I Gave:

✔️ What is Region in AWS?

“A Region is a physical geographical location where AWS data centers are hosted.”

Example:

• Mumbai Region → ap-south-1

• North Virginia Region → us-east-1

✔️ What is Availability Zone (AZ)?

“AZ is a group of isolated data centers inside a region that work together to provide high availability.”

Example:

• Mumbai Region has AZs like:

  • ap-south-1a

  • ap-south-1b

  • ap-south-1c

🟢 Interview Question 22:

“What is an IAM Role and how do you use it?”

Answer I Gave:

What is IAM Role?
“An IAM Role gives permission to AWS services or users without needing access keys.”

How to use it?
“Attach the role to EC2, Lambda, or any service to allow secure resource access.”

🟢 Interview Question 23:-

“Which AWS service works in a serverless model?”

Answer I Gave:

“AWS Lambda is a serverless compute service that runs code without managing servers. You only upload code, and Lambda handles scaling automatically.”

✅ Linux Commands for DevOps – Quick Reference Table

🟢 Interview Question 24:

“What is the difference between Virtual Machines and Docker?”

Answer I Gave:

Short Answer:
“VMs are heavy and slow because they run full OS; Docker is fast and lightweight because it uses containers and shares the host OS.”

🟢 Interview Question 25:

“What is Docker and why do we use it?”

Answer I Gave:
“Docker is a tool used to create, run, and manage containers for applications. It helps applications run faster, improves portability, and makes deployment easy.”

🟢 Interview Question 26:

“What is a Docker Image and what is a Docker Container?”

Answer I Gave:

Short Answer:
“A Docker image is a blueprint, and a container is the running instance created from that image.”

🟢 Interview Question 27:

“If Docker is available, why do we use Kubernetes? What is the difference?”

Answer I Gave:

Docker:
“Docker is used to create and run containers.”

Kubernetes:
“Kubernetes is used to manage and scale containers automatically across multiple servers.”

Short Difference:
“Docker runs containers. Kubernetes manages many containers.”

🟢 Interview Question 28:

“What is a Dockerfile? Give example and build command.”

Answer I Gave:
“A Dockerfile is a script that contains instructions to build a Docker image automatically.”

Example Dockerfile:

FROM python:3.9
COPY app.py .
CMD ["python", "app.py"]

Build Command:

docker build -t app .

app is the image name

🟢 One Line Logic:

“Dockerfile creates the image, and Docker Compose runs the image.”

🟢 Interview Question 29:

“What is Docker Compose and how does it work? Give example.”

Answer I Gave:
“Docker Compose is a tool used to run multiple containers together using a single YAML file. It helps manage multi-container applications easily.”

📌 How it works:

• We write all container details inside docker-compose.yml

• Then run all containers with one command

• 📌 Example:

docker-compose.yml:

version: '3'
services:
  web:
    image: nginx
    ports:
      - "80:80"

📌 Command:

docker-compose up -d

🟢 Interview Question 30 : -

“If your system gets millions of traffic and you don’t want to manage EC2 manually, what will you use?”

Answer I Gave:
“I will use Kubernetes because it automatically handles scaling, deployment, traffic distribution, self-healing, and node management. It creates and manages containers without manually launching EC2 instances.”

🟢 Interview Question 31:

“What is Kubernetes?”

Answer I Gave:
“Kubernetes is a container orchestration tool that automates deployment, scaling, and management of containerized applications.”

🟢 Interview Question 32:

“What are Pod, Deployment, and Service in Kubernetes?”

Answer I Gave:

✔️ Pod:

“Pod is the smallest unit in Kubernetes that runs one or more containers.”

✔️ Deployment:

“Deployment manages multiple Pods and enables easy updates, scaling, and rollback.”

✔️ Service:

“Service exposes Pods to the network so applications can communicate internally or externally.”

🟢 Interview Question 33:

“First, when a developer pushes code to GitHub, it triggers the CI pipeline.
The pipeline pulls the code and automatically builds the application using GitHub Actions or Jenkins.
Next, SonarQube performs static code analysis to check code quality and security issues.
After that, a Docker image is built and pushed to the container registry.
Then, Trivy scans the Docker image to identify security vulnerabilities.
For monitoring, Prometheus collects metrics and Grafana provides visual dashboards.
Finally, the container image is deployed to the production environment.”

✔️ Summary:

“In my Netflix clone CI/CD project, code went from GitHub → Jenkins/GitHub Actions → SonarQube → Docker → Trivy → Monitoring → Deployment.”

🟢 Interview Question 34:

“If you use a public IP to access a server, how is it secure? Anyone can access it, right?”

Answer I Gave:

“Public IP is safe because access depends on security group rules + SSH keys, not on IP alone.”

🟢 Interview Question 35:

“Give one combined real scenario where monitoring and security tools work together.”

Answer I Gave:

“In my Netflix clone deployment, I used Prometheus and Grafana to monitor container performance like CPU, RAM, latency, and traffic load. SonarQube was used for code scanning, and Docker images were scanned with Trivy for vulnerabilities. If any issue occurs, Prometheus alerts trigger notifications. This setup helped maintain application health, performance, and security continuously all in one workflow.”

🟢 Interview Question 36:

“What is CI/CD, and how does Jenkins help? Also, what is the difference between Jenkins and GitHub Actions?”

Answer I Gave:

✔️ What is CI?

“CI (Continuous Integration) means automatically building and testing code whenever developers push changes.”

✔️ What is CD?

“CD (Continuous Deployment/Delivery) means automatically deploying applications to servers or containers after testing.”

✔️ How Jenkins helps?

“CI/CD automates build, test, and deployment. Jenkins is the tool to do it. GitHub Actions is a simpler, cloud-based CI/CD alternative.”

🟢 Interview Question 37:

“What is Git and what is GitHub?”

Answer I Gave:

✔️ Git:

“Git is a version control system used to track and manage source code changes.”

✔️ GitHub:

“GitHub is a cloud platform used to store Git repositories and collaborate with others online.”

🟢 Interview Question 38:

“Explain the Git workflow from git init to pull request.”

Answer I Gave:

✔️ 1️⃣ git init

Start a new local repository.

✔️ 2️⃣ git add .

Add files to staging.

✔️ 3️⃣ git commit -m “msg”

Save changes in local repo.

✔️ 4️⃣ git branch -M main

Set main branch name.

✔️ 5️⃣ git remote add origin <URL>

Connect local repo to GitHub.

✔️ 6️⃣ git push -u origin main

Upload code to GitHub.

✔️ 7️⃣ Create new branch

Work on new feature.

✔️ 8️⃣ git push (new branch)

Push branch to GitHub.

✔️ 9️⃣ Create Pull Request

Compare branch → merge → review.

Short path :-
“init → add → commit → push → branch → pull request → merge.”

Interview Question 39:

“What is Shell Scripting, and why is it used in DevOps?”

Answer I Gave:
“Shell scripting automates Linux tasks using command sequences. In DevOps, it is used for automation, deployments, monitoring, log management, and server tasks.”

Interview Question 40:

“What is Shebang (#!) in shell script?”

Answer I Gave:
“Shebang tells Linux which interpreter should run the script, such as ‘#!/bin/bash’.”

Interview Question 41:

“How do you make a script executable?”

Answer I Gave:
“By using: chmod +x script.sh”

Interview Question 42:

“How do you run a shell script?”

Answer I Gave:
“By executing: ./script.sh”

Interview Question 43:

“Real scenario: If a service stops working, how will you restart it using shell script?”

Answer I Gave:
“I will automate it using systemctl commands inside a shell script to restart the service automatically if it fails.”

Interview Question 44:

“How do you search for errors inside a log file using shell script?”

Answer I Gave:
“I will use grep inside a shell script to filter error lines e.g., grep ‘ERROR’ app.log.”

Interview Question 45:

“How do you schedule a shell script automatically?”

Answer I Gave:
“I will use cron jobs by running: crontab -e”

Interview Question 46:

“Give one real DevOps example of Shell Script.”

Answer I Gave:
“I used shell script to automate backup using tar, which removed manual effort.

Interview Question 47:

“Why is Python used in DevOps?”

Answer I Gave:
“Python is used for automation, cloud scripting, API integration, data parsing, monitoring, and CI/CD workflows.”

Interview Question 48:

“Do you know Python scripting?”

Answer I Gave:
“Yes, I know basic Python and can write automation scripts if needed.”

Interview Question 49:

“Give one real example of Python automation in DevOps.”

Answer I Gave:
“I used Python to collect CPU and memory usage metrics automatically and send alerts.”

Interview Question 50:

“What is pip?”

Answer I Gave:
“pip is a Python package installer used to install libraries and modules.”

Interview Question 51:

“How do you automate AWS services using Python?”

Answer I Gave:
“I will use Python with boto3 library to create, manage, and automate AWS cloud operations.”

Interview Question 52:

“Shell scripting vs Python scripting in DevOps?”

Answer I Gave:
“Shell scripting is best for OS tasks, while Python is best for cloud automation, APIs, and data handling.”

Interview Question 53:

“How will you scan logs and extract errors using Python?”

Answer I Gave:
“I will loop through log file lines in Python and print the lines containing the keyword ‘ERROR’.”

🟢 EXTRA ADVANCED DEVOPS INTERVIEW QUESTIONS

Q1: Hard link vs Soft link?

Hard link = real file copy; Soft link = shortcut link.

Q2: Find top 10 biggest files?

du -ah / | sort -rh | head -n 10

Q3: Check which port is in use?

lsof -i :80

Q4: Check live disk I/O?

iotop

Q5: Check failed login attempts?

cat /var/log/secure

Q6: SSH not working — how to access server?

Use AWS Console or Session Manager.

Q7: High server load — first check?

Check CPU with top.

Q8: Find zombie processes?

ps aux | grep Z

Q9: Check highest CPU usage process?

top -o %CPU

Q10: Trace network packets?

tcpdump

🟢 ADVANCED DOCKER / K8s

Q11: What is overlay network?

Allows containers to talk across multiple hosts.

Q12: How Kubernetes auto-scales?

Using Horizontal Pod Autoscaler.

Q13: Liveness vs Readiness probe?

Liveness = container running; Readiness = ready for traffic.

Q14: What if Kubernetes master fails?

Cluster control breaks — need HA setup.

Q15: Why etcd used?

Stores Kubernetes cluster data.

🟢 ADVANCED CI/CD

Q16: Canary deployment?

Release to small users first, then full rollout.

Q17: Handle secrets in pipeline?

Use Secrets Manager or Vault.

Q18: What is an artifact?

Build output like Docker image or JAR.

Q19: How to rollback deployment?

Deploy the previous version again.

Q20: Trigger pipeline automatically?

Using webhook.

🟢 AWS SCENARIO

Q21: Public IP changes after reboot fix?

Use Elastic IP.

Q22: How is S3 secure?

Bucket policy + IAM + encryption.

Q23: RDS high load fix?

Add read replicas.

Q24: AWS cost increasing check how?

Use Cost Explorer.

🟢 NETWORKING

Q25: Website slow first check?

Ping to test response.

🟢 HR STYLE DEVOPS

Q26: Deployment fails at night what will you do?

Check logs, rollback safely, fix later.

Q27: Why DevOps?

For fast delivery and less manual work.

Q28: Your weakness?

Pay extra attention to details.

Q29: Deadline is close what will you do?

Focus on priority tasks.

🟢 ADVANCED LINUX COMMANDS

Q30: htop use?

Live process view.

Q31: nmap use?

Network scan.

Q32: ncdu use?

Disk usage view.

Q33: strace use?

System call trace.

Q34: journalctl use?

System logs.

Q35: dig use?

DNS check.

Q36: rsync use?

File sync.

Q37: uptime use?

System load.

Q38: crontab -l use?

List cron jobs.

🟢 ADVANCED DEVOPS / CLOUD CORE

Q39: What is Kernel Panic?

Fatal OS crash.

Q40: What is inode?

File metadata record.

Q41: /etc/passwd vs /etc/shadow?

passwd = users; shadow = passwords.

Q42: What is SELinux?

Security policy layer.

Q43: What is race condition?

Two processes accessing data same time → conflict.

Q44: Ephemeral storage?

Temporary storage for pods.

Q45: Pod Disruption Budget?

Stops too many pods from going offline.

Q46: Container Registry?

Stores container images.

Q47: What is throttling?

Performance reduced due to limits.

Q48: Cache invalidation?

Remove stale cache data.

Q49: Sticky session LB?

Same server for same user.

Q50: Infrastructure drift?

Infra state mismatch with IaC code.

🟢 Conclusion ✨

Preparing for a DevOps interview can feel challenging, especially for freshers but the journey becomes easier when we learn from real experiences instead of memorizing theory. In this blog, I shared every question that was asked in my two DevOps interviews, along with simple and practical answers so that anyone who is preparing can understand what companies actually expect.

From AWS, Linux, Networking, Docker, Kubernetes, and CI/CD pipelines to scenario-based cloud solutions these real interview learnings will save you time, build confidence, and help you prepare smarter.

💡 The purpose of this blog was not just to share answers,
but to show the process, mindset, and direction that a DevOps candidate should follow.

If you are a fresher like me, remember one thing:

You do not need to know everything.
You just need to:
✔️ Understand concepts
✔️ Build projects
✔️ Stay consistent
✔️ Keep learning
✔️ Believe in yourself

DevOps is not just about tools
It is about problem-solving, automation, teamwork, and continuous improvement.

Thank you for reading this blog.
I hope it helps you prepare better, feel confident, and move one step closer to your DevOps career.

🚀 If I can do it, you can do it too.
All the best, future DevOps engineers! 🔥

👨‍💻 About the Author

“This series isn’t just about tools it’s about mastering real DevOps concepts and interview-ready knowledge.”

📬 Let's Stay Connected

• 📧 Email: gujjarapurv181@gmail.com

• 🐙 GitHub: github.com/ApurvGujjar07

• 💼 LinkedIn: linkedin.com/in/apurv-gujjar