{"slug": "can-ai-replace-cloud-engineers-i-put-it-to-the-test", "title": "Can AI Replace Cloud Engineers? I Put It to the Test", "summary": "A developer tested how much cloud engineering work could be delegated to AI across AWS, Azure, and Google Cloud, running live Level 2 deployments of a Layer 7 load balancer fronting two private VMs and a Level 3 design-document trial that scored 77/100 and failed its acceptance criteria. The AI handled Terraform, GitHub Actions, federated authentication, remote state, monitoring, failure tests, recovery, and cleanup of 139 Terraform-managed items, while the human retained requirements, identity boundaries, and approvals. Three failures surfaced: unreachable startup dependencies broke Nginx on AWS, a CI apply silently stripped tags from 12 Azure resources, and an untracked backend declaration made 18 existing Google Cloud resources appear new.", "body_md": "I tested how much of my cloud engineering work I could delegate to AI in two experiments.\n\nThe live Level 2 experiments completed deployment, selected failure tests, recovery, and cleanup across AWS, Azure, and Google Cloud. The latest Level 3 trial, D5, scored **77/100 in an independent AI review: FAIL against the acceptance criteria, HOLD for adoption**.\n\nThe distinction matters throughout this article. Level 2 has live execution records. Level 3 evaluates design documents. Neither experiment measures the percentage of a profession that can be replaced.\n\n“Level” is my own classification, not an industry standard or an official mapping to cloud certifications. I did not run the introductory Level 1 stage.\n\nThe common target was a Layer 7 load balancer serving HTTP through two private VMs. The VMs had no public IP addresses and no direct SSH access from the internet.\n\n| Component | AWS | Azure | Google Cloud | \n|---|---|---|---|\n| Public entry point | Regional ALB | Application Gateway | Global external Application Load Balancer | \n| Backend | Two EC2 instances in separate AZs | Two Linux VMs in separate zones | Two VMs in a regional managed instance group | \n| Outbound path | S3 Gateway Endpoint | NAT Gateway | Cloud Router and Cloud NAT | \n| Remote state | S3 | Blob Storage | Cloud Storage | \n\nThese were implementations of common requirements, not identical architectures. Google Cloud used a managed instance group, while AWS and Azure used individual VMs. A global load balancer did not make the backend multi-region.\n\nThe human retained responsibility for requirements, allowed changes, identity and exposure boundaries, and approvals. AI handled Terraform, GitHub Actions, short-lived federated authentication, remote state, monitoring, selected failure tests, recovery, and cleanup.\n\nI looked beyond a successful `terraform apply`:\n\nThe execution records report completion across all three clouds. Cleanup removed **139 Terraform-managed items**: AWS 48, Azure 53, and Google Cloud 38. These totals include the application infrastructure and bootstrap resources for state and authentication.\n\nThat is not a count of VMs or individually billable resources. “Zero remaining” refers to the managed active resources checked in this experiment. It does not mean an empty account, physical erasure of every retained copy, or a guarantee of no later charges. See the [Level 2 final report](https://github.com/moruku36/cloud-validation-level2-multicloud/blob/c5d25b637c2a71ffb84b6a7dab6c5f0f994062a0/docs/final-report.md) for the evaluation method and counts.\n\n**AWS: the instance was private, but its startup dependencies were unreachable.**\n\nInsufficient outbound connectivity prevented Nginx installation, and the ALB returned 502. AI diagnosed the problem and added narrowly scoped HTTPS access to the S3 prefix list. The lesson was to review startup dependencies alongside inbound isolation. This S3-based path depended on the selected OS package source; it was not general internet access.\n\n**Azure: a successful apply removed tags from 12 resources.**\n\nLocal and CI inputs differed. The CI apply completed successfully while removing additional tags. The inputs were aligned, and a tag-only repair followed human approval. The exit status alone did not establish that the change matched the intended result.\n\n**Google Cloud: missing backend configuration made 18 existing resources look new.**\n\nThe backend declaration was not tracked in Git. CI could not use the existing remote state and planned 18 additions. The process stopped before apply and repaired the declaration. Unexpected creation, deletion, or replacement needs to be a stop condition, not just another line in the output.\n\nThese incidents and their recovery are documented in the [failure analysis](https://github.com/moruku36/cloud-validation-level2-multicloud/blob/c5d25b637c2a71ffb84b6a7dab6c5f0f994062a0/docs/final-report.md).\n\nMonitoring checks covered selected signals and alert states. External notification receivers were not configured, so delivery to an operator was not demonstrated. The failure scenarios also differed between providers.\n\nThe experiments ran sequentially: AWS, then Azure, then Google Cloud, carrying lessons forward. Human-intervention counts used different units. That rules out a clean provider ranking or a defensible intervention-reduction percentage.\n\nThere was also no standardized human-only baseline for time, cost, or quality. The final report identifies code and CI controls that need checking before reuse; successful historical execution is not proof that the current checkout reproduces unchanged.\n\nThe supported conclusion is narrower: an experienced engineer could delegate a substantial implementation and operations lifecycle in small, disposable environments while retaining design, review, and approval. Production readiness, long-term SLOs, and unattended operation remain outside that result.\n\nThe second experiment started with a member-facing application: registration, login, profile changes, list/detail views, favorites, and administrative updates.\n\nIts main constraints were:\n\nThe RTO/RPO targets covered process, runtime, database, and single-AZ failures. Region-wide failure was excluded. These were **design requirements**, not observed service metrics. The [customer answers](https://github.com/moruku36/cloud-validation-level3-architect/blob/e1ad7ab1baa2dec111259dd37a8eef405d418746/docs/sources/business-answers-2026-09-08.md) and [requirements document](https://github.com/moruku36/cloud-validation-level3-architect/blob/e1ad7ab1baa2dec111259dd37a8eef405d418746/docs/requirements.md) preserve the input.\n\nBudget compliance could not depend on free tiers, temporary credits, or long-term commitment discounts.\n\nThe tension between a 30-minute recovery target and weekday daytime staffing is a useful example: selecting managed services does not by itself establish who can act, which actions are authorized, or whether unattended recovery works.\n\nThe September work was self-assessed: A moved from 61 to 65, and B scored 66. October introduced a reviewer separate from the designer. D4 and D5 used anonymously reviewed, frozen design-and-evidence packages.\n\nA passing design had to meet every condition:\n\nThe mandatory categories were requirements, architecture, security/IAM, availability, cost, and backup/disaster recovery. No human scoring or adoption approval was obtained. These were independent **AI document reviews**, not production acceptance tests.\n\n| Trial | Requested designer configuration | Independent score | \n|---|---|---|\n| D1 | GPT-6 Luna / Low | 53 | \n| D2 | GPT-6 Luna / Medium | 72 | \n| D3 | GPT-6 Luna / High | 69 | \n| D4 | GPT-6.1 Sol / Medium | 78 | \n| D5 | GPT-6.1 Sol / High | 77 | \n\nThese are **requested settings**. Actual runtime models and applied reasoning settings are UNKNOWN, including for the reviewers.\n\nThe series also carries earlier findings forward. D5 revised D4, added controls and evidence, and used a fresh reviewer. The scores cannot isolate a model or reasoning-effort effect. September self-scores are a different evaluation method and are not part of this series.\n\nThe latest authoritative trial is D5, dated October 2, 2026. It failed the acceptance criteria and remained on hold for adoption. The [methods and results](https://github.com/moruku36/cloud-validation-level3-architect/blob/e1ad7ab1baa2dec111259dd37a8eef405d418746/docs/research/METHODS-RESULTS.en.md) and [D5 report](https://github.com/moruku36/cloud-validation-level3-architect/blob/e1ad7ab1baa2dec111259dd37a8eef405d418746/docs/reports/2026-10-02-d5/FINAL-REPORT.en.md) explain the chronology and comparison limits.\n\nRequirements changed separately on October 2 remain unscored and were not D5 input. The score of 77 does not apply to those changed requirements.\n\n**Cost was 3/5, below its mandatory minimum of 4.** The design did not establish an all-inclusive budget fit with headroom, adequately supported effort for custom controls and rehearsals, or sufficiently concrete cheaper alternatives. Keeping unknown prices explicit was credited; unknowns did not become zero or evidence of affordability.\n\n**Deletion gate G3 remained HOLD.** Deletion-trigger events, retention of linking information, independent custody of evidence, and responsibility for external services or recipient copies were not approved.\n\n**Operations gate G4 also remained HOLD.** Named primary and backup owners, approved effort, absence coverage, and authority for unattended recovery were unresolved.\n\n**Added controls brought an evidence burden.** D5 added a SQL-backed AdmissionCoordinator to principal request paths. Evidence for operation counts, contention, latency, and recovery ordering was insufficient. Complexity fell from 4 to 3, accounting for the one-point total decrease from D4. Complexity 3 meets the general category floor; it is distinct from Cost failing a mandatory minimum.\n\nUnresolved P0 items concerned owner decisions, source access, and prerequisites for live validation, rather than identified P0 desk-design defects. The [D5 report](https://github.com/moruku36/cloud-validation-level3-architect/blob/e1ad7ab1baa2dec111259dd37a8eef405d418746/docs/reports/2026-10-02-d5/FINAL-REPORT.en.md) and [gate record](https://github.com/moruku36/cloud-validation-level3-architect/blob/e1ad7ab1baa2dec111259dd37a8eef405d418746/docs/reports/2026-10-02-d5/evidence/independent-review-D5/gates.csv) keep these distinctions explicit.\n\nLevel 2 demonstrated more than initial code generation. AI investigated provider constraints, authentication mismatches, partial applies, and state inconsistencies, then made scoped repairs and completed cleanup.\n\nLevel 3 showed increasingly specific design documents, but no accepted design. Missing prices, owner decisions, and empirical evidence remained missing. A score near 80 does not establish that acceptance is close when mandatory conditions remain unresolved.\n\nMy practical takeaway is to specify the verification and decision process alongside the delegated task:\n\nA useful next experiment would hold inputs, evidence, and evaluation conditions constant while verifying actual model settings. Live performance, recovery, and cost validation would be a separate step. Those are research proposals, not work already completed.\n\nFor now, the evidence supports broad delegation of predefined implementation under human control. It does not establish replacement of cloud engineering as a whole, or that a stronger model alone would satisfy the remaining adoption conditions.\n\nSource review date: October 6, 2026. References are pinned to Level 2 commit c5d25b6 and Level 3 commit e1ad7ab. The existing Japanese and English slides were also cross-checked. Preparing this article did not rerun cloud operations or produce a new assessment.\n\nAI assisted the structure, drafting, and English wording of this article. The experiment conditions, results, and limitations are based on the linked records.", "url": "https://wpnews.pro/news/can-ai-replace-cloud-engineers-i-put-it-to-the-test", "canonical_source": "https://dev.to/moruku36/can-ai-replace-cloud-engineers-i-put-it-to-the-test-5egl", "published_at": "2026-10-06 10:16:42+00:00", "updated_at": "2026-10-06 10:18:09.397056+00:00", "lang": "en", "topics": ["ai-agents", "mlops", "ai-tools", "ai-infrastructure"], "entities": ["AWS", "Microsoft Azure", "Google Cloud", "Terraform", "GitHub Actions", "Nginx", "Amazon S3", "EC2"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/can-ai-replace-cloud-engineers-i-put-it-to-the-test", "markdown": "https://wpnews.pro/news/can-ai-replace-cloud-engineers-i-put-it-to-the-test.md", "text": "https://wpnews.pro/news/can-ai-replace-cloud-engineers-i-put-it-to-the-test.txt", "jsonld": "https://wpnews.pro/news/can-ai-replace-cloud-engineers-i-put-it-to-the-test.jsonld"}}