Automating Cloud Resources
# Automating Cloud Resources
Clicking through a console works, until it doesn't. This module covers how DevOps tools turn cloud deployment into something you can write, version, and repeat exactly — instead of remembering.
What you'll cover
Click an objective as you work through it — this list only lives in your browser tab.
- Explore automation and orchestration to manage code-based deployments.
- Use DevOps tools to provide Continuous Integration / Continuous Deployment management.
- Deploy and configure cloud resources using code.
Given a scenario, use code to deploy and configure cloud resources. Expect scenario questions that ask you to recognize when Infrastructure as Code or Configuration as Code is the right tool for a described deployment problem.
Manual vs. code-based management
Older network management connected to devices one at a time. If three routers needed the same update, an administrator logged into each router and made the change by hand — three times, hoping for zero typos.
A typical CI/CD pipeline
Continuous Integration and Continuous Deployment chain automated steps together so a code change flows to production the same way, every time. Hover a stage to see what it's responsible for.
Infrastructure as Code
IaC administrators define the desired configuration state in code, then apply that code to servers, routers, firewalls, VMs, and containers. Manual changes are never made directly on a device — every change to the desired state goes through code first.
Imperative vs. declarative
There are two ways to manage IaC. Both end up changing the same device — they just describe the change differently.
IaC benefits
Common IaC tools
Configuration as Code
Where IaC provisions the virtualized hardware — servers, routers, firewalls — Configuration as Code focuses on what runs on top of it. Say you're deploying a cluster of web servers for a new site: each one needs the same HTML, CSS, and JavaScript files, and each has to connect to the same inventory database. CaC keeps those files in a repository so every server ends up configured identically. The same idea applies to a Kubernetes cluster — CaC helps you maintain and update it, so only tested, approved configuration ever reaches it.
IaC and CaC, side by side
Ansible, Terraform, and Chef are common tools here — many deployments combine IaC and CaC functions in the same pipeline.
Benefits: repeatability & drift
Repeatability
Define a configuration once in code, and reapply it as often as needed to generate identical deployments — quickly reproducing a site during disaster recovery, or scaling it up for a high-demand season.
Configuration drift
Even with automation, devices can quietly deviate from their defined baseline. That deviation is configuration drift — click a category to see where it shows up.
- Operating system version
- Operating system patch level
- Application version
- Application patch level
- Device driver version
- The developer system changes unexpectedly
- The staging environment changes unexpectedly
- The production environment changes unexpectedly
- Unplanned configuration changes
- Undocumented configuration changes
- Hotfixes for security, drivers, or patching
- Administrators failing to document changes
Drift-detection tools scan managed and unmanaged systems to flag differences — sometimes with remediation advice. Terraform includes built-in drift detection; AWS Config evaluates cloud resources for the same purpose.
Versioning practices
Version tracking should be built into the development process from the start, and it comes down to three habits: stay consistent with one versioning method, advertise what each release changes, and make sure people know how to read your version format.
Semantic versioning
The most common format tracks three numbers — major, minor, and patch. Click a number to see what it means, using the Linux kernel on a cloud VM as the example.
Keeping software versions current matters for security as much as features — the latest version is usually the one with the most current security fixes. Versioning practices here means tracking release numbers; it's a different topic from version control systems like Git.
Testing procedures
Testing runs at every CI/CD stage so failures surface as early as possible — the sooner a developer sees a problem, the cheaper it is to fix.
Documentation practices
Documentation helps everyone touching the application understand how it's built, managed, and used — and in CI/CD environments, where changes ship constantly, that matters more, not less. Left unenforced, it tends to fall away for a predictable set of reasons:
Perceived lack of time to write it down.
Lack of understanding of the software being documented.
No incentive or process that requires it.
Poor documentation tools that make writing it a chore.
Challenges writing clearly, especially across languages.
Documentation works best when it's a requirement for software acceptance — built into the CI/CD process, not bolted on afterward.
Code formats: YAML & JSON
IaC and DevOps tools lean on two file structures to move configuration data around. Both are plain text and both are simple to read once you know the shape.
Most cloud tasks can be done manually. That doesn't mean they should be.
Manual work is slow, repetitive, and one missed step from an outage — it does not scale, and it does not stay cost-effective as your environment grows.
Automating with tools and files is faster and far less error-prone. This module looks at automated and orchestrated deployments, and the DevOps tools that make them possible.