fix: Making headers better

docs/_docs/02_features/includes.md

@@ -11,9 +11,9 @@ nav_title_link: /docs/
 ---
 
 - [Motivation](#motivation)
-- [Using include to DRY common Terragrunt config](#using-include-to-dry-common-terragrunt-config)
-- [Using exposed includes to override common configurations](#using-exposed-includes-to-override-common-configurations)
-- [Using read\_terragrunt\_config to access configurations directly](#using-read_terragrunt_config-to-access-configurations-directly)
+- [Using includes](#using-includes)
+- [Using exposed includes](#using-exposed-includes)
+- [Using read\_terragrunt\_config](#using-read_terragrunt_config)
 - [Considerations for CI/CD Pipelines](#considerations-for-cicd-pipelines)
 
 ## Motivation
@@ -99,7 +99,7 @@ adjustment to the `instance_type` parameter for each environment. These identica
 
 To solve this, you can use [multiple include blocks]({{site.baseurl}}/docs/reference/config-blocks-and-attributes#include).
 
-## Using include to DRY common Terragrunt config
+## Using multiple includes
 
 Suppose your `qa/app/terragrunt.hcl` configuration looks like the following:
 
@@ -207,7 +207,7 @@ inputs = {
 }
 ```
 
-## Using exposed includes to override common configurations
+## Using exposed includes
 
 In the previous section, we covered using `include` to DRY common component configurations. While powerful, `include` has
 a limitation where the included configuration is statically merged into the child configuration.
@@ -282,7 +282,7 @@ inputs = {
 }
 ```
 
-## Using read\_terragrunt\_config to access configurations directly
+## Using `read_terragrunt_config`
 
 In the previous two sections, we covered using `include` to merge Terragrunt configurations through static merges
 with unit configuration. What if you want included configurations to be dynamic in the context of unit where they

docs/_docs/02_features/units.md

@@ -13,7 +13,7 @@ nav_title_link: /docs/
 - [Motivation](#motivation)
 - [Terragrunt units](#terragrunt-units)
 - [Remote OpenTofu/Terraform modules](#remote-opentofuterraform-modules)
-- [Achieve immutable infrastructure patterns and atomic deployments](#achieve-immutable-infrastructure-patterns-and-atomic-deployments)
+- [Immutable modules and atomic deployments](#immutable-modules-and-atomic-deployments)
 - [Working locally](#working-locally)
 - [Working with lock files](#working-with-lock-files)
 - [Terragrunt caching](#terragrunt-caching)
@@ -169,7 +169,7 @@ When Terragrunt finds the `terraform` block with a `source` parameter in `live/s
 
 Check out the [terragrunt-infrastructure-modules-example](https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example) and [terragrunt-infrastructure-live-example](https://github.com/gruntwork-io/terragrunt-infrastructure-live-example) repos for fully-working sample code that demonstrates our recommended folder structure for successful infrastructure management.
 
-## Achieve immutable infrastructure patterns and atomic deployments
+## Immutable modules and atomic deployments
 
 With this approach, copy/paste between environments is minimized. The `terragrunt.hcl` files contain solely the `source` URL of the module to deploy and the `inputs` to set for that module in the current environment. To create a new unit, you copy an old one and update just the environment-specific `inputs` in the `terragrunt.hcl` files, which is about as close to the "essential complexity" of the problem as you can get.