Official reference architecture and interactive hands-on lab suite developed for the MBA em DevOps Engineering at FIAP.
Covering Declarative Terraform, AWS Cloud Infrastructure, Remote State Management & Locking, Amazon EKS, Shift-Left CI/CD with GitHub Actions & Trivy, Multi-Host Configuration Management with Ansible, and Zero-Touch Hybrid Orchestration.
Modern enterprise infrastructure operations face the ClickOps & Configuration Drift Trap: managing cloud topologies manually through web consoles or ad-hoc shell scripts produces fragile, irreproducible "Snowflake Servers". Over time, unrecorded manual hotfixes and undocumented network adjustments lead to production downtime, compliance violations, and slow release cycles.
This repository establishes an end-to-end, production-grade Reference Architecture designed to transition engineering organizations from fragile manual setups to fully automated, auditable, and immutable Infrastructure as Code (IaC). By converging HashiCorp Terraform, Amazon Web Services (AWS), GitHub Actions DevSecOps pipelines, and Ansible configuration management, this blueprint demonstrates how enterprise teams provision and operate mission-critical cloud platforms deterministically.
- Declarative State-Driven Provisioning: Enforcing declarative infrastructure definitions where Terraform computes dependency DAGs (Directed Acyclic Graphs), tracks real-world state against code, and executes idempotent convergence.
- Modularization & Enterprise Composition: Eliminating duplicate configurations through reusable, parameter-driven root and child modules, leveraging advanced HCL metaprogramming (
dynamic blocks,for_each,count, anddata sources). - Shift-Left DevSecOps & Continuous Delivery: Integrating automated quality gates directly into GitHub Actions pull requests, executing linting (
tflint), formatting, vulnerability scanning (Trivy), and policy verification before cloud deployment. - Hybrid Configuration & Zero-Touch Orchestration: Establishing an automated bridge between declarative infrastructure provisioning (Terraform) and idempotent software configuration (Ansible), achieving end-to-end deployment without human terminal intervention.
| Stage | Architectural Phase | Domain Responsibility & Core Actions | Standards & Technology Stack | Production Guarantees & Deliverables |
|---|---|---|---|---|
| 0 | Local Simulation & Foundations (Labs 01, 02) | Introduction to declarative syntax, resource graph, and local provider emulation without cloud costs. | Terraform 1.9+, Local & Docker Providers | Verified local state lifecycle, random UUID generation, and containerized Nginx runtime |
| 1 | Cloud Compute & State Management (Labs 03, 04) | Initializing AWS provider, deploying elastic compute, and transitioning local state to remote S3 backend. | AWS EC2, Security Groups, S3 Remote State | Publicly reachable web instances and atomic remote state storage preventing state corruption |
| 2 | Modularization & Metaprogramming (Labs 05 to 10) | Refactoring monolithic configs into reusable VPC/EC2 modules, dynamic AMI discovery, and iterative collection expansion. | Reusable HCL Modules, Data Sources, count, for_each, dynamic blocks |
DRY modular infrastructure, multi-subnet topologies, and dynamic multi-port firewall rules |
| 3 | Lifecycle Hooks, Drift & Secrets (Labs 11 to 14) | Executing operational provisioners, reconciling unmanaged brownfield resources via import, and managing cryptographic secrets. | local-exec, remote-exec, terraform import, AWS Secrets Manager |
Automated bootstrap scripts, zero-downtime state import, and runtime credential injection |
| 4 | Cloud-Native Kubernetes & DevSecOps (Labs 15, 16) | Provisioning managed Kubernetes control planes with worker nodes, and automating delivery pipelines with shift-left security. | Amazon EKS, AWS IAM Roles, GitHub Actions, Trivy | Production EKS cluster on public subnets and automated CI/CD pipeline blocking vulnerabilities |
| 5 | Configuration Management & Zero-Touch (Labs 17, 18) | Multi-host server configuration, dynamic templating via Jinja2, and orchestrating Terraform output directly into Ansible playbooks. | Ansible Core, Jinja2 Templates, Hybrid Orchestration | Idempotent multi-tier software deployment and zero-touch end-to-end cloud provisioning |
The repository is structured into 18 self-contained, progressive hands-on laboratories:
| Module | Guides / Roteiros | Enterprise Pain Point | Technical Solution & Modern Stack | Key Deliverable & Artifact |
|---|---|---|---|---|
lab01-hello_world |
π§π· PT-BR | πΊπΈ EN | Understanding IaC core concepts without incurring cloud costs or complex credentials | Terraform declarative lifecycle (init, plan, apply, destroy) with local providers |
Idempotent local text file provisioned with dynamic random UUID |
lab02-docker_basics |
π§π· PT-BR | πΊπΈ EN | Managing local development runtime dependencies reproducibly | Docker provider integration with Terraform managing image pull and container ports | Functional containerized Nginx web server running via code |
lab03-simple_aws_ec2 |
π§π· PT-BR | πΊπΈ EN | FricΓ§Γ£o inicial de onboarding na nuvem e custos desnecessΓ‘rios em testes iniciais | AWS EC2 and Security Group provisioning with LocalStack emulation support | Live EC2 web server accessible on HTTP port 80 |
lab04-terraform_state |
π§π· PT-BR | πΊπΈ EN | Team collaboration conflicts and accidental state file deletion in local folders | Remote state backend architecture utilizing encrypted AWS S3 storage | Migrated terraform.tfstate backed by versioned remote object storage |
lab05-refactoring |
π§π· PT-BR | πΊπΈ EN | Spaghetti infrastructure codebases where changing one component breaks another | Root-and-child module refactoring isolating network (VPC) from compute (EC2) | Modular, reusable architecture consuming standardized child inputs and outputs |
lab06-datasource |
π§π· PT-BR | πΊπΈ EN | Hardcoded AMI IDs failing across different AWS regions and deprecation cycles | Dynamic querying using data "aws_ami" filters for official Amazon Linux AMIs |
Resilient compute declaration adapting automatically to latest patched AMI |
lab07-count |
π§π· PT-BR | πΊπΈ EN | Code duplication when provisioning multiple identical infrastructure resources | Metaprogramming with count and index-based naming conventions |
Scaled array of instances managed via a single declarative resource block |
lab08-foreach |
π§π· PT-BR | πΊπΈ EN | Accidental recreation cascades caused by index shifts in count lists |
Key-based iteration using for_each over mapped resource definitions |
Robust resource collection keyed by domain tags without destructive index shifts |
lab09-for |
π§π· PT-BR | πΊπΈ EN | Inflexible output contracts and inability to transform lists into lookup maps | HCL for expressions, list comprehensions, and map transformations |
Exported map of server names paired with public IP addresses |
lab10-dynamic_blocks |
π§π· PT-BR | πΊπΈ EN | Bloated and repetitive security group ingress rules across enterprise ports | dynamic "ingress" blocks iterating over structured port and protocol lists |
DRY firewall configuration managing multi-port ingress dynamically |
lab11-localexec |
π§π· PT-BR | πΊπΈ EN | Manual synchronization between provisioned cloud outputs and local deployment tools | Client-side execution via local-exec provisioners and template files |
Automatically populated local inventory and IP manifest upon resource creation |
lab12-remoteexec |
π§π· PT-BR | πΊπΈ EN | Post-boot server initialization requiring manual SSH login and command execution | In-line post-provisioning with remote-exec over secure SSH connections |
Fully configured application web server serving dynamic instance metadata |
lab13-import |
π§π· PT-BR | πΊπΈ EN | Brownfield cloud resources created manually without IaC management | Reconciling existing cloud assets into Terraform state via terraform import |
Brownfield EC2 adopted into code with 0 drift on subsequent plans |
lab14-secrets |
π§π· PT-BR | πΊπΈ EN | Hardcoded API tokens and database credentials committed to public Git repos | Secrets management integration with AWS Secrets Manager and dynamic retrieval | Secure credential consumption without plain-text exposure in version control |
lab15-eks |
π§π· PT-BR | πΊπΈ EN | High complexity of provisioning production Kubernetes control planes and nodes | Amazon EKS cluster architecture with managed Node Groups on optimized subnets | Enterprise-ready Kubernetes cluster ready for containerized workloads |
lab16-cicd |
π§π· PT-BR | πΊπΈ EN | High-risk manual deployments from developer laptops without security audits | GitHub Actions pipeline integrating fmt, validate, Trivy, and automated deploy |
Automated Quality Gate enforcing static analysis and zero-vulnerability standards |
lab17-ansible |
π§π· PT-BR | πΊπΈ EN | Imperative bash scripts failing silently and lacking configuration idempotency | Multi-host configuration management with Ansible playbooks and Jinja2 templates | Idempotent multi-tier configuration deploying web services across hosts |
lab18-zero-touch |
π§π· PT-BR | πΊπΈ EN | Disconnected silos between cloud infrastructure provisioning and app configuration | Zero-touch orchestration binding Terraform outputs directly into Ansible automation | Unified pipeline: single execution provisions cloud hardware and configures services |
Click the button below to launch a fully configured Linux cloud container with Terraform 1.9+, AWS CLI v2, Docker, Ansible, and TFLint pre-installed:
Once Codespaces is ready:
# 1. Navigate to the desired laboratory (e.g. Lab 01)
cd lab01-hello_world
# 2. Follow the guided instructions in your preferred language
cat "Lab 01 - Student Guide.md" # πΊπΈ English Guide
# or: cat "Lab 01 - Roteiro Aluno.md" # π§π· Portuguese Guide
# 3. Initialize and apply Terraform
terraform init
terraform applyPrerequisites: Terraform 1.9+, AWS CLI v2, Docker & Docker Compose, Ansible Core 2.16+, Git.
# Clone the repository
git clone https://github.com/rafaelmatsuyama/FIAP-DevOps-InfrastructureAsCode.git
cd FIAP-DevOps-InfrastructureAsCode
# Configure AWS Credentials
aws configure| Feature / Scenario | AWS Academy Learner Lab | LocalStack (Emulation) | AWS Commercial Account |
|---|---|---|---|
| Basic Compute & VPC (Labs 01-14) | Full Support (us-east-1) |
Full Support (Docker) | Full Support (Any Region) |
| Amazon EKS (Lab 15) | Supported on Public Subnets | Requires LocalStack Pro | Full Support (Public & Private) |
| Secrets Manager (Lab 14) | Full Support | Requires LocalStack Pro | Full Support |
| CI/CD via GitHub Actions (Lab 16) | Supported via Session Tokens | Local Runner | Full Support (OIDC / IAM Roles) |
| Ansible Zero-Touch (Labs 17-18) | Full Support (SSH on EC2) | Supported via Containers | Full Support |
This reference architecture incorporates essential engineering practices learned from enterprise cloud operations:
- Remote State Integrity & Concurrency Control:
Storing state locally creates an immediate risk of concurrent overwrites and credential leaks. Production deployments configure an encrypted AWS S3 bucket with versioning enabled alongside a DynamoDB table for distributed state locking (dynamodb_table), preventing corrupted state files during simultaneous pipeline executions. - Deterministic AMI Resolution vs. Version Pinning:
Whiledata "aws_ami"filters automate the discovery of the latest official Amazon Linux release, enterprise production workloads pin specific AMI release IDs or consume validated Golden Images from private EC2 Image Builder pipelines to prevent untested upstream kernel changes from destabilizing production workloads. - Kubernetes Control Plane vs. Node Group Networking:
In constrained cloud environments (such as AWS Academy), allocating EKS worker node groups in private subnets without an active NAT Gateway causes node registration timeouts. Production clusters route worker nodes through properly configured NAT Gateways or place public endpoints with strict security group ingress rules. - Zero-Touch Provisioning and Idempotent Configuration:
Combining Terraform and Ansible creates a clear separation of concerns: Terraform acts as the declarative hardware provisioner, while Ansible acts as the idempotent software configurer. Passing dynamically computed IP outputs from Terraform directly into an Ansible template inventory eliminates fragile hardcoded IP addresses. - Shift-Left Security & Vulnerability Scanning:
Every infrastructure commit must pass automated verification in CI/CD before hitting production. Executingtflintdetects invalid AWS resource configurations statically, whileTrivyaudits HCL manifests for misconfigurations (such as open0.0.0.0/0security groups) before executingterraform apply.
This framework and comprehensive laboratory suite were architected, refined, and battle-tested by Rafael Matsuyama as part of the Infrastructure as Code (IaC) curriculum for the Executive MBA in DevOps Engineering at FIAP (SΓ£o Paulo, Brazil).
Senior DevOps engineers, Site Reliability Engineers (SREs), cloud architects, and tech leaders across enterprise cohorts have executed, validated, and stress-tested these scenarios, providing continuous feedback to ensure that every laboratory reflects real-world corporate cloud engineering workloads.
This repository follows a strict Calendar Versioning with Cycle and Patch semantics (CalVer) (vYYYY.CYCLE.PATCH) to balance enterprise technical stability with annual executive curriculum delivery:
v2026 . 1 . 0
β β β
β β βββ PATCH: Hotfixes, dependency bumps & documentation errata
β βββββββ CYCLE: Major content iterations or new lab modules
βββββββββββββ YEAR: Annual technology stack baseline & MBA curriculum edition
- Deterministic Reproducibility: Each tagged release provides an immutable snapshot where all manifests, playbooks, guides, and CI/CD pipelines are verified to run deterministically.
- Academic Cohort Pinning: Students or corporate teams standardizing on past editions can pin their environment directly to the official release tag:
git checkout tags/v2026.1.0
- All milestone releases and automated release notes are available on the official GitHub Releases page.
Rafael Matsuyama
Solutions Architect & DevOps Engineering Specialist
Engineering graduate from Escola PolitΓ©cnica da Universidade de SΓ£o Paulo (Poli-USP) with over two decades of experience across Cloud Architecture, Distributed Systems, Mission-Critical Platforms, and Academic Leadership.
- π LinkedIn: linkedin.com/in/rafaelmatsuyama
- π GitHub: github.com/rafaelmatsuyama
This repository employs a dual-licensing structure to encourage enterprise adoption of the codebase while protecting educational materials from unauthorized commercial resale:
- π» Code, Manifests & Playbooks (
*.tf,*.hcl,*.yml,*.py,*.sh): Licensed under the Apache 2.0 License. Permissive and free to be used, adapted, and integrated into enterprise production environments. - π Educational Content & Manuals (
*.mdlab guides, guides, diagrams): Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0). Free for personal learning, study, and educational reference; commercial reproduction, selling, or course packaging by third parties is strictly prohibited.

