Demonstration lab · Cloud Engineering
Cloud Engineering lab. Terraform and local verification.
This demonstration lab translates an AWS architecture into Terraform code and repeatable checks. It is the same example discussed in the Cloud Architecture article. Here, the focus is on implementation, input constraints and local verification with a mock provider.
The context
From design to module
The module defines infrastructure for distributing public web files: an S3 bucket as a private origin and a CloudFront distribution. Resources, permissions and dependencies are expressed in code. Uploading content, setting up the domain and obtaining the certificate remain separate tasks.
Illustrative diagram
From module code to mock-provider tests.
An illustration of the Cloud Engineering lab: Terraform code and local checks with a mock provider. No AWS deployment: the tests do not verify AWS APIs or real HTTPS delivery.
Open the full-resolution diagramThe constraint
Make the configuration verifiable
The work defines the module's inputs and the conditions to maintain: a non-public origin, CloudFront access restricted to the intended distribution and HTTPS for visitors. Tests must distinguish these requirements from the dummy values generated by the mock provider.
Implementation, step by step
Implementation work
Define resources and permissions
The configuration covers object ownership, public access blocking, encryption and S3 versioning. Origin Access Control signs requests; the bucket policy authorises object reads by the specified distribution.
Make HTTPS and cache settings explicit
The domain and certificate ARN are required variables. The distribution uses a custom certificate, the TLSv1.2_2021 policy and an HTTP-to-HTTPS redirect. A separate policy defines cache lifetimes for static content.
Validate the inputs
Input validation makes the naming, domain and certificate constraints explicit. Negative test cases describe configurations that must be rejected, including a certificate ARN outside the region required for CloudFront certificates.
Prepare repeatable checks
The lockfile pins the provider version and checksums. The procedure includes formatting, validation and test plans with mocks. Mock ARNs have deterministic values; assertions examine the policy produced by the module and the links between resources.
Local lab checks
Lab artefacts
The results concern code and local checks. They do not represent infrastructure tested on AWS.
- Explicit resources and dependencies
- Inspectable code
The module connects the origin, access control, policy and distribution, making its configuration choices readable.
- Declared constraints
- Validated inputs
Validation rules and negative cases describe which values must be accepted or rejected.
- Mock provider · all passed
- 12 local tests
Four scenarios check configuration properties; eight verify that invalid inputs are rejected. Every run uses a simulated plan.
Available materials
Code and verification
Scope of the results
What the checks cover.
Validation checks syntax, schema and configuration consistency; mocks do not verify AWS APIs. They do not establish that the certificate exists, that account permissions are sufficient, that policies will be accepted or that real HTTPS delivery works. Costs, latency and availability were not measured. Any deployment would require additional prerequisites and acceptance checks.
Before any deployment
A technical foundation still to verify
The lab documents how to turn requirements into Terraform resources and code checks. Local tests make the decisions reviewable while keeping the checks still needed before using the infrastructure explicit.
The author
Eddy Boscolo.
For over 17 years, I have worked with IT infrastructure. My work covers AWS and Azure architecture, Linux administration and automation with Terraform, Ansible, Docker and Kubernetes, alongside technical teams and project managers.
Based in Vicenza, I work with businesses across Veneto and remotely throughout Italy.