Cloud and DevOps Fundamentals: Git, Terraform, CI/CD, and SSH

Cloud engineering involves more than creating servers. It also requires understanding how infrastructure is managed, how software changes are delivered, how systems are monitored, and how servers are accessed securely.

Several tools and practices support this work, including Git, Infrastructure as Code (IaC), Continuous Integration and Continuous Delivery (CI/CD), containers, observability, Terraform, and SSH.

This article introduces these concepts and explains how they fit into a cloud engineering workflow.

1. Version Control with Git

Git is a distributed version control system that tracks changes to files over time. It allows developers to review previous changes, experiment with new features, and collaborate without losing the history of a project.

Git is widely used in software development and infrastructure projects.

Core Git concepts

Working directory

The working directory is where you view and modify project files.

For example, when you edit a Bash script or Terraform configuration, you're changing files in your working directory.

Staging area

The staging area allows you to select the changes you want to include in your next commit.

git add main.tf

This stages the changes to main.tf.

Local repository

The local repository stores the project's Git history, including commits and branch information.

To record staged changes:

git commit -m "Add Terraform configuration"

Remote repository

A remote repository is a version of the repository hosted elsewhere, such as on GitHub. It allows you to share your work and collaborate with other people.

Common commands include:

git push
git pull

git push sends local commits to a remote repository, while git pull fetches and integrates changes from a remote repository.

Branches

Branches allow you to develop features or make changes independently of another branch.

For example:

git switch -c add-monitoring

This creates and switches to a new branch named add-monitoring.

Pull requests

A pull request is a proposal to merge changes from one branch into another. It gives team members an opportunity to review and discuss the changes before they are integrated.

Merging

Merging integrates changes from one branch into another. For example, a feature branch may be merged into the main branch after review.

Why Git matters in cloud engineering

Infrastructure configurations are files too. By storing Terraform configurations and scripts in Git, you can track infrastructure changes, review proposed modifications, and recover earlier versions of your configuration.

Version control makes infrastructure work more transparent and repeatable.

2. Infrastructure as Code (IaC)

Infrastructure as Code is the practice of defining and managing infrastructure through machine-readable configuration files rather than relying entirely on manual setup.

Instead of repeatedly clicking through a cloud provider's console to create servers and networks, you describe the desired infrastructure in configuration files.

These files can be version-controlled, reviewed, reused, and applied consistently.

For example, a Terraform configuration can describe an AWS EC2 instance, including its instance type and other settings.

Why IaC is useful

IaC can help teams:

• Reproduce infrastructure environments.
• Reduce repetitive manual configuration.
• Review infrastructure changes before applying them.
• Track configuration history in Git.
• Standardize infrastructure across development and production environments.

IaC does not automatically guarantee that every deployment will be identical. Results also depend on the configuration, provider behaviour, external dependencies, and the state of the environment.

The main advantage is that infrastructure becomes defined and managed through explicit, reviewable configuration.

3. Continuous Integration and Continuous Delivery/Deployment (CI/CD)

CI/CD describes practices and automation used to integrate, test, and deliver software changes.

The abbreviation has two main components.

Continuous Integration (CI)

Continuous Integration involves regularly integrating code changes into a shared codebase.

Automated checks may run when changes are pushed or a pull request is opened. These checks can include:

• Running tests.
• Checking code quality.
• Validating configuration files.
• Building an application.

The goal is to detect problems early, before changes progress further through the delivery process.

Continuous Delivery and Continuous Deployment

Continuous Delivery automates the process of preparing software for release. A production deployment may still require human approval.

Continuous Deployment goes further: changes that pass the required checks can be released automatically to production.

A simplified pipeline might look like this:

1. A developer pushes a change to Git.
2. An automated pipeline runs tests.
3. The application is built and validated.
4. The deployment process prepares or releases the application.
5. Monitoring helps identify problems after deployment.

CI/CD reduces repetitive work and helps teams deliver changes more consistently. However, automation is only as reliable as the tests, deployment procedures, and safeguards behind it.

4. Observability: Understanding What's Happening Inside a System

Observability is the ability to understand a system's internal state by examining the information it produces.

When an application becomes slow or fails, engineers need evidence to investigate the cause rather than relying on guesses.

Three commonly discussed observability signals are logs, metrics, and traces.

Logs

Logs are records of events produced by an application or system.

For example:

2026-10-09 10:32:00 ERROR Database connection failed

A log entry may help an engineer identify what happened and when it occurred.

Metrics

Metrics are numerical measurements collected over time.

Examples include:

• CPU utilization.
• Memory usage.
• Request rate.
• Error rate.
• Request latency.

Metrics can help engineers identify trends, unusual behaviour, and performance problems.

For example, a steady increase in memory usage may indicate a resource leak or growing workload.

Traces

Distributed traces follow a request as it passes through multiple components of an application.

Imagine an application request moving through an API, a payment service, and a database. A trace can help show which part of that journey contributed most to the delay.

Monitoring and observability

Monitoring commonly involves tracking predefined indicators and alerting when they cross certain thresholds.

Observability helps engineers investigate less predictable problems by examining system telemetry and relationships between events.

They complement each other: monitoring can tell you that something is wrong, while observability can help you investigate why.

Collecting data is only one part of the process. Teams also need suitable tools, useful dashboards, appropriate alerts, and a method for investigating what the data reveals.

5. Containers and Kubernetes

Applications often depend on specific libraries, configuration files, and runtime components. Differences between environments can cause an application to work on one machine but fail on another.

Containers help address this problem by packaging an application with its required dependencies and isolating its processes from the surrounding system.

What is a container?

A container is an isolated environment in which an application runs.

Containers commonly use images that package the application and its required components. The same image can be used across different environments, provided the necessary runtime and platform requirements are met.

Containers are generally lighter than traditional virtual machines because they share the host operating system's kernel rather than each requiring a separate guest operating system.

However, a container does not automatically guarantee identical behaviour everywhere. Environment variables, permissions, networking, storage, and other external dependencies can still affect how it runs.

What is Kubernetes?

Kubernetes is a container orchestration platform.

When an application runs across many containers and machines, managing each container manually becomes difficult. Kubernetes helps automate tasks such as:

• Scheduling containers across available machines.
• Restarting containers when they fail.
• Scaling workloads.
• Managing service discovery and networking.
• Maintaining the desired number of application replicas.

For example, you might configure a workload to run three replicas of an application. Kubernetes works to maintain that desired state.

The distinction: Containers provide an environment for running applications; Kubernetes helps manage containerized workloads at scale.

Kubernetes is a useful technology to understand, but you don't need to master it before learning the fundamentals of Linux, networking, and cloud infrastructure.

6. Terraform: Managing Infrastructure with Code

Terraform is an Infrastructure as Code tool that allows you to define infrastructure using configuration files.

Instead of manually creating resources in a cloud console, you describe what you want Terraform to manage.

For example, you can define an AWS EC2 instance in a Terraform configuration.

The Terraform workflow

A typical workflow has three important commands.

1. Initialize

terraform init

This initializes a Terraform working directory. Terraform downloads the required providers and prepares the directory for further operations.

Run it when setting up a new configuration or when initializing a project cloned from version control.

2. Plan

terraform plan

Terraform compares the desired configuration with its understanding of the existing infrastructure and produces a proposed execution plan.

Reviewing the plan helps you understand which resources Terraform intends to create, change, or destroy.

3. Apply

terraform apply

Terraform executes the proposed changes, subject to its planning and approval workflow.

For example, it may create an EC2 instance in AWS based on your configuration.

Always review the proposed changes before approving an apply operation, particularly when working with existing infrastructure.

Understanding a Terraform provider configuration

A Terraform configuration may contain the following block:

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

  required_version = ">= 1.2"
}

Let's break it down.

• terraform is a Terraform configuration block.
• required_providers declares the providers the configuration needs.
• aws is the local name assigned to the provider in this configuration.
• source = "hashicorp/aws" identifies the AWS provider in the Terraform Registry.
• version = "~> 5.92" specifies a provider version constraint.
• required_version = ">= 1.2" specifies the minimum Terraform CLI version permitted by the configuration.

The version constraints above are examples from the configuration in my notes, not recommendations to use those versions in every new project. Check the current Terraform documentation and provider registry when starting a new configuration.

The ~> 5.92 constraint allows compatible releases within the relevant version range; it does not mean Terraform will always install exactly version 5.92.

Why Terraform matters

Terraform makes it possible to define infrastructure in a repeatable and reviewable way.

Combined with Git, it also provides a history of configuration changes that can help engineers understand how infrastructure has evolved.

Before using Terraform to manage real resources, it's important to understand its state file, resource dependencies, provider configuration, and the costs associated with creating cloud resources.

7. SSH: Securely Accessing Remote Systems

SSH stands for Secure Shell. It is a protocol for securely connecting to and managing remote computers over a network.

Cloud engineers commonly use SSH to access Linux servers for administration, troubleshooting, and maintenance.

SSH typically uses TCP port 22 by default, although administrators can configure a different port.

What SSH provides

SSH supports several important capabilities.

Remote administration

An engineer can connect to a remote Linux server and execute commands.

For example:

ssh username@server-ip

Here, username is the account on the remote machine, and server-ip is the server's IP address or resolvable hostname.

Secure file transfer

Tools such as scp and sftp use SSH-related functionality to transfer files securely.

Authentication

SSH supports several authentication methods, including passwords and public-key authentication.

With public-key authentication, the user keeps a private key and configures the corresponding public key on the remote system. The server can verify that the client possesses the matching private key without requiring the private key itself to be sent to the server.

SSH also negotiates encryption keys to protect the session's communications. Public-key cryptography is not simply used to encrypt every piece of data transmitted during the session.

SSH tunnelling and port forwarding

SSH port forwarding allows traffic to travel through an SSH connection to reach another address and port.

For example, an engineer may need to access a service running on a remote server without exposing that service directly to the public internet.

A local forwarding example is:

ssh -L 8080:localhost:80 username@server-ip

This forwards connections to port 8080 on the local machine through the SSH connection to port 80 on the remote server's localhost.

The exact destination depends on the forwarding configuration. In this example, localhost:80 is interpreted from the remote server's perspective.

SSH tunnelling can help provide controlled access to services, but it does not automatically bypass every firewall or security restriction. The SSH server, network rules, authentication, and destination service must permit the connection.

Why SSH matters in cloud engineering

SSH is useful for:

• Administering remote Linux servers.
• Investigating application or system problems.
• Transferring files securely.
• Accessing services that should not be publicly exposed.
• Establishing encrypted tunnels to permitted network destinations.

For cloud environments, access should be restricted to authorized users and trusted networks wherever practical. Private keys should be protected, and SSH access should follow the security controls of the environment.

8. Essential Linux Networking Commands

Cloud engineers frequently use Linux commands to inspect interfaces, addresses, and routing information.

Two particularly useful commands are ip addr and ip route.

ip addr

ip addr

This displays information about network interfaces and their IP addresses.

It can help answer questions such as:

• Which network interfaces are available?
• What IP addresses are assigned?
• Is an interface up or down?

ip route

ip route

This displays the IPv4 routing table.

It helps you understand where the system sends traffic and which gateway it may use to reach destinations outside its local network.

For example, an output line such as:

default via 192.168.1.1 dev eth0

indicates that the default route uses 192.168.1.1 as its gateway through the eth0 interface.

The actual interface name and gateway will depend on the system's network configuration.

What about ifconfig?

ifconfig is an older utility used to inspect and configure network interfaces. On many modern Linux distributions, the ip command from the iproute2 package is preferred.

For example:

ip addr
ip route

These commands provide much of the interface and routing information beginners commonly seek with ifconfig.

What about iwconfig?

iwconfig is an older utility for inspecting and configuring wireless network interfaces.

Depending on the Linux distribution, it may not be installed by default. Modern Linux systems commonly use iw for wireless-specific operations.

The commands serve different purposes:

Command	Primary purpose
ip addr	Inspect network interfaces and IP addresses
ip route	Inspect routing information
iwconfig	Inspect or configure wireless interface settings using the older wireless tools
iw	Inspect or configure wireless devices using the modern wireless utility

A virtual machine may not expose a physical wireless interface to its guest operating system. For example, an Ubuntu VM using a virtual Ethernet adapter may not have access to the host Mac's Wi-Fi interface directly. In that case, iw or iwconfig may not show a wireless interface, even when the host computer is connected to Wi-Fi.

---

Conclusion

Cloud and DevOps engineering bring together tools and practices that make infrastructure easier to manage, software changes easier to deliver, and system behaviour easier to investigate.

The concepts covered here play different roles:

• Git tracks changes to code and configuration.
• Infrastructure as Code defines infrastructure in reusable files.
• CI/CD automates testing and software delivery.
• Observability helps engineers understand system behaviour.
• Containers package applications and their dependencies.
• Kubernetes orchestrates containerized workloads.
• Terraform provisions and manages infrastructure.
• SSH enables secure remote access and tunnelling.
• Linux networking commands help troubleshoot interfaces, addresses, and routes.

These technologies become more useful when understood as parts of a workflow rather than as isolated tools.

For someone entering cloud engineering, the practical next step is to build small projects that combine these fundamentals—for example, managing a cloud server with Terraform, tracking the configuration in Git, and connecting to the server securely with SSH.

References

• Git Documentation
• Terraform Documentation
• AWS Provider Documentation
• GitHub Actions Documentation
• Kubernetes Documentation
• OpenTelemetry Documentation
• OpenSSH Manual Pages
• Linux ip command manual