Built and deployed a personal resume website entirely through infrastructure-as-code, following the Cloud Resume Challenge format — provisioning, securing, and deploying a static site on Azure without manually clicking through the portal.
- Resource group and Azure Storage Account provisioned via Terraform, with static website hosting enabled directly on the storage account
- Static HTML/CSS resume site uploaded and served from Azure Storage
- Azure Front Door Standard in front of the storage origin, providing global edge delivery and HTTPS
- All infrastructure defined as code —
.gitignoreconfigured from the first commit to exclude.tfstate/.tfvarsfiles - Continuous Deployment A GitHub Actions workflow (
.github/workflows/deploy.yml) automatically deploys any change pushed to thesite/folder onmain:
The original plan was classic Azure CDN in front of the storage account. While
building this, I hit a live error: Microsoft retired new classic CDN profile
creation (both Microsoft and Verizon SKUs) as of August 2025, pushing all new
deployments to Azure Front Door Standard/Premium instead. I adapted the Terraform
config to use azurerm_cdn_frontdoor_profile, _endpoint, _origin_group,
_origin, and _route resources instead of the classic CDN resource types.
This meant working through a genuinely current Azure platform migration rather than following a static tutorial — the kind of adaptation that comes up regularly in real cloud work.
Azure Storage's static website endpoint already serves HTTPS natively on its own domain, so Front Door wasn't strictly required for basic security. I added it anyway to demonstrate the pattern of never exposing an origin directly: Front Door provides global edge caching for faster load times worldwide, and in front of any real (non-static) workload would also provide DDoS protection and, on Premium, a Web Application Firewall. For this specific low-traffic, no-backend site, the security benefit is more about the pattern than an urgent need — worth knowing when it matters and when it's added cost/complexity.
A GitHub Actions workflow (.github/workflows/deploy.yml) automatically deploys
any change pushed to the site/ folder on main:
- Checks out the repo
- Authenticates to Azure using a service principal (credentials stored as a GitHub Secret, never in code)
- Uploads the site files to the storage account's
$webcontainer - Purges the Front Door cache so visitors see the update immediately
The pipeline only triggers on changes inside site/ — infrastructure changes
(main.tf) are applied manually and deliberately, mirroring how most real
teams separate infrequent, reviewed infra changes from frequent, automated
content deploys.
Permissions note: the service principal is granted the Storage Blob Data Contributor role, scoped only to this storage account — a data-plane role
separate from the Contributor role used to manage the resource itself. I hit
this exact gap during setup (the pipeline could manage the storage account but
not write blobs into it) and fixed it with a scoped role assignment rather than
falling back to a shared account key, since a scoped role limits the blast
radius if the credential were ever exposed.
Azure Front Door Standard carries a base monthly fee (~$35), unlike classic CDN's
pure bandwidth pricing. Since this is a portfolio demo rather than a production
site, I tore down all resources with terraform destroy after the first round
of testing, then redeployed to build and test the CI/CD pipeline.
- Used Claude for Terraform config and troubleshooting the CDN migration
- Caught an inaccuracy myself: was told Front Door was needed for HTTPS — checked the browser address bar and confirmed Storage's static site endpoint already had it
- Custom domain with Front Door-managed HTTPS certificate
- Architecture diagram showing the full request flow (User → Front Door → Storage)
- Application Insights or Front Door's built-in monitoring for real traffic data
- WAF (Front Door Premium) if the site ever needed dynamic/user-input functionality