IN THE IMPLEMENTATION
Reviewable network contract
- Derived, non-overlapping /20 allocations
- One /24 workload subnet per VNet
- NSG association and explicit inbound deny
- Bidirectional hub/spoke peerings
- Validated owner and environment inputs
ENGINEERING CASE STUDY / AZURE + TERRAFORM
Azure foundation.
Boundaries before workloads.
A small Terraform foundation designed to make network allocation, team ownership, security intent and future deployment authority explicit before application infrastructure arrives.
- Implemented
- One resource group, a hub, Team A and an optional Team B spoke. Each VNet has a workload subnet, NSG and explicit inbound deny.
- Recorded evidence
- 17 Terraform mock tests passed, 0 failed for the merged second-team increment.
- Evidence boundary
- Configuration only. No Azure deployment, packet-flow test, production workload or customer outcome is claimed.
01 / THE PLATFORM PROBLEM
A VNet is easy.
Ownership is the architecture.
A foundation becomes difficult when the second team arrives. Address space must remain predictable. Existing resources must not acquire new Terraform addresses by accident. Connectivity needs a clear owner. Application automation should not inherit authority over shared network decisions.
I kept the implementation deliberately small so those boundaries could be inspected instead of buried inside a framework: a single subscription-level resource group, one hub, Team A and an optional Team B spoke, all created through a reusable network module.
The interesting question is not whether Terraform can create another spoke. It is who owns the state, the connection and the failure when that spoke changes.
OUTSIDE THE CLAIM
Operational platform work
- Management groups and Azure Policy
- Remote state and deployment identities
- Firewall, gateway, DNS and controlled egress
- Live permission and packet-flow tests
- Production workloads and measured outcomes
02 / IMPLEMENTED ARCHITECTURE
One allocation.
Three explicit boundaries.
Subscription-level network foundation
The default /16 is divided into deterministic /20 slots. Both enabled spokes peer with the hub in both directions. No direct Team A-to-Team B peering, gateway transit or forwarded traffic is created.
BASE ALLOCATION10.42.0.0/16Example only · verify against the authoritative network inventory
SLOT 0 / PLATFORM
Hub
10.42.0.0/20- Subnet
- 10.42.0.0/24
- Owner
- platform-engineering
- Inbound
- Explicit deny
SLOT 1 / DEFAULT
Team A
10.42.16.0/20- Subnet
- 10.42.16.0/24
- Owner
- Configurable tag
- Peering
- Both directions to hub
SLOT 2 / OPTIONAL
Team B
10.42.32.0/20- Subnet
- 10.42.32.0/24
- Owner
- Required when enabled
- Peering
- Both directions to hub
Implemented configurationOptional configurationInbound denied by default
Peering creates routes; it does not override the subnet NSGs or authorize application traffic. Default Azure outbound rules remain, so the lab does not demonstrate controlled egress.
03 / ARCHITECTURE DECISIONS
Preserve what is stable.
Expose what can change.
Derive addresses from one allocation
cidrsubnet assigns fixed /20 slots from a supplied /16, preventing overlap inside this deployment. It cannot detect collisions elsewhere in an enterprise network.
Keep Team A's address stable
The existing module.spoke and peering addresses remain unchanged. Team B uses its own stable team_b key instead of turning old resources into indexed instances.
Reuse the module, not the entire root
One network module standardizes VNet, subnet, NSG and association behavior. The root retains allocation and shared-connectivity decisions.
Treat tags as metadata
Per-team owner tags identify accountability. They do not grant Azure access, separate state or prove operational ownership.
Manage both peering directions together
Platform-owned connectivity prevents two teams from competing over the same relationship. It also creates sequencing requirements for onboarding and teardown.
Make the lab reject production intent
Variable validation accepts only lab, dev or test. Production requires a separately reviewed design rather than a different string.
04 / TEAM ONBOARDING
A second spoke is code.
A second owner is governance.
Enabling Team B is a small configuration change. Onboarding Team B safely would also require an approved allocation, enforced deployment authority, a connectivity contract, positive and negative tests, recovery instructions and a handover record.
| Concern | Current lab | Proposed operational boundary |
|---|---|---|
| State | One Terraform root using local state. | Separate, access-controlled Azure Storage state aligned to ownership and lifecycle. |
| Shared connectivity | Root owns the hub and both directions of every peering. | Platform state and identity retain the hub, routing and peering authority. |
| Team foundations | All networks share one resource group and execution boundary. | Team-scoped resource groups, state and deployment identities consume an approved contract. |
| Access | Owner tags identify responsibility only. | Entra identities and Azure RBAC enforce the intended authority. |
| Acceptance | Mock tests inspect configuration contracts. | Azure inspection, permission tests, packet-flow tests, cost review and teardown evidence. |
05 / NETWORK SECURITY CONTRACT
Routing is not permission.
IMPLEMENTED
Explicit inbound deny
Each workload subnet is associated with an NSG containing a priority-4096 inbound deny. Future application traffic needs a narrower reviewed allow rule with a lower priority number.
IMPLEMENTED
No implicit transit
Peerings disable forwarded traffic, gateway transit and remote gateways. No direct inter-team peering is created.
BOUNDARY
No controlled egress claim
The configuration contains no Azure Firewall, NAT design or custom outbound rules. Default Azure outbound behavior remains.
BOUNDARY
No packet-flow claim
Provider schemas and mock values can verify configuration intent. They cannot prove effective routes, Azure authorization, DNS behavior or live traffic.
06 / DELIVERY TRUST BOUNDARY
Validate without credentials.
Deploy only after trust.
The repository implements credential-free pull-request validation. A team deployment path is intentionally documented as a separate extension so untrusted code does not automatically inherit Azure authority.
IMPLEMENTED / NO AZURE CREDENTIALS
Pull-request validation
Format, locked provider initialization, schema validation and Terraform mock tests.
PROPOSED / REVIEW GATE
Approved commit + plan
A protected environment binds human approval to the exact source and reviewed plan.
PROPOSED / SHORT-LIVED ACCESS
OIDC to Azure
A narrowly scoped identity performs only the authorized deployment operation.
Remote state bootstrap, federated identity, protected environments and privileged apply automation are not included in the current repository.
07 / RECORDED EVIDENCE
Seventeen contracts.
Zero Azure credentials.
17
Terraform mock tests passed
The merged second-team increment recorded 17 passing plan-only runs and no failures.
0
Cloud credentials used by CI
The workflow validates provider schemas and configuration contracts without contacting Azure APIs.
1c24b17
Inspected source revision
This article links the exact current repository revision used for its implementation claims.
What the test contract checks
- Expected hub, Team A and optional Team B allocations
- Stable existing Team A and hub configuration when Team B is enabled
- Owner tags on VNets and NSGs
- Bidirectional peerings with forwarded traffic disabled
- Explicit inbound-deny fields in the network module
- Default-off behavior and alternate Team B allocation
- Rejection of blank owners and reserved, fractional or out-of-range slots
These tests establish configuration contracts. They do not establish Azure permissions, live NSG association, packet flow, service availability or production readiness.
08 / FROM FOUNDATION TO LANDING ZONE
Keep the next work
visible.
What an enterprise design still needs
- Management-group and subscription organization
- Azure Policy and compliance ownership
- Central logging, monitoring and security operations
- DNS, routing, inspection and controlled egress
- Remote state, identity and break-glass procedures
- Cost controls, operational acceptance and recovery exercises
What must happen before a real apply
- Verify the subscription and authoritative IP inventory
- Register required resource providers deliberately
- Review pricing and a saved Terraform plan
- Treat plan and state files as sensitive
- Run positive and negative connectivity checks
- Inspect a destroy plan and preserve state until deletion is verified
LET’S TALK
Bring me the
interesting problems.
I’m looking for Senior DevOps and Platform Engineering opportunities where I can improve Azure delivery, build useful automation and help teams operate with clearer boundaries.
bailey.n.fitchett@gmail.comAPPLY THE APPROACH TO YOUR ENVIRONMENT
Infrastructure Alchemy
Review Terraform module boundaries, compatibility and maintainability within an agreed scope.
Separate consulting assessment. The evidence and limitations above remain specific to the original project or demonstration.
Email WitchOps Explore the assessment ↗