Cloud Computing Fundamentals
DevOps and Infrastructure as Code
How development and operations merged into one continuous practice, what each stage of a CI/CD pipeline catches, and how describing infrastructure as code, instead of clicking through a console, keeps environments consistent and reproducible.
- Explain what DevOps changes about how development and operations teams work together
- Describe the stages of a CI/CD pipeline and what each stage catches before a change reaches production
- Explain how infrastructure as code replaces manual console changes with versioned, declarative configuration
- Identify configuration drift and why it happens when infrastructure is changed outside its code definition
- Compare a declarative infrastructure-as-code tool's plan-then-apply workflow to making the same change by hand
The last lesson left you with more moving pieces than one deployment can handle
The last lesson left you with a team running a growing number of independently deployable services, each shipping on its own schedule. Shipping one application by hand, tested manually and copied onto a server by whoever was on duty, was already slow and error-prone. Shipping 10 services that way is not just slower, it stops being something a person can reliably do at all. DevOps, and the practices built around it, exist to answer exactly that problem.
What DevOps actually changes
Before DevOps, development and operations were usually 2 separate teams: developers wrote code and handed it off, operations deployed and ran it, and each side blamed the other when a release broke something. DevOps, in AWS's own framing, is a combination of cultural philosophies, practices, and tools that increases an organization's ability to deliver applications and services at high velocity. In practice, that means the same team writes, tests, deploys, and operates its own services, which gives that team a direct incentive to make deployment itself fast and safe, instead of throwing a build over a wall and hoping.
Continuous integration, continuous delivery: what actually happens at each stage
| Stage | What happens | What it catches |
|---|---|---|
| Source | A developer commits code to a shared repository | Nothing yet, this just starts the pipeline |
| Build | The code compiles and packages into a deployable artifact | Syntax errors, missing dependencies |
| Test | An automated test suite runs against the build | Regressions in existing behavior |
| Staging | The build deploys to a pre-production environment | Integration and configuration problems |
| Production | The build deploys to live users | Nothing further, this is the release |
Follow one commit through it. A developer pushes a fix to the checkout service from the last lesson. Continuous integration builds a new container image and runs the test suite against it; if a test fails, the pipeline stops right there, and the change never reaches staging, let alone production. If every test passes, continuous delivery takes over, deploying the same build to staging automatically, and, once checks there pass, promoting that exact build to production. No stage is skipped, and no human copies a file by hand.
name: ci
on: [push]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: docker build -t checkout-service:${{ github.sha }} .
- run: docker run checkout-service:${{ github.sha }} npm test
Infrastructure as code: the same idea, aimed at infrastructure
CI/CD automates shipping application code. Infrastructure as code applies the same discipline to the servers, networks, and services that code runs on: provisioning and managing infrastructure using code instead of manual processes and console clicks. A storage bucket created by clicking through a console leaves no record of who created it, why, or how to recreate it. The same bucket declared in a file does.
resource "aws_s3_bucket" "uploads" {
bucket = "my-app-uploads"
}
Tools like Terraform work in 3 steps: write the configuration, plan (preview exactly what will be created, changed, or destroyed to match it), and apply (execute those changes in the right dependency order). That configuration is declarative: it describes the end state you want, not the individual commands to get there, and the tool works out the rest.
The misconception: "a quick manual fix in the console is fine"
It is tempting to think a fast fix in the console, bumping an overloaded instance's memory at 2 a.m. during an incident, is harmless as long as it solves the immediate problem. It is not: the infrastructure-as-code file still describes the old, smaller instance, so the code and the real infrastructure have quietly drifted apart. The next time someone applies that code, it can revert the emergency fix without anyone intending it to, or the team simply stops trusting the code to reflect what is actually running. Configuration drift is the name for that gap, and the fix is discipline, not cleverness: update the code to match the emergency change immediately, or revert the manual change and make the same fix through the code instead.
Exam cues: spotting the fit in a scenario
| The scenario says... | Points to |
|---|---|
| "Automated build, test, and deploy on every commit" | CI/CD pipeline |
| "Infrastructure defined in version-controlled files" | Infrastructure as code |
| "A manual change made outside the deployment pipeline" | Configuration drift risk |
| "Preview changes before they are applied" | Declarative infrastructure-as-code plan step |
Where this leaves you
DevOps, CI/CD, and infrastructure as code are what make everything the last 2 lessons covered sustainable at real scale: a serverless function or a container image is only as reliable as the pipeline that builds, tests, and ships it, and the infrastructure it runs on is only as consistent as the code that describes it. The next domain in this course turns to what keeps systems secure and available once they are running, the shared responsibility model, identity, encryption, and disaster recovery, practices that infrastructure as code makes far easier to enforce the same way across every environment a team has.