Cloud+: Operations &
DevOps Fundamentals

1. Cloud Resource Lifecycle Management

Every cloud resource progresses through a lifecycle: provision → configure → scale → update → decommission. Understanding each phase — and the right tools for each — is an Operations core competency.

Provisioning

Create resources (VMs, databases, networks) via IaC (Terraform, CloudFormation), console, CLI, or API. IaC is the preferred cloud-native approach for repeatability and auditability.

Configuration

Set up OS, install software, configure settings after provisioning. Key tools:

• cloud-init — runs scripts at first boot (cloud-native, no agent needed)
• Ansible — agentless, SSH-based playbooks pushed to servers
• SSM Run Command — AWS Systems Manager, run commands without SSH

Scaling

Updating

OS patches and application updates. Use rolling updates (gradual replacement) or blue/green deployments to minimize downtime.

Decommissioning

Safe removal sequence: backup data → remove DNS records → check dependencies → revoke IAM access → terminate resource. Skipping steps causes data loss or broken services.

Resource Tagging Lifecycle

2. Backup and Recovery

RPO vs RTO

Backup Types

• Full — all data, longest to create, most storage, fastest restore
• Incremental — changes since last backup — fastest, least storage, complex restore (need full + all incrementals)
• Differential — changes since last FULL — middle ground, moderate storage, faster restore than incremental

Cloud Snapshots

Point-in-time copy of block storage (EBS snapshot, Azure Managed Disk snapshot). Stored in object storage, encrypted, supports cross-region copy for DR protection against regional outages.

DR Strategies — Cost vs RTO/RPO

• Backup & Restore — cheapest, highest RTO (hours) — restore from backup when disaster strikes. Minimal ongoing cost.
• Pilot Light — minimal critical components always running — scale up on disaster. RTO: tens of minutes.
• Warm Standby — scaled-down full environment always running — scale up on disaster. RTO: minutes.
• Multi-Site Active/Active — full capacity in multiple regions simultaneously — lowest RTO/RPO, highest cost.

3. Observability: Monitoring, Logging, Alerting

The Three Pillars of Observability

Alerting & Dashboards

• Alerting: trigger notifications when metrics exceed thresholds — CloudWatch Alarms, Azure Monitor Alerts
• Dashboards: CloudWatch Dashboards, Azure Monitor Workbooks, Grafana (multi-source)

SLI / SLO / SLA

• SLI — Service Level Indicator: actual measured metric (e.g., 99.5% availability measured this month)
• SLO — Service Level Objective: internal target (e.g., maintain 99.9% availability)
• SLA — Service Level Agreement: contractual commitment to customer with credits if breached

Error Budget

Allowed downtime before SLO is violated. Formula: (1 - SLO%) × time period.

Example: 99.9% SLO monthly = 0.1% × 43,200 min ≈ 43.2 minutes per month. When the error budget is consumed, freeze feature releases and focus on reliability.

4. Auto Scaling and Elasticity

Scaling Policy Types

• Target Tracking — maintain metric at target value (e.g., keep CPU at 70%). Simplest, recommended default. AWS auto-creates alarms.
• Step Scaling — scale by defined increments based on how much the alarm is breached. More granular control.
• Scheduled Scaling — known load patterns (scale up at 9 AM Mon–Fri, scale down at 7 PM). Good for predictable traffic.
• Predictive Scaling — AWS ML-based, proactively scales ahead of anticipated load using historical patterns.

Cooldown Period

Scale-In Protection

Prevent specific instances from being terminated during scale-in. Use when an instance is processing a long-running job that must complete (e.g., video encoding, batch processing).

Load Balancer Health Checks

Auto Scaling uses LB health checks to detect unhealthy instances. When an instance fails health checks, Auto Scaling terminates it and launches a replacement — automatic self-healing.

5. Source Control and Git

Git is a distributed version control system — every developer has a complete copy of the repository history. Foundational to all DevOps workflows.

Core Workflow

Branching Strategies

Key Concepts

• Pull Request / Merge Request: code review gate before merging — enforces quality and compliance
• Git Tags: mark release points (v1.2.3) using semantic versioning (MAJOR.MINOR.PATCH)
• .gitignore: exclude credentials, local config, build artifacts, large binaries from commits

GitOps

Use git as single source of truth for both application code and infrastructure state. All changes via git commit + PR — never direct kubectl apply or console changes. Tools: ArgoCD Flux continuously sync git repo to Kubernetes cluster. Drift detection alerts when cluster diverges from git.

6. CI/CD Pipelines

CI vs CD (Delivery) vs CD (Deployment)

• CI — Continuous Integration — auto build + test on every commit. Detect issues early. Fast feedback loop.
• CD — Continuous Delivery — auto deploy to staging/pre-prod. Requires manual approval gate for production.
• CD — Continuous Deployment — auto deploy to production on every passing build. No manual gates. Requires high test confidence.

Pipeline Stages

Source → Build → Unit Test → Code Quality Scan → Security Scan → Artifact Publish → Deploy Staging → Integration Tests → [Approval] → Deploy Production

Pipeline Tools Comparison

• Jenkins — self-hosted, most flexible, largest plugin ecosystem (1800+), Jenkinsfile (Groovy DSL)
• GitHub Actions — native to GitHub, YAML workflows, no separate server needed
• GitLab CI/CD — integrated with GitLab, .gitlab-ci.yml, built-in container registry
• AWS CodePipeline — AWS-native, integrates with CodeBuild/CodeDeploy, no server to manage
• Azure DevOps — Microsoft's end-to-end platform, YAML or visual pipeline editor

Artifact Repository

Store built artifacts between pipeline stages: Docker images in AWS ECR / Azure ACR, JARs/packages in JFrog Artifactory / Nexus. Enables repeatable deploys — deploy the same exact artifact to staging and prod.

7. DevOps Tools: Kubernetes, Ansible, Jenkins

Kubernetes (K8s)

Container orchestration platform — manages deployment, scaling, self-healing, and networking of containerized applications.

• kubectl — CLI to interact with K8s API. Key commands: get pods, apply -f, describe, logs, exec
• kubectl apply -f — declarative config: idempotent, re-applying same manifest is safe
• Helm — Kubernetes package manager. Charts = templated K8s YAML. helm install, helm upgrade, helm rollback
• Rolling update (default): gradually replace old pods. Blue/Green: switch all traffic at once. Canary: route percentage of traffic.

Ansible

Agentless configuration management — configure existing servers, deploy applications, orchestrate workflows via SSH. YAML-based playbooks, idempotent runs.

• ansible-playbook — run playbooks against inventory file of target hosts
• Ansible Tower / AWX — enterprise web UI, scheduling, RBAC, audit logging

Jenkins

Open-source CI/CD server with 1800+ plugins. Pipeline defined in Jenkinsfile committed to the repo (pipeline as code).

• Declarative Pipeline: structured syntax with pipeline{}, stages{}, steps{} — recommended
• Scripted Pipeline: Groovy-based, more flexible but more complex
• Webhook triggers: GitHub sends HTTP POST to Jenkins on push → build starts immediately (no polling)

Ansible vs Terraform

8. Event-Driven Architectures and System Integration

Event-driven design decouples components so they communicate asynchronously via events — enabling independent scaling and resilience to partial failures.

Messaging Patterns

• Message Queue (SQS, Service Bus) — one-to-one delivery, each message processed once, durable. Handles backpressure — if consumer is slow, messages wait in queue safely.
• Pub/Sub (SNS, Event Grid) — publisher sends to topic, multiple subscribers receive independently. One-to-many broadcast (e.g., order placed → notify inventory + email + analytics simultaneously).
• Event Streaming (Kafka, Kinesis, Event Hubs) — ordered, replayable event log. Consumers maintain their own position. Use for event sourcing, real-time analytics, audit trails.

Integration Components

• Serverless integration: AWS Lambda triggered by SQS/SNS/EventBridge — no servers, pay per invocation
• API Gateway: managed endpoint handling auth, rate limiting, routing — sits in front of backend services
• Webhook: HTTP callback — source sends POST to URL when event occurs (e.g., GitHub push → Jenkins build)
• Service Mesh (Istio, Linkerd): infrastructure layer for microservices — mTLS between services, traffic management, observability without code changes