From b22edd72e7016ceed1ea04494c62d20f90798487 Mon Sep 17 00:00:00 2001 From: Ashutosh ojha Date: Wed, 11 Feb 2026 13:41:25 +0530 Subject: [PATCH 1/2] Test pull request - ashutoshojha18 --- 02-git/01-git-fork-vs-git clone.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/02-git/01-git-fork-vs-git clone.md b/02-git/01-git-fork-vs-git clone.md index 7341abdf..ac6c28f3 100644 --- a/02-git/01-git-fork-vs-git clone.md +++ b/02-git/01-git-fork-vs-git clone.md @@ -25,4 +25,4 @@ Here’s how you’d typically use both: > So: **Fork = GitHub-level action**, **Clone = Local machine-level action**. - + From 3a583eeeb1a62d96f2fa42d577b28eace465c814 Mon Sep 17 00:00:00 2001 From: Ashutosh ojha Date: Sun, 14 Jun 2026 17:03:52 +0530 Subject: [PATCH 2/2] 03-Have you considered storing statefile in git instead of aws s3? 03-Have you considered storing statefile in git instead of aws s3? --- ...toring statefile in git instead of aws s3? | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 06-terraform/03-Have you considered storing statefile in git instead of aws s3? diff --git a/06-terraform/03-Have you considered storing statefile in git instead of aws s3? b/06-terraform/03-Have you considered storing statefile in git instead of aws s3? new file mode 100644 index 00000000..79edce7f --- /dev/null +++ b/06-terraform/03-Have you considered storing statefile in git instead of aws s3? @@ -0,0 +1,23 @@ +# Architectural Decision: Why We Store Terraform State in AWS S3 vs. Git + +This document explains our decision to use AWS S3 and DynamoDB for Terraform state management instead of storing state files directly in version control. + +## 1. Security Risks (Plain-Text Secrets) +* **The Problem:** Terraform state files store infrastructure details in plain text. This includes database passwords, private keys, API tokens, and initial administrative credentials. +* **The Git Flaw:** Committing a state file to Git injects sensitive credentials into version control history. Even if the file is deleted later or the repository is private, secrets remain permanently baked into the Git history. + +## 2. Concurrency Issues (No State Locking) +* **The Problem:** Simultaneous deployments by multiple engineers can overwrite changes, leading to corrupted state files or destroyed cloud resources. +* **The Git Flaw:** Git lacks a live state locking mechanism. AWS S3 combined with DynamoDB natively locks the state file during execution. Git only detects conflicts during a `git push`, which happens after infrastructure changes are already applied. + +## 3. Automation Bottlenecks (Race Conditions) +* **The Problem:** Terraform requires real-time state accuracy before modifying infrastructure. +* **The Git Flaw:** Git introduces race conditions. Engineers must manually commit and push updated state files. If someone forgets to push or pull the latest changes, deployments run on stale data and break the infrastructure. + +--- + +## Interview Cheat Sheet: Summary Answer + +If asked, **"Have you considered storing the state file in Git instead of AWS S3?"**, answer with: + +> "We explicitly avoid storing the state file in Git because it violates security and operational best practices. First, state files contain plain-text secrets that should never be committed to version control. Second, Git doesn't support native state locking, which creates a massive risk of race conditions and state corruption if two team members run deployments simultaneously. We use AWS S3 with DynamoDB precisely because it gives us automated encryption at rest, automatic version history, and real-time state locking to ensure team safety."