Cloud Engineer (DevOps)

Mission

Turn the architecture into running, reproducible, observable infrastructure. The Cloud Engineer (DevOps) designs, builds, deploys, and monitors the cloud-based system across AWS, Azure, and GCP, so that every increment the team produces can be shipped safely, repeatedly, and rolled back when needed - all expressed as code.

Responsibilities

• Design cloud topology, networking, identity, and landing zones against the Architect’s non-functional requirements (availability, security, cost).
• Build infrastructure as code - Terraform, CloudFormation, Bicep, Ansible, and Kubernetes/Helm YAML - kept in version control and peer-reviewed like application code.
• Deploy via CI/CD pipelines, progressive delivery (blue-green, canary), and GitOps; own the release mechanics and rollback paths.
• Monitor the system end to end - metrics, logs, traces, alerting, dashboards, and SLO/error-budget tracking.
• Enforce platform security & compliance: least-privilege IAM, secret management, network policy, policy-as-code, and CIS/benchmark hardening.
• Own cost visibility and FinOps - tagging, budgets, right-sizing, and surfacing spend to the Architect and stakeholders.
• Run incident response for infrastructure: on-call, runbooks, and post-incident reviews.

Inputs

Input	From
Architecture, NFRs & CI/CD design	Solutions Architect / Dev Lead
Deployable application increment	Developer (via PR / pipeline)
Non-functional & compliance targets	Stakeholders (PO), Architect
Release plan & schedule	Project Manager, Stakeholders (PO)
Quality & security gate results	Quality Engineer

Outputs

Output	To
Provisioned environments (dev/test/prod)	Whole team
IaC modules & pipelines (Terraform/Bicep/CFN/Ansible/Helm)	Developers, Architect
Deployed, released increment	Stakeholders (PO)
Monitoring dashboards, alerts & SLOs	Team, Stakeholders (PO)
Cost & reliability reports	Architect, PM, Stakeholders (PO)
Incident & post-mortem reports	Team, Stakeholders (PO)

AI tools & how we use them

Infrastructure is text - HCL, YAML, JSON, policy - which makes it a strong fit for AI assistance. The Cloud Engineer uses AI to draft, translate, review, and explain infra, while owning every line that touches security, money, or production state.

• Copilot / Cursor / Claude Code (IaC authoring): scaffold Terraform modules, Bicep templates, CloudFormation stacks, Ansible playbooks, and Kubernetes/Helm manifests from a described topology - then harden by hand. Prompt: “Write a Terraform module for an EKS cluster with managed node groups, IRSA, and a least-privilege IAM role; output variables and a README.”
• AI cloud advisors (AWS Well-Architected + Q, Azure Advisor/Copilot, GCP Gemini Cloud Assist): review live infrastructure for cost, security, reliability, and performance findings.
• Policy & security AI (Checkov, tfsec/Trivy, Snyk IaC with AI triage): scan IaC for misconfigurations pre-merge and explain/prioritize the findings.
• AIOps & observability copilots (Datadog Bits AI, Grafana/Dynatrace AI, PagerDuty AI): anomaly detection, alert noise reduction, and AI-summarized incident timelines.
• AI for translation & toil: convert a CloudFormation stack to Terraform, generate a Helm chart from raw manifests, draft runbooks and post-mortems from incident logs, and explain unfamiliar HCL/YAML during on-call.

Good practice

Treat AI-generated IaC as a pull request from a fast but unaudited junior - plan it, terraform plan / what-if it, scan it, and review every IAM statement, security group, and region/cost-bearing resource before it touches an account.

flowchart LR
    ARCH[Architecture + NFRs] --> AIIaC[AI drafts IaC<br/>Terraform/Bicep/CFN/Ansible/Helm]
    AIIaC --> REV[Cloud Engineer reviews & hardens]
    REV --> SCAN{Plan + policy/security scan clean?}
    SCAN -->|no| REV
    SCAN -->|yes| PIPE[CI/CD apply · GitOps]
    PIPE --> MON[Monitor · SLOs · alerts]
    MON -->|signals & cost| ARCH

Collaboration

The Cloud Engineer partners closely with the Architect/Dev Lead (whose design and CI/CD intent they implement and harden), receives deployable increments from Developers, consumes security and quality gate results from the Quality Engineer, and aligns releases with the Project Manager and Stakeholders (PO). During Build & Verify they are the bridge between a merged PR and a running, monitored production system.

Definition of Done for this role

• All infrastructure is expressed as version-controlled IaC - no manual console changes (“ClickOps”) in shared environments.
• IaC passes plan review, policy-as-code, and security scans before apply.
• Deployments are automated, repeatable, and reversible, with a tested rollback path.
• The system is observable: dashboards, alerts, and SLOs exist and are owned, not just provisioned.
• Cost and security posture are visible and within agreed budgets/baselines.

Pitfalls & anti-patterns

Watch out

• Applying AI-generated IaC unaudited. Generated Terraform/Bicep can carry over-permissive IAM, public buckets, wrong regions, or expensive instance types - review every security- or cost-bearing line and always read the plan / what-if.
• Hallucinated resources & arguments. Models invent provider resources, arguments, and ARNs that don’t exist or are deprecated; validate against current provider docs, not the model’s confidence.
• ClickOps drift. Fixing things by hand in the console breaks reproducibility and lets AI suggestions diverge from reality - change infrastructure through code only.
• Cloud-specific blind spots. A pattern that’s safe on AWS may be wrong on Azure or GCP (IAM models, networking, managed-service quirks differ); don’t let AI flatten the differences.
• Secrets in prompts or state. Never paste credentials, kubeconfigs, or tfstate into consumer AI tools; follow Integration & Governance.
• Alerting on everything. AI makes dashboards cheap to generate - but unscoped alerts create noise and on-call fatigue. Alert on symptoms and SLO burn, not every metric.