100 Days of DevOps and Cloud (AWS), Day 27: Undo Isn't a Switch, and Neither Is Public

Two frequent requests are undoing changes and making things publicly accessible. At first glance, both actions seem like a single step, but they are actually multiple components. On day 27, both undoing a commit in Git and configuring a public subnet in AWS proved to be more complex than they appeared. One Git task and one AWS task were part of the KodeKloud Engineer platform.

Undoing a commit can be done in Git by reverting a specific commit, which creates a new commit with the inverse changes of the targeted commit. This new commit still keeps the original in the history, ensuring that the alteration remains visible. The git revert command does not delete anything; instead, it adds a new commit that undoes the targeted change. In contrast, git reset moves the branch pointer backwards and alters the history, which can cause problems when others pull the modified history.

On the AWS side, creating a public subnet involves using four separate components. First, an internet gateway is created and then attached to the VPC. A route table is subsequently set up with a default route to the internet gateway. The route table is then associated with the subnet, and finally, the subnet itself is modified to allow public IP addresses.

Each of these steps is essential; missing any one of them results in an instance that cannot reach the internet. The process may not produce any error messages or warnings, making it difficult to debug.

The terms "undo" and "public" are summaries of more complex actions. Undoing a commit in Git either adds an additive commit or rewrites shared history, both of which have different implications for the team's workflow. Making a subnet public in AWS requires configuring four separate resources, none of which are labeled as "public." In both cases, the word hides the actual work being performed, making it crucial to understand the underlying processes to avoid unintended consequences.