initial

NOTES.md

@@ -0,0 +1,23 @@
+* Changes to terraform/ansible*
+I noticed an extra set of brackets that VS Code didn't flag. Running a quick terraform validate catches small syntax issues like this before they cause deployment errors.
+
+In main.tf, I scoped cidr_blocks down from 0.0.0.0/0 to a sample subnet (180.191.0.0/16). While still somewhat broad to accommodate dynamic ISP leases that reset every 48 hours, it significantly reduces the initial attack surface.
+
+Alternative Access & Security Models
+Rather than leaving SSH exposed, the best practice—even for small instances—is to remove port 22 from the security group entirely. A few options to consider:
+
+Tailscale / Headscale (Recommended): Uses Tailscale SSH to manage access securely. Users authenticate via Identity Providers (IdPs) like Google or GitHub, while Headscale handles key rotations, ACLs, and permissions. I personally use this setup in production for small cloud workloads; it provides excellent ACL control and a clean management interface.
+
+AWS SSM Session Manager: Allows secure CLI and console access via the AWS agent without open inbound ports, though executing local tools like Ansible internally requires additional setup.
+
+Cloudflare Tunnels: Useful for routing developer traffic directly to the instance without exposing public IPs, especially in environments requiring DNS over tunnels.
+
+I prefer the Tailscale/Headscale combination as a modern, manageable solution that keeps port 22 completely closed to the internet.
+
+Handling Port 80 Ingress
+I added port 80 to the ingress rules to support standard HTTP traffic. While this opens a public surface area, network risks can easily be mitigated at the Linux OS level (e.g., hardening TCP kernel parameters against SYN floods). In practice, Nginx will use port 80 primarily to issue 301 permanent redirects to HTTPS (port 443).
+
+
+*Scenario Response: TinyCommerce App Intermittent Health Check Failures*
+Part 3 — Incident note (~30 min, written)
+A Scenario response for the TinyCommerce app with intermittent health check failures. Detection relies on baseline health check monitoring. The issue would likely present as a 5xx HTTP error specifically a 502 Bad Gateway indicating an application-level problem within the TinyCommerce app. Assuming the application has a reliable deployment pipeline, I would start by investigating the error logs. For example, if the app crashes whenever it attempts a file write, I would check system monitoring and host logs for clear indicators like disk space exhaustion. On small instances, unrotated application logs, Docker container logs, or bloated volumes are almost always the root cause of disk exhaustion and subsequent crashes.