C3: IaC Implementation

Objective

Do now: Choose one IaC path, generate templates, validate them, and attempt deployment.
Input: 02-architecture-assessment.md and your architecture diagram.
Output: IaC templates, agent-output/freshconnect/04-implementation-plan.md, agent-output/freshconnect/03-des-deployment-workflow.md, and agent-output/freshconnect/06-deployment-summary.md.
Required to move on: One working IaC path, validation results, 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 actually happened.

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

Plan the implementation (~10 min). Use 05-IaC Planner to turn the architecture assessment into a phased implementation plan and save it as agent-output/freshconnect/04-implementation-plan.md.
Generate the IaC (~15 min). Use the matching code agent to create a modular folder structure, tags, naming approach, and security settings for your chosen path.
Validate and deploy (~15 min). Run the required validation and preview step, then attempt the deployment. If deployment fails, capture the exact blocker and the fix you would make next, then save a concise summary at agent-output/freshconnect/06-deployment-summary.md.
Explain the workflow (~5 min). Create a Mermaid flowchart showing how agents, validation, preview, deployment, and feedback loops fit together, then save it at agent-output/freshconnect/03-des-deployment-workflow.md.

Path	Planning agent	Code agent	Output folder
Bicep	`05-IaC Planner`	`06b-Bicep CodeGen`	`infra/bicep/freshconnect/`
Terraform	`05-IaC Planner`	`06t-Terraform CodeGen`	`infra/terraform/freshconnect/`

Challenge 3

IaC Agent Routes

Path	Planning agent	Code agent	Output folder
Bicep	`05-IaC Planner`	`06b-Bicep CodeGen`	`infra/bicep/freshconnect/`
Terraform	`05-IaC Planner`	`06t-Terraform CodeGen`	`infra/terraform/freshconnect/`

Path	Validate	Preview	Deploy
Bicep	`bicep build main.bicep` and `bicep lint main.bicep`	`az deployment group what-if ...`	`az deployment group create ...`
Terraform	`terraform init` and `terraform validate`	`terraform plan -out=tfplan`	`terraform apply tfplan`

Challenge 3

IaC Validation And Deployment Commands

Path	Validate	Preview	Deploy
Bicep	`bicep build main.bicep` and `bicep lint main.bicep`	`az deployment group what-if ...`	`az deployment group create ...`
Terraform	`terraform init` and `terraform validate`	`terraform plan -out=tfplan`	`terraform apply tfplan`

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

agent-output/freshconnect/04-implementation-plan.md
agent-output/freshconnect/03-des-deployment-workflow.md
agent-output/freshconnect/06-deployment-summary.md
IaC folder at infra/bicep/freshconnect/ or infra/terraform/freshconnect/
Validation evidence such as build, lint, validate, or plan output.
Deployment evidence or blocker notes captured in 06-deployment-summary.md.
Mermaid workflow diagram covering generation, validation, deployment, errors, and iteration in 03-des-deployment-workflow.md.

Success Criteria

| Focus | What good looks like | Evidence | | ------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | Implementation strategy | The team has a clear path from architecture to deployable resources | 04-implementation-plan.md reflects sequence, dependencies, and assumptions | | Maintainable IaC | Templates are structured for readability and reuse | The IaC folder has sensible files, modules, parameters, and naming strategy | | Validation and governance | The team checks quality before deployment and handles policy constraints intentionally | Validation output exists and required tags or security settings are included | | Delivery understanding | The team can explain what happened and why | Deployment evidence and workflow diagram show the real path, including failures if any |

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

Validation success is not the same as deployment success.
Azure Policy propagation can lag; still include the required tags and security settings even if you are not denied immediately.
Global names can fail late, so keep your naming strategy explicit.
Do not skip the exact artifact names; later challenges and facilitator review expect 03-des-deployment-workflow.md and 06-deployment-summary.md.

Artifact Handoff

| Item | Value | | ----------------------- | -------------------------------------------------------------------------------------------------------- | | Input from | agent-output/freshconnect/02-architecture-assessment.md, architecture diagram | | Your output | IaC folder, agent-output/freshconnect/04-implementation-plan.md, deployment evidence, workflow diagram | | Next challenge uses | C4 branches from your deployment outcome and extends the same design with HA/DR changes |

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.