Automating Cloud Resources
Module 8
Automating Cloud Resources
Manual configuration doesn't scale. This module is about making the code the source of truth — IaC and CaC, CI/CD pipelines, Git, Bash, and the DevOps tools that stitch it together.
Infrastructure & Configuration as Code
If a change isn't in code, it isn't real — manual edits on individual devices cause the drift IaC exists to prevent.
IaC vs. CaC
| Infrastructure as Code | Configuration as Code | |
|---|---|---|
| Focus | Provisioning virtualized hardware — servers, routers, firewalls | Application-level configuration |
| Example tools | Ansible, Puppet, Chef, PowerShell | Ansible, Terraform, Chef |
Repeatability & drift detection
- Repeatability — identical deployments, quick recovery, fewer human errors, easier scaling
- Drift — OS/app versions, patch levels, driver versions, or undocumented hotfixes pulling a device away from its defined baseline
Terraform includes built-in drift detection; AWS Config evaluates cloud resources to identify and manage changes against baseline.
CI/CD Pipelines
Small, frequent, automated integrations replace the old model of massive, infrequent releases.
A developer's change is integrated into the code base, automatically built, tested, and delivered to a repository — ready to deploy. The process repeats for every new component. Delivery means the build lands in a repository; deployment means it's actually installed for consumers.
Testing at every stage
| Test type | Checks |
|---|---|
| Unit | Independent pieces of the application in isolation |
| Integration | How independent pieces work together |
| System | The entire application deployment |
| Acceptance | Alignment with business requirements |
Versioning — semantic format
Major.Minor.Patch — e.g. Linux kernel 6.10.9. Pick one convention, advertise what changed, and explain the format to your users. This is distinct from Git-style version control, covered later in this module.
Automation vs. Orchestration
One task running itself, versus a whole workflow of tasks running itself.
| Automation | Orchestration | |
|---|---|---|
| Scope | A single task | A series of automated tasks as one workflow |
| Trigger | Launched separately, per step | Launched once — each step follows automatically |
| Example | Auto-install an OS on an instance | Create instance → install OS → configure → install web service → copy files → start service |
Good automation candidates
- Routine, repetitive operations (log archiving, account management)
- Deployments and updates
- Scaling test/QA environments
- Scheduled shutdowns and restarts
- Internal APIs feeding the automation pipeline
Troubleshooting automation failures
- Version mismatch — managed node OS/app version, or the config tool itself, is wrong
- Deprecated features — configuration references an OS or app feature that no longer exists
- Sequencing — check logs to find the last step that completed successfully
- Authentication — SSH key identities or keys no longer match between systems
Deployment artifacts
- VM images · container images · executable files · application binaries · libraries · tar/zip bundles · flat files
DevOps Tools
Deployment, orchestration, and observability tools — each doing one job well.
| Tool | Role |
|---|---|
| Ansible | Agentless, declarative config management via YAML playbooks over SSH |
| Docker | Container engine; builds images from a Dockerfile |
| Kubernetes (K8s) | Container orchestration — scaling, load balancing, storage, secrets, grouped into pods |
| ELK Stack | Elasticsearch (search/store) + Logstash (ingest) + Kibana (visualize) |
| Grafana | Dashboard visualization across many data sources |
| Jenkins | CI/CD pipeline tool — build, test, deploy stages via plugins |
| Terraform | Declarative IaC using HCL; drift detection, execution plans |
Ansible ad hoc command vs. playbook
ansible server42 -a "/sbin/reboot" runs once, immediately. A playbook (YAML) defines tasks grouped into plays for repeatable, larger-scale automation — that's where Ansible's real strength is.ELK data path
Source Control with Git
Four zones, six commands you'll actually use daily.
Common git subcommands
| Command | Does |
|---|---|
init | Create a new repository |
clone | Copy an existing remote repository locally |
add | Stage files to be tracked |
commit | Snapshot staged changes into the local repo |
push | Upload local commits to the remote repo |
pull | Fetch and merge remote changes locally |
branch | Create/manage pointers to snapshots |
merge | Integrate one branch's changes into another |
rebase | Rewrite history for a linear, cleaner log |
checkout | Switch the working directory to a branch |
Security practices for automation code
- Never hardcode passwords in scripts or playbooks
- Use SSH key-based authentication so automation isn't interrupted by password prompts
- Store secrets in a password vault (e.g., Ansible Vault), not in the repo
- Give services their own individual accounts with least privilege
- Default deny — no access unless explicitly granted
Bash Scripting
Consistency, speed, and accuracy — the same commands, run the same way, every single time.
# comments start with #, run before the script's real work num_file=432 total_files=512 echo "There are $((total_files - num_file)) files remaining."
Operators
| Bash test | Meaning | Arithmetic/logic | Meaning |
|---|---|---|---|
-eq | Equal to | == | Equal to |
-ne | Not equal to | != | Not equal to |
-gt | Greater than | && | Logical AND |
-lt | Less than | ! | Logical negation |
test command returns 0 for true and 1 for false — the opposite of what many people instinctively expect from "0 = off."Integration of Systems
Decoupled services talking to each other over HTTP, triggered by events rather than by polling.
Event-driven example: an order
- Item added to cart → order placed → billing charges the card → shipping ships the order → purchaser notified
Each step is a discrete event triggering the next — the architecture stays agile, scales independently, and keeps microservices decoupled from each other.
| API / protocol | Notable trait |
|---|---|
| REST | Architectural style; scalable, language- and platform-independent |
| SOAP | XML-based, strong platform independence (Windows/macOS/Linux) |
| RPC | Calls code execution in another address space |
| WebSockets | Two-way, persistent client-server communication |
| GraphQL | Client requests exactly the fields it needs — nothing extra |
Exam Keyword Flashcards
Tap a card to flip it.
Quick Self-Check
Four questions pulled straight from the module.