5.3.2. Cloud Platforms and Hybrid Infrastructure
Cloud Concepts for XK0-006:
The exam tests cloud-aware Linux administration, not deep AWS/Azure/GCP expertise. Key concepts:
| Concept | Description |
|---|---|
| IaaS | Infrastructure as a Service — VMs, storage, networking (AWS EC2, Azure VM); you still manage the OS, patches, runtime, and application |
| PaaS | Platform as a Service — managed runtime (AWS Elastic Beanstalk); the provider manages the OS and middleware, you deploy code |
| CaaS / serverless containers | You supply a container image; the provider runs it with no VMs, OS patching, or cluster to manage (AWS Fargate, Google Cloud Run) |
| SaaS | Software as a Service — complete application (Gmail, Salesforce) |
| Cloud-init | Industry-standard initialization system for cloud VMs; runs scripts on first boot |
| User data | Script provided at VM launch time; executed by cloud-init on first boot |
| Instance metadata | Per-VM metadata accessible from within the VM (http://169.254.169.254) |
# cloud-init — configures a new VM on first boot
# /etc/cloud/cloud.cfg — configuration
# /var/log/cloud-init.log — initialization log
# Status check
cloud-init status # show status of initialization
# Instance metadata (AWS example)
curl http://169.254.169.254/latest/meta-data/instance-id
curl http://169.254.169.254/latest/meta-data/public-ipv4
Terraform — Infrastructure Provisioning:
# main.tf — declarative infrastructure
provider "aws" {
region = "us-east-1"
}
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t3.micro"
key_name = "my-key"
tags = {
Name = "webserver"
Env = "production"
}
}
terraform init # Initialize providers
terraform plan # Preview changes
terraform apply # Apply changes
terraform destroy # Tear down infrastructure
terraform plan first refreshes its state by querying the provider APIs, so a change made by hand in the cloud console shows up as drift: the plan proposes changes that bring the real resource back to what the .tf files declare. Nothing is imported or reverted automatically — you review and apply, or update the code to adopt the change. OpenTofu is the open-source fork of Terraform with the same workflow under the tofu command (tofu init, tofu plan, tofu apply).
Terraform vs. Ansible:
| Tool | Purpose | Model |
|---|---|---|
| Terraform | Provision infrastructure (VMs, networks, DNS) | Declarative, stateful |
| Ansible | Configure software on existing systems | Procedural/declarative |
| Together | Terraform provisions, Ansible configures | Common production pattern |
⚠️ Exam Trap: Cloud-init user data scripts run once at first boot, not on every reboot. If you need to reconfigure a VM, you cannot rely on user data — you need Ansible, Puppet, or manual intervention. Also, the metadata endpoint 169.254.169.254 is a link-local address reachable only from within the instance — it's not a general network address.
Reflection Question: You provision a cloud VM using Terraform and configure it with an Ansible playbook. Two weeks later, a developer manually edits /etc/nginx/nginx.conf on the VM. How does each tool handle this configuration drift, and what would you run to restore the desired state?
