Cloud Automation Engineer II

Cloud Automation Engineer II practitioners own the design and direction of automation systems, not just their implementation. The distinction matters because automation systems, like software systems generally, are easy to build quickly and expensive to maintain if built carelessly. An Engineer II thinks about module interfaces that will still make sense when 50 teams are using them and they haven't been touched in a year. They think about testing strategies that catch the class of errors that break things in production without making tests so slow that engineers skip them. They think about the developer experience of the platform — not just whether it works, but whether teams actually want to use it.

The IaC module library is often the most important product an Engineer II owns. Well-designed modules encode organizational standards in a way that makes compliance the path of least resistance: the default configuration is secure and cost-appropriate, the interface exposes the options teams legitimately need, and the documentation is clear enough that consumers can use it without a support ticket. Poorly designed modules create a proliferation of workarounds, manual exceptions, and security gaps that erode the value of the entire automation investment.

Policy-as-code frameworks require similar design discipline. A policy library needs to cover real risks, avoid false positives that interrupt legitimate work, and be maintainable as the cloud environment evolves. Writing one policy is straightforward; maintaining 100 policies across changing cloud service APIs, evolving security standards, and multiple platform versions is a software maintenance problem that requires engineering rigor.

The cross-team influence dimension distinguishes this level from Engineer I. Engineer IIs contribute to platform decisions that affect multiple teams, evaluate tools across the organization's automation needs rather than a single team's needs, and build the relationships with development teams and security teams that make the platform genuinely useful rather than a compliance checkbox.

Mentoring at this level is substantive. Code review isn't just catching errors — it's explaining why a module interface should be designed one way versus another, how to think about testing trade-offs, and what makes a Terraform plan readable to someone who didn't write it. That coaching has leverage: every engineer whose skills improve is an ongoing benefit to the platform.

Education:

• Bachelor's degree in computer science, software engineering, or information systems
• Strong portfolios of production IaC work and relevant certifications are accepted alongside formal education

Experience:

• 5–8 years in cloud engineering, DevOps, or infrastructure automation roles
• 3+ years of production Terraform ownership — not just contributing to others' modules but owning module design and maintenance
• Evidence of cross-team influence: standards that other teams adopted, platform work that benefited multiple teams

IaC depth:

• Terraform: advanced module design, provider development basics, state migration strategies, workspace and environment patterns, Terratest for integration testing
• Terraform Cloud or Enterprise: RBAC, policy sets, run triggers, team workflows
• GitOps: Atlantis or equivalent for PR-based infrastructure workflows, drift detection and automated reconciliation
• Secondary familiarity with AWS CDK, Pulumi, or Crossplane for organizations using these alternatives

Policy and security automation:

• Policy-as-code: OPA/Rego for custom policy development, Checkov, tflint
• Security automation: IAM audit scripts, credential rotation automation, CSPM integration
• Compliance: translating framework requirements (CIS, SOC 2, PCI) into implemented policy rules

Software engineering:

• Python at a software engineering level: well-tested, well-documented, maintainable code — not just scripting
• Testing: Terratest, pytest for infrastructure tests, mocking cloud APIs for unit tests
• Code review: structured feedback that improves code quality and engineers' skills simultaneously

Architecture and design:

• Module versioning and lifecycle management: semantic versioning, changelog maintenance, deprecation policy
• Multi-account automation patterns: AWS Organizations scale, cross-account role assumptions
• Developer experience design: thinking about module consumers, not just implementors

The Cloud Automation Engineer II level is where market demand concentrates for the platform engineering specialty. Organizations that have committed to internal developer platforms need engineers who can own the automation frameworks at production quality — not just implement tasks, but design systems that scale. The supply of engineers at this level is limited relative to demand, keeping compensation strong.

Platform engineering as an organizational discipline is maturing. Companies like Google (internal developer platform), Spotify (Backstage), and the CNCF's Platform Engineering Working Group have documented the value of investing in platform capabilities, and the industry is following. This creates structured organizational demand for Cloud Automation Engineer II skills that goes beyond individual team needs.

The Kubernetes ecosystem creates a growing specialization path. Helm chart development, Kubernetes operator development, and GitOps with ArgoCD or Flux are skills that complement cloud IaC automation and are in demand at cloud-native organizations. Engineers who develop both cloud IaC depth and Kubernetes automation expertise have access to a broader set of high-compensation roles.

FinOps automation is an emerging specialization within cloud automation. Organizations with large cloud spend are investing in automated cost governance — tagging enforcement, idle resource cleanup, commitment optimization — and need engineers who can build these systems reliably. Cloud Automation Engineer IIs who develop FinOps automation expertise are well-positioned for dedicated FinOps engineering roles that are appearing at large cloud consumers.

Career progression from this level leads to Senior Cloud Automation Engineer, Cloud Automation Architect, Platform Engineering Lead, or Staff/Principal Engineer. The architecture track requires stronger design skills and broader organizational scope; the management track moves toward Engineering Manager for platform teams. Both paths represent meaningful compensation growth. Independent consulting is also a strong option: Cloud Automation Engineer II-level practitioners are in high demand at consulting and advisory firms building platform engineering practices.

Dear Hiring Manager,

I'm applying for the Cloud Automation Engineer II position at [Company]. I've spent five years building and operating cloud automation infrastructure, the last two and a half as a mid-senior platform engineer at [Company] owning our Terraform module library and GitOps workflow.

The module library I've designed and maintained now covers 23 standardized infrastructure patterns used by 40 development teams. When I took ownership of it 18 months ago, it was a collection of independently created modules with inconsistent interfaces and no testing. I rebuilt the interface design from scratch — establishing a standard variable naming convention, standardizing output structures, and adding mandatory variables for the security controls our policy framework requires. I also built a Terratest suite that runs integration tests for each module against a dedicated test account; the tests provision real resources, validate their configuration against compliance requirements, and tear them down. The CI pipeline runs these tests on every PR before the module can be merged.

On the GitOps side, I built our Atlantis integration that manages all infrastructure PRs through a review-and-apply workflow. Every Terraform change goes through a PR, gets a plan run automatically, requires approval from the platform team, and then gets applied with a full audit trail. We've gone from infrastructure changes that were sometimes undocumented console operations to a complete history of every resource change with the PR discussion that led to it.

I mentor two Engineer I team members — I review their PRs with detailed explanations of why I'm suggesting changes, not just what to change, and we pair on complex module design problems.

I'm looking for a role with more multi-cloud scope and exposure to a larger-scale developer community. I'd welcome the chance to discuss what you're building.

[Your Name]