C3: IaC Implementation
Objective
Section titled “Objective”- Do now: Choose one IaC path, generate templates, validate them, and attempt deployment.
- Input: Approved requirements, architecture and cost evidence, SKU manifest, and current review findings.
- Output: Governance constraints, approved IaC plan and contracts, one IaC track, validation evidence, deployment summary, and workflow diagram.
- Required to move on: Governance reconciliation, approved plan review, one validated IaC path, explicit deployment authorization, a recorded deployment attempt, and the workflow explanation.
- Decisions now: Bicep vs Terraform, module boundaries, governance handling, and what evidence to keep.
- Next: C4 branches from your actual deployment outcome and extends the same platform for HA/DR.
This is the most execution-sensitive step in the sequence. Keep the work moving by choosing one path, validating often, and recording what happened.
The Business Challenge
Section titled “The Business Challenge”Nordic Fresh Foods now needs production-ready infrastructure code that can be deployed consistently, respects governance and security controls, and stays maintainable for a small DevOps function. A design that looks good on paper but cannot be validated or deployed is not enough.
Your Tasks
Section titled “Your Tasks”- Discover governance (~5 min). Select
04g-Governanceto capture effective policy constraints in04-governance-constraints.mdand.json. If constraints exist, complete the required reconciliation review and approval. - Plan the implementation (~8 min). Select
05-IaC Plannerto create04-implementation-plan.mdand the machine-readable contracts. Select10-Challenger, resolve blocking plan findings, and approve the plan. - Generate one IaC track (~10 min). Select
06b-Bicep CodeGenor06t-Terraform CodeGenaccording to the approved requirements. Keep the approved plan read-only and retain05-iac-handoff.json. - Validate and preview (~7 min). Run the deterministic checks and Bicep what-if or Terraform plan. Validation success does not authorize deployment.
- Authorize and deploy (~10 min). Review the proposed scope and current evidence as a team. Explicitly authorize the matching Deploy agent, then capture the result in
06-deployment-summary.md. If deployment fails, preserve the exact blocker. - Explain the compressed workshop path (~5 min). Create
03-des-deployment-workflow.mdshowing human handoffs, reviews, approval gates, validation, deployment, and return paths.
Key Decisions
Section titled “Key Decisions”- Which IaC language gives your team the best chance of producing maintainable, reviewable code inside the workshop timebox?
- Which resources or concerns deserve separate modules, and which can stay simple in the first version?
- Which governance and security requirements must be built into the templates before you even try deployment?
- What evidence best proves that the templates are real, validated, and understood by the team?
Deliverables
Section titled “Deliverables”agent-output/freshconnect/04-governance-constraints.mdand.json- Governance reconciliation evidence when effective constraints exist.
agent-output/freshconnect/04-implementation-plan.mdand its machine-readable contracts.- Current plan review evidence with no unresolved blocking findings.
- IaC folder at
infra/bicep/freshconnect/orinfra/terraform/freshconnect/. agent-output/freshconnect/05-iac-handoff.json.- Validation and preview evidence for the selected track.
agent-output/freshconnect/06-deployment-summary.mdand policy-precheck evidence.agent-output/freshconnect/03-des-deployment-workflow.mdshowing the real human-approved path.
Success Criteria
Section titled “Success Criteria”| Focus | What good looks like | Evidence |
|---|---|---|
| Governance closure | Effective policy constraints are known before planning | Governance artifacts and reconciliation evidence are present or the no-constraints condition is recorded |
| Approved implementation strategy | The plan connects approved architecture, cost, SKU, and governance evidence to code generation | Plan contracts and current Challenger evidence are complete |
| Maintainable IaC | One selected track is structured for readability and reuse | The IaC folder follows the approved plan and includes the handoff artifact |
| Validation and authorization | The team separates deterministic validation from permission to deploy | Preview evidence exists and deployment authorization is explicit |
| Delivery understanding | The team can explain what happened and why | Deployment evidence and workflow diagram show handoffs, gates, failures, and return paths |
Tips / Hints
Section titled “Tips / Hints”Common implementation blockers
Use Quick Reference Card for shared naming rules, Quick Reference Card for the security baseline, and Hints & Tips for common policy denials.
If you hit a deployment blocker, record three things before you ask the agent to help:
- The exact error message.
- Which resource or module caused it.
- Whether the failure happened at validation, preview, or deployment time.
Watch Out
Section titled “Watch Out”- Governance discovery is not optional because the challenge is time-boxed.
- A missing or failed Azure policy query does not prove that no constraints exist.
05-IaC Plannerowns plan corrections. CodeGen must not silently rewrite the approved plan.- Validation success is not deployment success and does not grant deployment permission.
- Preserve the exact preview, policy, deployment, and application-health limits in the summary.
- Do not skip artifact names; later challenges and facilitator review depend on them.
Artifact Handoff
Section titled “Artifact Handoff”| Item | Value |
|---|---|
| Input from | Approved requirements, architecture, cost, SKU, and review evidence from C1-C2 |
| Your output | Governance, approved plan, IaC handoff, validation, deployment evidence, and workflow diagram |
| Next challenge uses | C4 branches from your deployment outcome and extends the same design with HA/DR changes |
Next Step
Section titled “Next Step”Challenge 4 uses your actual deployment outcome, not the ideal one. If deployment succeeded, you will extend the platform; if it partially worked or failed, you will use that evidence to justify the DR path you propose next.