A cloud portal makes it easy to create a resource. Choose a service, fill in a form and click deploy. That convenience is valuable when exploring a service, inspecting an environment or handling a tightly controlled emergency. It becomes a problem when the portal is the normal way an organization builds its infrastructure.
A click changes the live environment, but it does not automatically create a durable description of why the change was made, how it should be reproduced, who reviewed its impact or how another environment should match it. The cloud activity log may record that an operation happened. The missing piece is a versioned desired state connected to validation, approvals and future deployments.
For enterprise infrastructure, the system of record should be code and the change path should be reviewable: Git → pull request → validation → policy → Terraform or Bicep plan → approval → controlled deployment. The portal remains useful as an interface to inspect and operate the platform; it should not be the undocumented source of truth for production architecture.
Portal-driven infrastructure creates four predictable problems
1. Configuration differs between environments
When engineers create resources by hand, they repeat decisions from memory: network ranges, tags, identity settings, diagnostics, firewall rules, policies and service options. Small differences accumulate. A development environment may work because someone enabled a setting manually, while production lacks it—or production may carry a broad permission that no one intended to copy.
The risk is not that every portal change is wrong. It is that consistency depends on people remembering every relevant choice across every environment and resource lifecycle.
2. Recreating a working environment becomes archaeology
If an environment must be recovered, expanded to another region or reproduced for testing, teams need to reconstruct what was created and which settings mattered. Screenshots, runbooks and portal history can help explain past actions, but they are not an executable definition of the intended architecture. Rebuilds then become slow investigations rather than repeatable deployments.
3. Change control sees the request, not the actual change
A ticket may say “increase capacity” or “open access for the application.” Reviewers still need to know which resources and properties will change, what could be deleted or replaced, and how the change affects dependent services. A pull request with a Terraform plan or Bicep what-if output gives reviewers concrete proposed changes before deployment. It connects the reason for the change to the exact infrastructure diff.
4. Live state drifts away from intended architecture
When people change settings directly in the portal but do not update the infrastructure definition, the declared configuration and actual environment diverge. Later automation may overwrite the manual fix, preserve an accidental exception or propose changes no one expects. Without regular comparison, teams may not notice the difference until an incident, audit or environment rebuild.
Microsoft’s Cloud Adoption Framework describes IaC as a versioned definition deployed through pipelines and recommends using it to detect and manage configuration drift in landing zones. The Engineering Library’s IaC Drift Detection, Reconciliation, and Safe Import guide covers how to identify and safely reconcile differences between declared and live state.
Move infrastructure changes into a controlled code path
Portal-first production change
Ticket or request → manual settings → live state with incomplete change evidence.
Result: reproduction, review and drift investigation depend on people reconstructing what happened.
Code-first production change
Git change → pull request → validation and policy → plan review → controlled deployment.
Result: intent, proposed impact, approval and deployment evidence stay connected.
A reliable workflow makes the infrastructure change visible before it reaches the environment:
- Git: store the desired state, reusable modules, policy and environment parameters in source control.
- Pull request: explain the operational reason and scope, then review the code and its impact with the people responsible for the platform and workload.
- Validation: run formatting, static checks, module validation, security scans and tests appropriate to the change.
- Policy: evaluate organizational requirements such as approved regions, private network access, identity, encryption, required tags and logging.
- Plan or what-if: produce the proposed resource changes from the current environment state so reviewers can detect unexpected replacement, deletion or scope.
- Controlled deployment: deploy through a governed pipeline with an appropriately scoped identity and a human approval gate where risk requires it.
- Reconcile and observe: compare actual state to declared state, investigate drift and record deployment results for operations.
This workflow applies whether the implementation uses Terraform, Bicep or another declarative tool. Terraform’s core workflow describes writing, planning and applying changes, including plan review in a team pull request. Azure Resource Manager’s Bicep what-if operation previews resource changes without applying them.
Keep the portal useful while moving production intent into a reviewable change path
Portal-first production change
Ticket or request → manual settings → live state with incomplete change evidence.
Result: reproduction, review and drift investigation depend on people reconstructing what happened.
Code-first production change
Git change → pull request → validation and policy → plan review → controlled deployment.
Result: intent, proposed impact, approval and deployment evidence stay connected.
Keep the portal; change its role
“Stop building through the portal” does not mean remove access to the cloud console. Engineers still need to inspect resources, review telemetry, understand service health and perform approved operational tasks. A portal can also be the front end for a controlled workflow—such as a self-service request that opens a pull request or triggers a governed deployment.
The architectural boundary is whether a change to durable infrastructure is captured in the versioned desired state and follows an accountable change process. Read-only inspection and documented break-glass operations have a place. Routine production configuration should not exist only as a sequence of clicks.
Make exceptions visible and recoverable
Emergencies sometimes require direct intervention. The key is to treat that as an exception with a defined identity, reason, scope and expiry—not as a competing deployment process. Record what changed, notify the owner, update the IaC definition to reflect the intended state, and run a new plan or what-if before the next normal deployment.
Separate the permissions for preview and deployment. A plan job should have only the read access it needs; an apply job should use a controlled identity with write access to the target scope. Production approval should review the concrete plan and account for any changes that occurred after an earlier speculative plan.
From infrastructure code to a dependable platform
Once core infrastructure changes follow a repeatable path, the organization can make that path easier to consume. Standard modules, pipeline templates and policy checks become part of a platform product. Workload teams request a supported environment and contribute workload-specific code, while the platform supplies consistent guardrails and deployment mechanics.
This is the practical meaning of “architecture becomes code”: decisions are explicit, changes can be reviewed, environments can be reproduced and differences can be explained. The next steps build on the same foundation—policy, configuration and platform as code—and the wider progression from a landing zone to self-service delivery and workload platforms.
This article focuses on the change path; From Architecture Diagram to Production explores how architectural decisions connect to executable infrastructure and operational evidence.
Tongtech’s Cloud Foundation work establishes governed cloud environments. Platform Engineering turns IaC, policy and delivery workflows into reusable capabilities. The Azure Landing Zone Accelerator and Platform Engineering Accelerator provide practical starting points.
Close the loop after a break-glass change
An emergency portal change should have a short, explicit path back into the normal source of truth. Capture the affected resource, the operator identity, the incident or request, the setting changed and any temporary permission or network exposure introduced. Once the immediate risk is controlled, update the infrastructure definition or explain why the difference is intentionally temporary, then run a plan or what-if to understand the next deployment. Do not hide the intervention with a broad ignore rule or assume that a later apply will safely repair it. Review the exception and remove temporary access when the incident is closed. For high-impact changes, attach the follow-up plan and reconciliation decision to the incident record so the next operator can see whether the deployed difference was adopted, reverted or left under an approved exception. After reconciliation, run the same plan and policy checks used for a routine change so the follow-up does not introduce a second unreviewed difference.
Continue reading
References
- Use Infrastructure as Code to update Azure landing zones — Microsoft Cloud Adoption Framework.
- Overview of the core Terraform workflow — HashiCorp Developer.
- Terraform plan command — HashiCorp Developer.
- Bicep What-If: Preview changes before deployment — Microsoft Learn.