[ 3+ YRS EXP // CLOUD BUILDER // MANILA, PH ]

Crafting the Cloud,
Making Systems Resilient

I'm Marielle Lois Bahuyo, a cloud engineer and computer engineering student dedicated to serverless architectures, DevOps automation, and intelligent pipelines.

Get in Touch [ Explore Projects ]
  • 6case studies
  • AWScloud focused
  • 3+years building
Marielle Lois P. Bahuyo
[ Cloud ]
[ DevOps ]
[ AI ]
[ Web ]
WebCloudDevOpsAWS TerraformDockerKubernetesHelm GitLab CIArgoCDLaravelPHP MySQLJavaScriptPythonGit
[ 01 // ARCHITECTURE & REPOSITORIES ]

Selected Work

Production cloud architectures, GitOps pipelines, serverless workflows, and full-stack systems.

Completed Oct 2026
Highly available multi-tier AWS architecture across two Availability Zones Terraform • Multi-AZ AWS Architecture
Academic Capstone Oct 2026

Highly Available Multi-Tier AWS Architecture

v1.0.0

Engineered a secure, scalable, and fault-tolerant AWS environment across two Availability Zones using Terraform.

Terraform AWS ALB VPC
Updated 1 week ago
GitOps workflow from source commit through GitLab CI, container registry, ArgoCD, and Kubernetes GitLab CI → ArgoCD → Kubernetes
★ 3 Stars Aug 24, 2026

GitOps CI/CD Pipeline

v2.1.0

Implemented automated continuous delivery for containerized services using Helm manifests, GitLab CI automation, and ArgoCD Kubernetes synchronization.

Kubernetes ArgoCD GitLab CI Helm
Completed • 2026
Serverless Service Appointment System interface delivered through CloudFront CloudFront • Lambda • RDS • DynamoDB
Cloud-Native Full Stack Sep 05, 2026

Serverless Service Appointment System

v1.4.0

Built a full-stack appointment experience using CloudFront, API Gateway, Lambda, RDS, and DynamoDB for globally distributed service booking.

Lambda RDS DynamoDB CloudFront
Learning Prototype • 50 min
AI Workflow Oct 10, 2026

Automate Your Calendar with AI

v1.0.0

Built an n8n AI workflow that interprets natural-language meeting requests and creates Google Calendar events with dynamic dates, times, and prompt-based constraints.

n8n GPT-4o mini Google Calendar AI Agent
OJT Project • 2026
Maye Store Laravel authentication interface Laravel • MySQL • Staff Authentication
OJT Application May 18, 2026

Maye Store Inventory & User Management

v2.0.0

Built during OJT to manage store inventory, staff registration, authentication, and automated welcome emails through a Laravel and MySQL workflow.

Laravel PHP MySQL Mailtrap
Thesis • July 2026
Academic Thesis Jul 2026

SmartH2wo

IoT + ML

A smart water-dispenser platform combining ESP32 hardware, dual payments, real-time monitoring, and machine-learning-assisted maintenance.

React FastAPI ESP32 ML
~/projects/aws-multi-tier/case-study
Academic Capstone • October 2026

Highly Available Multi-Tier AWS Web Architecture

A secure, scalable, and fault-tolerant cloud infrastructure provisioned with Terraform to host a full-stack application across multiple Availability Zones.

TerraformAWSEC2ALBNLBAuto Scaling
Status
Completed & tested
Role
Cloud Architect & Engineer
Context
Stratpoint Capstone
Deployment
Destroyed after testing to control cost
AWS multi-tier architecture showing an internet gateway, application and network load balancers, frontend and backend Auto Scaling Groups across two Availability Zones, a NAT Gateway, a Bastion Host, S3, and CloudWatch.
Cost-optimized capstone topology. The backend instances belong inside the private subnet boundaries; their position here is a diagram layout artifact.
01

System design

Request flow

  1. 01
    Traffic enters AWS

    User requests enter the VPC through the Internet Gateway and reach the public-facing Application Load Balancer.

  2. 02
    Frontend tier scales

    The ALB performs health checks and distributes traffic to Apache frontend EC2 instances in private subnets across AZ-A and AZ-B.

  3. 03
    API traffic stays private

    The React interface sends internal API requests through a Network Load Balancer to backend Auto Scaling instances.

  4. 04
    Services and telemetry

    Backend services return JSON responses, S3 stores static assets and remote Terraform state, and CloudWatch collects health, CPU, and server logs.

Security model

Private by default

  • Frontend and backend instances have no public IP addresses.
  • The frontend security group accepts application traffic only from the ALB.
  • The backend security group accepts traffic only from approved frontend and NLB paths.
  • SSH access is restricted to a known IP and uses ProxyJump through the Bastion Host.
  • IAM instance profiles avoid hardcoded AWS credentials.
Reliability model

Designed for failure

  • Compute capacity is distributed across two Availability Zones.
  • ALB health checks route requests only to responsive frontend targets.
  • Auto Scaling adds capacity when CPU utilization exceeds 70%.
  • If one AZ fails, load balancers route traffic to healthy instances in the other AZ.
  • CloudWatch provides health, utilization, and log visibility.
02

Engineering deep dive

Debugging a failed scale-out

INCIDENT

The ALB routed traffic to a newly scaled frontend instance at 10.0.4.240, but the instance returned a 404 because its /var/www/html directory was empty.

DIAGNOSIS

I used Git Bash and SSH ProxyJump through the Bastion Host to reach the private instance and verify the missing deployment files.

RESOLUTION

I corrected the Terraform user_data boot script so every new instance initializes with the expected application code.

Outcome

High availability verified

The ALB balanced web traffic successfully, and the private backend returned valid cross-subnet API payloads. After validation, I used terraform destroy to prevent recurring AWS charges.

$ terraform apply -var-file="prod.tfvars" Health checks: passing Cross-AZ routing: verified Architecture validation complete.
Cost-aware trade-off

One NAT Gateway in AZ-B and one Bastion Host in AZ-A were intentional capstone cost controls. A production deployment would place a NAT Gateway in each AZ for complete redundancy.

Next iteration

Replace raw EC2 boot scripts with Docker containers to make scaled instances consistent and deployments more repeatable.

Built independently with Terraform • AWS • Linux • Apache • Git
~/devops/gitops/cicd-pipeline
Cloud & DevOps Engineering • August 2026

GitOps CI/CD Pipeline

An automated delivery workflow for containerized services that connects GitLab CI, versioned Helm configuration, ArgoCD, and Kubernetes.

GitLab CIHelmArgoCDKubernetesContainer Registry
Context
Cloud & DevOps internship
CI
GitLab CI pipeline
CD
ArgoCD synchronization
Target
Kubernetes cluster
01

Implementation map

One commit, one traceable delivery path

gitops-cicd-implementation.svg WORKFLOW
GitOps workflow showing a developer commit entering GitLab CI, publishing an image to a container registry, updating a Helm manifest repository, and synchronizing to Kubernetes through ArgoCD
The implementation separates application artifacts from deployment state, then lets ArgoCD reconcile the versioned Helm configuration with Kubernetes.
VERSIONEDCode and manifests

Application changes and deployment configuration remain visible and reviewable in Git.

AUTOMATED CIBuild, test, and publish

GitLab CI validates the change and publishes the container artifact to the registry.

DECLARATIVE CDDesired state synchronized

ArgoCD detects the manifest update and reconciles it with the Kubernetes cluster.

02

Delivery design

From source change to cluster state

SOURCEDeveloper & repository

A committed change starts the automated pipeline.

CONTINUOUS INTEGRATIONGitLab CI

Builds, tests, and publishes the container image.

DESIRED STATERegistry & Helm repo

Stores the image and its versioned deployment values.

CONTINUOUS DELIVERYArgoCD & Kubernetes

Synchronizes and deploys the declared release.

Continuous integration

Automated artifact delivery

  • A source commit triggers the GitLab CI workflow.
  • The pipeline builds and tests the containerized service.
  • A successful build is pushed to the container registry.
  • The release reference is carried into versioned Helm configuration.
Continuous delivery

Git as deployment truth

  • The manifest repository records the intended cluster state.
  • ArgoCD watches the repository for configuration changes.
  • Synchronization applies the Helm-defined release to Kubernetes.
  • The separation keeps cluster deployment changes traceable in Git.
Implementation result

A repeatable GitOps delivery path

The implemented workflow connects code changes to versioned deployment configuration and ArgoCD synchronization, reducing manual cluster changes and making the intended state visible in Git.

$ git push origin main GitLab CI: build • test • push ArgoCD: manifest change detected Kubernetes: desired state synchronized
Separation of concerns

The container registry stores runnable artifacts, while the manifest repository stores the declarative configuration used for deployment.

GitOps principle

ArgoCD pulls the desired state from Git and reconciles the cluster instead of relying on direct, untracked production changes.

Implemented with GitLab CI • Helm • ArgoCD • Kubernetes
~/thesis/smarth2wo/full-stack-iot-system
Academic Thesis • July 2026

SmartH2wo

An intelligent water-dispenser management system connecting an ESP32-based physical device to a full-stack monitoring platform, dual payment flows, and machine-learning-assisted maintenance.

ReactViteFastAPIPythonSupabaseMQTTESP32
Role
Full-Stack Developer & Machine Learning
Hardware
Arduino-compatible platform & ESP32
Payments
QR PH through PayMongo + coins
Context
PUP Institute of Technology thesis
01

Operational interface

One dashboard for the connected dispenser

dash.smarth2wo.tech/dashboard LIVE SYSTEM VIEW
SmartH2wo dashboard showing water level, bottles saved, revenue, maintenance prediction, system alerts, and water-level history
The implemented dashboard brings device health, operational metrics, revenue, maintenance information, and alerts into a single responsive view.
FULL STACKConnected monitoring

React consumes FastAPI and Supabase data to display transactions, sensor state, analytics, and logs.

DUAL PAYMENTQR and coin accepted

The prototype supports PayMongo QR PH checkout and physical coin-based dispensing.

SURVEY EVALUATEDPositive accuracy assessment

Respondents evaluated the system as accurate; no unsupported numerical score is claimed.

02

System design

From payment to monitored dispensing

01User input

The customer selects a water volume and chooses QR PH or coin payment.

02Payment validation

PayMongo confirms QR checkout while the hardware validates coin input.

03ESP32 control

MQTT connects backend commands and device status to the physical dispenser.

04Cloud records

Supabase stores transactions, logs, user profiles, and sensor history for the dashboard.

My contribution

Full-stack engineering

  • Built across the React/Vite frontend and Python FastAPI backend.
  • Connected operational views to Supabase data and authentication.
  • Supported payment, transaction, sensor, and device-management workflows.
  • Collaborated on integrating the software with the ESP32-based prototype.
My contribution

Machine-learning pipeline

  • Implemented predictive-maintenance and anomaly-detection modules.
  • Used Random Forest models and Isolation Forest for sensor analysis.
  • Exposed inference through FastAPI endpoints for dashboard consumption.
  • Kept rule-based fallback behavior when trained model files are unavailable.
Engineering challenge

Separating hardware faults from software faults

During integration, COM-port and incorrect hardware connections interrupted device communication. The team traced the issue to the physical connection path while the application and backend workflow continued to operate correctly.

$ verify device integration Frontend + API: operational Fault domain: port / wiring connection Software workflow validated.
Responsible ML claim

The models were developed as part of the thesis prototype and supported by positive survey evaluation. A numerical accuracy percentage is intentionally omitted because it was not available for verification.

Hardware scope

Arduino-compatible development and ESP32 are documented as the hardware platform. Specific sensor models are not listed until they can be confirmed.

Thesis stack React • Vite • FastAPI • Supabase • MQTT • ESP32 • scikit-learn
View GitHub
~/projects/serverless-appointments/case-study
Cloud-Native Full Stack • 2026

Serverless Service Appointment System

A globally distributed appointment application that loads a live service catalog and records customer bookings through a scalable AWS backend.

CloudFrontS3API GatewayLambdaRDS MySQLDynamoDB
Status
Completed & verified
Frontend
HTML, CSS & Vanilla JavaScript
Runtime
Node.js on AWS Lambda
Pattern
Serverless API + polyglot persistence
01

Product experience

Services loaded from the cloud

https://d3….cloudfront.net HTTPS
Deployed Service Appointment System showing General Consultation, IT Support Session, and Network Advising service cards
Deployed through Amazon CloudFront: service cards are loaded dynamically from the cloud-backed catalog.
201 CREATEDAPI request accepted

The browser successfully posted the appointment to the cloud backend.

RDS / MYSQLCatalog retrieved

Service titles, descriptions, IDs, and durations were returned from relational storage.

DYNAMODBBooking persisted

The customer transaction appeared in the appointments table after submission.

02

System design

Request lifecycle

EDGECloudFront

Delivers the application globally over HTTPS.

STATICAmazon S3

Hosts the HTML, CSS, and JavaScript frontend.

APIAPI Gateway

Receives REST requests from the browser.

COMPUTELambda

Runs Node.js booking and catalog logic.

RELATIONAL READSAmazon RDS / MySQL

Structured source of truth for the professional service catalog.

TRANSACTION WRITESAmazon DynamoDB

Fast NoSQL persistence for client records and appointment logs.

OBSERVABILITYAmazon CloudWatch

Captures Lambda execution logs and runtime errors.

Architecture decision

Polyglot persistence

  • MySQL models the structured service catalog and its consistent fields.
  • DynamoDB handles appointment transactions and client activity at low latency.
  • Each datastore is matched to the shape and access pattern of its data.
  • Lambda environment variables keep database configuration outside application code.
Delivery & operations

Managed AWS services

  • CloudFront provides HTTPS delivery and low-latency edge distribution.
  • API Gateway separates the browser client from backend implementation details.
  • Lambda scales compute on demand without a continuously running application server.
  • CloudWatch centralizes execution logs and supports real-time error investigation.
Verified result

One booking, two data models

The deployed frontend retrieved its service catalog from MySQL, submitted a booking through the REST API, received a successful 201 Created response, and persisted the resulting client transaction in DynamoDB.

$ POST /appointments API Gateway → Lambda (Node.js) DynamoDB: PutItem succeeded HTTP/1.1 201 Created
Key learning

Built confidence connecting a static frontend to managed APIs, configuring Lambda layers and environment variables, and operating relational and NoSQL databases together.

Proof protected

The original database screenshots were used for verification but are not published here because they contain personal client and appointment data.

Built with HTML • CSS • JavaScript • Node.js • AWS
~/projects/maye-store/case-study
On-the-Job Training Project • 2026

Maye Store Inventory & User Management System

A Laravel application created during my OJT at Customer Frontline Solutions to manage store inventory and automate staff account onboarding through email notifications.

Laravel 11PHPMySQLBladeMailtrapVite
Context
Customer Frontline Solutions OJT
Type
Full-stack web application
Backend
Laravel 11 & PHP
Database
MySQL
01

Product experience

Controlled staff onboarding

127.0.0.1:8000/login LARAVEL APP
Maye Store Laravel login page with email and password fields
The implemented authentication entry point protects inventory and staff-management workflows before users reach the dashboard.
AUTH READYSecure account flow

Login and registration provide controlled access to the application.

MYSQLInventory persisted

Product and user records are managed through Laravel models and migrations.

SMTP DELIVEREDWelcome email verified

Mailtrap confirms that the onboarding message is generated and delivered successfully.

02

Application design

Request and notification flow

01Authenticated request

A user signs in and accesses inventory or staff-management actions.

02Laravel application

Routes, middleware, controllers, validation, and Blade views handle the request.

03MySQL persistence

Eloquent models read and write user and inventory records.

04SMTP notification

A successful registration triggers a welcome email tested through Mailtrap.

Core capabilities

Store operations

  • Real-time product inventory tracking through a centralized dashboard.
  • Authenticated login and registration workflows for application users.
  • Staff account creation with selectable system roles.
  • Custom Blade templates for dashboard, registration, and email views.
Engineering workflow

Laravel foundations

  • Laravel migrations provide a repeatable MySQL schema setup.
  • Mailtrap supplies a safe sandbox for SMTP testing during development.
  • Vite bundles application CSS and JavaScript assets.
  • Git and GitHub track source changes and support project setup.
Implementation result

Registration through delivery

The completed workflow creates a staff account, persists the user in MySQL, and sends a personalized welcome message to the Mailtrap sandbox while keeping the dashboard and email presentation consistent through custom Blade templates.

$ composer install && npm install $ php artisan migrate $ npm run build $ php artisan serve
Development lesson

Connected authentication, relational data, server-rendered interfaces, asset bundling, and transactional email in one maintainable Laravel workflow.

Proof protected

The original Mailtrap screenshot is not published because it displays personal email addresses and SMTP account information.

Source code Laravel 11 • PHP • MySQL • Blade • Mailtrap • Vite
View GitHub
~/projects/ai-calendar-automation/case-study
AI Workflow Prototype • 2026

Automate Your Calendar with AI

A focused n8n learning project that turns conversational scheduling requests into verified Google Calendar events through an OpenAI-powered agent.

n8nGPT-4o miniAI AgentGoogle CalendarDynamic Expressions
Scope
Learning prototype
Build time
Approximately 50 minutes
Trigger
n8n chat message
Result
Calendar event verified
01

Workflow design

Conversation becomes an action

AI CALENDAR WORKFLOWTESTED
TRIGGER When chat message received Natural-language request
AGENT Calendar AI Agent Interprets intent and selects a tool
RESULT Event confirmation Booking returned to chat
CHAT MODELGPT-4o mini

Understands the request and prepares the scheduling action.

INSTRUCTIONSSystem message

Provides timezone, personality, availability rules, and booking constraints.

TOOLGoogle Calendar

Checks availability and creates the event with authorized access.

02

Execution path

From message to meeting

  1. 01
    Receive intent

    The n8n chat trigger captures a request such as “Book a meeting today at 4 PM.”

  2. 02
    Interpret context

    GPT-4o mini reads the message alongside the system instructions and current timezone.

  3. 03
    Resolve timing

    Dynamic expressions pass changing start and end times into the calendar operation.

  4. 04
    Create and verify

    The agent uses the Google Calendar tool, then the resulting event is checked in the calendar.

n8n CHATEXECUTION SUCCESS
YOU

Book a meeting today at 4:00 PM.

AI AGENT

Your meeting has been added to Google Calendar for 4:00 PM.

CALENDAR / TODAY
Scheduled Meeting

Created by the n8n AI workflow

EVENT VERIFIED
Prompt engineering

Behavior through instructions

  • Added the current date, time, and timezone through expression mode.
  • Changed the assistant from generic language to a more upbeat, detailed personality.
  • Experimented with custom scheduling constraints based on selected days and minute values.
  • Observed how system-message changes directly affected the agent’s response and actions.
Integration & safety

Authorized calendar access

  • Connected n8n to Google Calendar with permission to view and edit events.
  • Used the calendar integration as an explicit agent tool rather than free-form output.
  • Validated success by checking the created event in Google Calendar.
  • Kept API credentials, OAuth details, session IDs, and calendar data out of the portfolio.
Challenge & result

Getting the agent to book—not just respond

The hardest part was moving from a conversational answer to a real calendar action. Connecting the agent to the Google Calendar tool, passing dynamic times, and tightening the system message produced a workflow that created the requested 4 PM event successfully.

> Book a meeting today at 4:00 PM Intent parsed • timezone applied Google Calendar tool executed Event created successfully.
What I learned

Built practical understanding of n8n triggers, agent tools, dynamic expressions, system messages, and how prompt instructions shape automation behavior.

Next exploration

Extend the workflow with stronger availability validation and explore visual agent-building tools such as Langflow or OpenClaw.

Prototype stack n8n • GPT-4o mini • Google Calendar • Dynamic Expressions
[ 02 // COMMUNITY LEADERSHIP ]

Community Impact

Developer community leadership, technical mentorship, and cloud workshop initiatives.

BuildHers+ PH
BuildHers+ PH Mentee & Speaker • Cohort Fellow
AWS Cloud Club PUP
AWS Cloud Club PUP Operations Team • Cloud Builder
GDG on Campus PUP Project Management Associate
KIRO AI Night
KIRO AI Night Modern Agentic IDEs Participant
[ 03 // CAREER ROADMAP ]

Work Experiences

Progressive engineering roles across cloud infrastructure, DevOps pipelines, and full-stack software.

01 Work Experience

02 Organizations & Leadership

[ 04 // CREDENTIALS & ACHIEVEMENTS ]

All Certificates

Hackathon recognition, technical certifications, and specialized engineering workshop completions.

[ 05 // ENGINEERING NOTES ]

Dev Notes

Engineering decisions, implementation lessons, and trade-offs documented from projects I built.

$ php artisan test --filter=ReportTest PASS 24 tests • 0 warnings • Audit trail OK
Backend • 8 min read

Building an Audit-Ready Reporting System in Laravel

How I separated report requests from PDF generation, protected sensitive data, and tested the workflow from request to delivery.

$ aws lambda invoke --function-name api StatusCode: 200 • Lambda OK • RDS/MySQL connected
Serverless • 6 min read

Building a Serverless Appointment API on AWS

What I learned connecting API Gateway and Lambda to an RDS-backed service catalog—and why each boundary matters.

$ terraform plan -out=tfplan Plan: 12 to add, 0 to change, 0 to destroy.
DevOps • 7 min read

Terraform Lessons from a Multi-Tier AWS Build

Turning a multi-tier architecture into repeatable infrastructure, then debugging the boot script that kept new instances from becoming healthy.

~/dev-notes/laravel-reporting.md
Backend • 8 min read

Building an Audit-Ready Reporting System in Laravel

How I designed a traceable reporting workflow around validation, queued PDF generation, protected data, and automated tests.

LaravelPHPMySQLQueuesPDF
01

The challenge

Reporting without blocking the request

A report request touches validation, database records, PDF rendering, and email delivery. Keeping all of that inside one HTTP request would make the interface slower and failures harder to recover from. I separated the user-facing request from the heavier generation work.

Request path

Validate and record

  • Validate the incoming title and report payload.
  • Persist the report before starting background work.
  • Record who initiated the action and what changed.
  • Return an accepted response while processing continues.
Worker path

Generate and deliver

  • Load the saved report inside a queued job.
  • Render a consistent PDF from a server-side template.
  • Store the generated file in a controlled location.
  • Notify the intended recipient when it is ready.
02

Validation

Test behavior, not just output

The useful tests cover the whole handoff: unauthorized requests are rejected, valid input creates the expected records, the audit entry belongs to the correct user, and the PDF job is queued with the correct report identifier.

$ php artisan test --filter=ReportTestAuthorization: verifiedAudit trail: recordedReport workflow passes.
Takeaway

Traceability is a workflow decision

An audit-ready feature is not created by adding a log at the end. Identity, validation, state changes, background jobs, and delivery all need a clear chain that can be tested and explained.
~/dev-notes/serverless-appointment-api.md
AWS • 6 min read

Building a Serverless Appointment API on AWS

What I learned connecting API Gateway and Lambda to an RDS-backed service catalog—and why each boundary matters.

API GatewayLambdaRDSMySQLCloudFront
01

Architecture

A small API with clear boundaries

CloudFront delivers the frontend. Requests enter through API Gateway, which invokes Lambda to retrieve service names, descriptions, durations, and identifiers from RDS MySQL. Each component owns one part of the request path.

  1. 01
    Deliver

    CloudFront serves the interface close to the visitor.

  2. 02
    Route

    API Gateway provides the public HTTP contract.

  3. 03
    Execute

    Lambda validates and handles the request.

  4. 04
    Retrieve

    RDS MySQL returns relational service data.

02

Engineering lesson

The connection is the system

NETWORK

Lambda needs the correct network path and security-group rules to reach the database.

CONFIG

Credentials and environment values must remain outside application code.

CONTRACT

The response shape must match what the frontend expects, including failure states.

Takeaway

Serverless still requires systems thinking

Managed services reduce server maintenance, but reliability still depends on secure connectivity, observable requests, least-privilege access, and well-defined interfaces.

$ aws lambda invoke --function-name apiAPI Gateway: reachableRDS/MySQL: connectedService catalog returned.
~/dev-notes/terraform-lessons.md
Terraform • 7 min read

Terraform Lessons from a Multi-Tier AWS Build

Turning a multi-tier design into repeatable infrastructure, then debugging the boot script that kept new instances from becoming healthy.

TerraformAWSEC2Auto ScalingCloudWatch
01

Approach

Model boundaries before resources

I separated networking, access, compute, and observability concerns before writing individual resources. This made dependencies visible: subnets depend on the VPC, routes depend on gateways, and compute depends on networking and security rules.

Repeatability

Make patterns explicit

  • Use variables for values that change by environment.
  • Keep naming predictable across Availability Zones.
  • Review plans for unexpected replacements.
  • Apply the smallest meaningful change.
Operations

Validate the running system

  • Inspect boot and application logs.
  • Check load-balancer target health.
  • Verify cross-subnet responses.
  • Destroy temporary infrastructure after testing.
02

Debugging

A successful apply, but an unhealthy target

SYMPTOM

Terraform completed and EC2 launched, but a newly scaled frontend returned a 404.

CAUSE

The instance boot script did not place the application files in the expected web directory.

FIX

I corrected user_data so every new instance initialized with the same application state.

Takeaway

Repeatable is not automatically reliable

Terraform can reproduce infrastructure, but operational checks prove whether the application actually boots, registers, responds, and recovers as designed.

$ terraform plan -out=tfplanFormat: cleanValidation: passedThen verify the workload.
[ 06 // SYSTEM PROFILE ]

About Me

Computer Engineering Technology student at the Polytechnic University of the Philippines.

Specializing in cloud-native architecture, container orchestration, and AI-powered workflow automation. Through active leadership roles in AWS Cloud Club PUP, GDG on Campus, and BuildHers+ PH, I am committed to building production-grade serverless platforms and empowering the next generation of engineers through hands-on technical workshops.