Deploying Cloud Infrastructure Through Infrastructure as Code

Client context

This page presents a representative enterprise implementation pattern, not a named customer engagement. No client identity or project-specific results were provided.

Starting state pattern

Provisioning may span portal changes, engineer-owned scripts, duplicated IaC, environment-specific configuration, long-lived credentials and limited drift controls. This is an illustrative pattern, not a verified client baseline.

Executive Summary

Manual infrastructure deployment works at small scale, but it becomes increasingly difficult to control as cloud environments grow. Configuration drift appears between environments, change history becomes incomplete, security controls depend on individual knowledge, and application teams wait for infrastructure specialists to provision resources.

This representative engagement shows how Tongtech converts cloud infrastructure delivery into a version-controlled engineering workflow using Infrastructure as Code, reusable modules, automated validation, secure deployment identities, and CI/CD.

The objective is to make infrastructure delivery repeatable without turning the IaC platform into an unnecessarily complex abstraction layer.

The Challenge

A typical cloud environment begins with a mixture of:

• resources created manually in the cloud portal
• deployment scripts maintained by individual engineers
• inconsistent naming and tagging
• duplicated Terraform code
• environment-specific configuration
• long-lived service-principal secrets
• infrastructure changes performed outside change control
• incomplete documentation
• no reliable drift-management process
• production deployments that depend on a small number of specialists

The organization needs a deployment model in which infrastructure is treated as software.

Objectives

The IaC platform is designed to:

1. Make infrastructure definitions version-controlled and reviewable.
2. Standardize recurring infrastructure patterns.
3. Reduce configuration differences between environments.
4. Eliminate unnecessary manual portal deployment.
5. Integrate infrastructure changes with CI/CD.
6. Add automated security and policy checks before deployment.
7. Use short-lived or federated authentication where possible.
8. Create clear promotion and approval processes.
9. Keep the code understandable to internal engineering teams.
10. Allow application teams to consume platform patterns without bypassing governance.

Target Delivery Model

Engineer Changes IaC
        ↓
Pull Request
        ↓
Format / Lint / Validate
        ↓
Security & Policy Checks
        ↓
Terraform Plan / Bicep What-If
        ↓
Peer Review
        ↓
Approval
        ↓
Merge
        ↓
Environment Deployment
        ↓
Post-deployment Validation

The cloud portal becomes an operational interface rather than the primary deployment mechanism.

Repository and Code Structure

A maintainable structure separates reusable components from environment-specific configuration.

infra/
  modules/
    network/
    private-endpoint/
    key-vault/
    storage/
    app-service/
    aks/
    monitoring/

  environments/
    dev/
    test/
    staging/
    production/

  platform/
    identity/
    connectivity/
    policy/
    monitoring/

  policies/
  pipelines/
  scripts/
  docs/

Key principles:

• reusable logic belongs in modules
• environment configuration remains explicit
• secrets are not stored in code
• provider and module versions are controlled
• state ownership is clearly defined
• changes are applied through repeatable workflows

Reusable Terraform and Bicep Modules

Reusable modules are created around real platform boundaries rather than around every individual resource.

Useful module boundaries can represent:

• a private App Service pattern
• an application network
• a Key Vault with standard security controls
• a storage account with private connectivity
• AKS platform components
• diagnostic settings
• role assignments
• a Private Endpoint plus DNS integration

The approach is to use abstraction only where it improves consistency, security, maintainability, or developer experience.

State Management

For Terraform, remote state is configured using a controlled backend.

The design addresses:

• state isolation
• environment separation
• access control
• locking
• backup and recovery
• sensitive values
• state ownership

State boundaries follow deployment and ownership boundaries rather than placing the entire estate into one oversized state file.

Identity and Authentication

CI/CD pipelines should not depend on personal accounts or long-lived cloud secrets.

Where supported, deployment pipelines use workload identity federation.

For Azure deployments, this commonly means:

• Microsoft Entra application or managed identity
• federated credential
• narrowly scoped Azure RBAC
• GitHub OIDC or Azure DevOps workload identity federation

Permissions are separated between validation, non-production deployment, production deployment, state access, and administrative platform operations.

CI/CD Validation

Every infrastructure change should be validated before it reaches production.

Code Quality

• terraform fmt
• terraform validate
• Bicep validation
• linting
• dependency/version checks

Security

Depending on tooling:

• Checkov
• tfsec
• Trivy
• Microsoft security tooling
• custom static checks

Policy as Code

OPA/Conftest or equivalent policy checks can enforce engineering standards before cloud deployment.

Examples:

• prohibit public storage access
• require approved regions
• require diagnostic configuration
• prevent overly permissive network rules
• restrict specific SKU choices
• validate tags or ownership metadata

Azure Policy provides runtime governance, while pipeline policy catches issues earlier in delivery.

Pull Request Workflow

Infrastructure changes are reviewed using the same engineering discipline as application code.

A pull request can include:

• change description
• architecture impact
• Terraform plan
• policy results
• security scan results
• deployment risk
• rollback considerations

Reviewers see the proposed infrastructure changes before they are applied.

Environment Promotion

Development, test, staging, and production use the same underlying infrastructure patterns where practical.

Differences should be configuration-driven rather than implemented as unrelated copies of code.

Promotion does not necessarily mean deploying the same resource sizes everywhere. It means applying the same architectural pattern through controlled configuration.

Secrets and Sensitive Configuration

Secrets are stored outside the code repository.

Common approaches include:

• Azure Key Vault
• managed identities
• federated identities
• secured CI/CD variables for unavoidable secrets

Where possible, workloads authenticate directly using managed identity so application-level secrets can also be reduced.

Drift Management

The operating model includes:

• scheduled plan or drift detection
• review of portal changes
• clear break-glass procedures
• remediation through code
• restrictions on unnecessary write access

The declared IaC configuration remains the authoritative state of the platform.

Platform Consumption

Reusable infrastructure patterns can be exposed to application teams through:

• documented Terraform modules
• reusable pipeline templates
• repository templates
• service catalog entries
• internal developer platform workflows
• controlled self-service provisioning

This allows application teams to consume standardized cloud infrastructure without administrator access to every underlying service.

Implementation Sequence

1. Assess Existing Deployment Practices

Review current IaC, portal-created infrastructure, scripts, pipelines, identity model, state management, module duplication, environment differences, and operational pain points.

2. Define IaC Standards

Decide on Terraform, Bicep, or a justified combination; repository structure; module boundaries; naming conventions; state boundaries; version strategy; deployment identity model; and code review process.

3. Build Core Modules

Prioritize recurring patterns rather than attempting to modularize the entire cloud estate immediately.

4. Build CI/CD

Implement validation, plan/preview, security checks, policy checks, approvals, deployment, and post-deployment validation.

5. Migrate Existing Infrastructure

Existing resources can be imported or progressively brought under code rather than recreated blindly.

6. Operationalize

Document the contribution process, release process, break-glass procedure, module ownership, upgrade strategy, drift handling, and troubleshooting model.

Representative Deliverables

A typical engagement can include:

• IaC architecture and standards
• repository structure
• reusable Terraform/Bicep modules
• remote state design
• environment configuration
• GitHub Actions or Azure DevOps pipelines
• workload identity federation
• policy-as-code controls
• security validation
• documentation
• deployment runbooks
• migration plan for existing infrastructure

Outcome

The infrastructure platform becomes reproducible, reviewable, and easier to operate.

Instead of relying on manual cloud configuration, teams work from a declared desired state stored in source control.

The organization gains:

• consistent infrastructure patterns
• clearer change history
• stronger deployment controls
• reduced configuration drift
• reusable platform components
• simpler onboarding for new workloads
• better separation between platform and application responsibilities
• a foundation for controlled self-service

Most importantly, infrastructure delivery becomes an engineering process rather than an accumulation of manual cloud changes.

Technologies

Terraform · Bicep · Microsoft Azure · GitHub Actions · Azure DevOps · Workload Identity Federation · Open Policy Agent · Conftest · Azure Policy · Key Vault · CI/CD

Next step

Discuss a similar Platform Engineering challenge.

Share your current architecture, constraints and desired next step. Tongtech can help determine whether a focused review or implementation engagement fits.

Book an Architecture Review →