DEV-607: fix some broken anchors

docs/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -41,7 +41,7 @@ v0.7.0, v0.8.0, and v0.9.0 to get the full list of backward incompatible updates
 The following table provides a summary of all the relevant Gruntwork AWS modules and the respective versions that are
 compatible with CIS AWS v1.3.0:
 
-<a id="compatibility-table" class="snap-top"></a>
+##### Compatibility Table
 
 <table >
   <colgroup>

docs/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-3-deploy-new-modules.md

@@ -11,7 +11,7 @@ accidentally to a resource such as AWS Elastic Load Balancer (ELB), which can da
 achieve this recommendation, check out the [example](https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/tree/v0.10.0/examples/cleanup-expired-certs/terraform) of the ready-made `cleanup-expired-certs` module.
 
 For the code examples of deploying this module, see the
-[relevant section](../../../../build-it-yourself/achieve-compliance/production-grade-design/identity-and-access-management.md#cleanup-expired-ssl-tls-certificates)
+[relevant section](../../../../build-it-yourself/achieve-compliance/production-grade-design/identity-and-access-management.md#cleanup-expired-ssltls-certificates)
 of our "How to achieve compliance with the CIS AWS Foundations Benchmark" guide.
 
 ## 2. Deploy IAM Access Analyzer module (recommendation 1.21)

docs/guides/stay-up-to-date/cis/cis-1.4.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -21,7 +21,7 @@ v0.7.0, v0.8.0, and v0.9.0 to get the full list of backward incompatible updates
 The following table provides a summary of all the relevant Gruntwork AWS modules and the respective versions that are
 compatible with CIS AWS v1.4.0:
 
-<a id="compatibility-table" class="snap-top"></a>
+##### Compatibility Table
 
 <table id="compatibility-table">
   <colgroup>

docs/guides/stay-up-to-date/cis/cis-1.5.0/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -12,7 +12,7 @@ versions of the Gruntwork library to pick up the changes necessary for your infr
 The following table provides a summary of all the relevant Gruntwork AWS modules and the respective versions that are
 compatible with CIS AWS v1.5.0:
 
-<a id="compatibility-table" class="snap-top"></a>
+##### Compatibility Table
 
 <table id="compatibility-table">
   <colgroup>

docs/guides/stay-up-to-date/terraform/how-to-dry-your-reference-architecture/deployment-walkthrough/refactoring-common-configurations-for-a-component.md

@@ -4,13 +4,9 @@ The rest of this guide will cover how to identify and extract the common configu
 in your Reference Architecture. These steps can be used to refactor any component that is deployed in multiple
 accounts or environments in your Reference Architecture.
 
-- [Refactoring common configurations for a component](#refactoring-common-configurations-for-a-component)
-  - [Step 1: Identify the component](#step-1-identify-the-component)
-  - [Step 2: Identify common configurations](#step-2-identify-common-configurations)
-    - [Using `diff` to identify raw differences](#using-diff-to-identify-raw-differences)
-    - [Using JSON rendering to identify semantic differences](#using-json-rendering-to-identify-semantic-differences)
-  - [Step 3: Extract common configurations](#step-3-extract-common-configurations)
-  - [Step 4: Update child configurations](#step-4-update-child-configurations)
+import TOCInline from '@theme/TOCInline';
+
+<TOCInline toc={toc} />
 
 ## Step 1: Identify the component
 
@@ -43,7 +39,7 @@ Example inventory:
   - `logs/us-west-2/mgmt/ecs-deploy-runner`
   - `security/us-west-2/mgmt/ecs-deploy-runner`
 
-As mentioned in the [Background](../core-concepts.md#background), the changes will be isolated to Terragrunt configuration files (syntactic changes vs
+As mentioned in the [Background](../core-concepts.md), the changes will be isolated to Terragrunt configuration files (syntactic changes vs
 semantic changes) and there will be no need to roll out the changes using `terraform`. Given that, the order in which
 the components are updated does not matter. You can update the components in whatever order you would like.
 
@@ -92,14 +88,6 @@ identified as different across environments.
 There are a couple ways to go about this depending on how complex the underlying configuration files are, and how much
 customization has been made since the deployment of the Reference Architecture.
 
-- [Refactoring common configurations for a component](#refactoring-common-configurations-for-a-component)
-  - [Step 1: Identify the component](#step-1-identify-the-component)
-  - [Step 2: Identify common configurations](#step-2-identify-common-configurations)
-    - [Using `diff` to identify raw differences](#using-diff-to-identify-raw-differences)
-    - [Using JSON rendering to identify semantic differences](#using-json-rendering-to-identify-semantic-differences)
-  - [Step 3: Extract common configurations](#step-3-extract-common-configurations)
-  - [Step 4: Update child configurations](#step-4-update-child-configurations)
-
 ### Using `diff` to identify raw differences
 
 If you haven’t made many modifications to the component since the Reference Architecture was deployed, we recommend

docs/guides/stay-up-to-date/terraform/terraform-1.1/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -9,8 +9,7 @@ references to the Gruntwork Infrastructure as Code Library to use a compatible
 version. We (Gruntwork) have gone through all our modules in the library to test
 and update the code to be compatible with Terraform 1.1. As a customer, you need
 to update to the proper versions of the Gruntwork library to pick up the
-fixes/changes that we made to be compatible. Refer to [the "Updating to new versions" section of
-"Stay Up to Date"](/library/stay-up-to-date/updating#updating)
+fixes/changes that we made to be compatible. Refer to [Updating Modules](/2.0/docs/library/guides/updating-modules)
 for instructions on how to update the versions in your code.
 
 The releases of the modules from the Gruntwork Infrastructure as Code Library that correspond with the

docs/guides/stay-up-to-date/terraform/terraform-1.x/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md

@@ -9,8 +9,7 @@ references to the Gruntwork Infrastructure as Code Library to use a compatible
 version. We (Gruntwork) have gone through all our modules in the library to test
 and update the code to be compatible with Terraform 1.x. As a customer, you need
 to update to the proper versions of the Gruntwork library to pick up the
-fixes/changes that we made to be compatible. Refer to [the "Updating to new versions" section of
-"Stay Up to Date"](/library/stay-up-to-date/updating#updating)
+fixes/changes that we made to be compatible. Refer to [Updating Modules](/2.0/docs/library/guides/updating-modules)
 for instructions on how to update the versions in your code.
 
 For the vast majority of the repos, the only change that will be necessary is a

docs/guides/stay-up-to-date/terraform/terraform-12/deployment-walkthrough.md

@@ -22,10 +22,10 @@ gotchas that the upgrade tool occasionally misses.
 
 Here is the rough process:
 
-1. [Install and setup Terraform 0.12](#install-and-setup-terraform-12)
-1. [Upgrade each module for 0.12 compatibility](#upgrade-each-module-for-1compatibility)
+1. [Install and setup Terraform 0.12](#install-and-setup-terraform-012)
+1. [Upgrade each module for 0.12 compatibility](#upgrade-each-module-for-012-compatibility)
 
-### <a id="install-and-setup-terraform-0-12"></a>Install and setup Terraform 0.12
+### Install and setup Terraform 0.12
 
 To use Terraform 0.12, you will need to have the binary available on your machine. However, you don't want to blindly
 replace your existing `terraform` binary to the newer version, because that would mean you wouldn't be able to use the
@@ -104,7 +104,7 @@ terraform version
 
 You can find the available binaries for each terraform version [here](https://releases.hashicorp.com/terraform/).
 
-### <a name="upgrade-each-module-for-0-12-compatibility"></a>Upgrade each module for 0.12 compatibility
+### Upgrade each module for 0.12 compatibility
 
 To upgrade each of your modules to HCL2 syntax, you can run the `terraform 0.12upgrade` command using version 0.12.x of
 the `terraform` binary. You will need to do the following for each of your Terraform modules (e.g in your
@@ -172,14 +172,14 @@ terragrunt `terraform.tfvars` files to the new syntax.
 
 Here is the rough process:
 
-1. [Install and setup Terragrunt 0.19](#install-and-setup-terragrunt-19)
-1. [Migrate terraform.tfvars to terragrunt.hcl](#migrate-terraform-tfvars-to-terragrunt-hcl)
+1. [Install and setup Terragrunt 0.19](#install-and-setup-terragrunt-019)
+1. [Migrate terraform.tfvars to terragrunt.hcl](#migrate-terraformtfvars-to-terragrunthcl)
 1. [Switch common tfvars files to use yaml](#switch-common-tfvars-files-to-use-yaml)
 
-### <a name="install-and-setup-terragrunt-0-19"></a>Install and setup Terragrunt 0.19
+### Install and setup Terragrunt 0.19
 
 You will also need to setup the Terragrunt 0.19 binary in a [similar fashion to setting up Terraform
-0.12](#install-and-setup-terraform-0-12). You can use the same instructions available for managing Terraform 0.12 as for
+0.12](#install-and-setup-terraform-012). You can use the same instructions available for managing Terraform 0.12 as for
 managing Terragrunt 0.19.
 
 - [Using homebrew to manage multiple terragrunt versions](#using-homebrew-to-manage-multiple-terraform-versions)
@@ -219,7 +219,7 @@ versions](#manually-managing-multiple-terraform-versions) to manage multiple ver
 You can find the available binaries for each terragrunt version
 [here](https://github.com/gruntwork-io/terragrunt/releases).
 
-### <a name="migrate-terraform-tfvars-to-terragrunt-hcl"></a>Migrate terraform.tfvars to terragrunt.hcl
+### Migrate terraform.tfvars to terragrunt.hcl
 
 Once you have terragrunt 0.19 available on your machine, you will need to migrate your `terraform.tfvars` files to
 `terragrunt.hcl` files before you can start to use the new version. You will need to follow the steps outlined in the
@@ -233,7 +233,7 @@ environment to test the changes you are making to that module (e.g
 [`infrastructure-live/dev/us-east-1/dev/vpc`](https://github.com/gruntwork-io/infrastructure-live-multi-account-acme/tree/dd6dce7f737f8c1bd32466b69e905b2bdd25db80/dev/us-east-1/dev/vpc)).
 The rough process should be:
 
-1. Upgrade the module to TF12 syntax following the steps [listed above](#upgrade-each-module-for-1compatibility).
+1. Upgrade the module to TF12 syntax following the steps [listed above](#upgrade-each-module-for-012-compatibility).
 1. Update the live config for a pre-prod environment that deploys the module.
 1. Run `terragrunt plan` to verify the changes. Use `--terragrunt-source` so you can point to the updated module (see
    the docs on [working locally](https://github.com/gruntwork-io/terragrunt#working-locally)). Carefully review to make
@@ -257,7 +257,7 @@ module before promoting the changes. Depending on your infrastructure setup, you
 - Delaying promotion allows you to minimize disruption from environments being in a mixed version state, that might
   prevent you from addressing issues in downstream modules.
 
-### <a name="switch-common-tfvars-files-to-use-yaml"></a>Switch common tfvars files to use yaml
+### Switch common tfvars files to use yaml
 
 Terragrunt supports ingesting common `tfvars` files to pass global variables to your terraform modules through the use
 of [`required_var_files` and `optional_var_files` in the

docs/guides/style/markdown-style-guide.md

@@ -800,7 +800,7 @@ at the end of the file) where readers can find them in context.
 
 Please prefer standard Markdown syntax wherever possible and avoid HTML hacks.
 If you can't seem to accomplish what you want, reconsider whether you really
-need it. Except for [big tables](#prefer-lists-to-tables), Markdown meets almost
+need it. Except for [big tables](#consider-lists-for-complex-content), Markdown meets almost
 all needs already.
 
 Every bit of HTML or Javascript hacking reduces the readability and portability.

docs/infrastructure-pipelines/security/audit-log.md

@@ -12,7 +12,7 @@ CloudTrail can be configured to automatically store events in an S3 bucket of yo
 
 ## How it works
 
-Gruntwork Pipelines provides an audit log of which user performed what action in which account. To accomplish this, Pipelines sets the [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) session name using a combination of the initiating GitHub user, the name of Pipelines itself, and the pull request or branch from which the action was triggered. All log data for Gruntwork Pipelines is done using [AWS CloudTrail](https://aws.amazon.com/cloudtrail/). Session names are used in the `User name` field in CloudTrail, allowing those searching the data to clearly identify which user performed an action. For more information on querying the logs see [where you can find logs](#where-you-can-find-logs) and [querying data](#querying-data).
+Gruntwork Pipelines provides an audit log of which user performed what action in which account. To accomplish this, Pipelines sets the [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) session name using a combination of the initiating GitHub user, the name of Pipelines itself, and the pull request or branch from which the action was triggered. All log data for Gruntwork Pipelines is done using [AWS CloudTrail](https://aws.amazon.com/cloudtrail/). Session names are used in the `User name` field in CloudTrail, allowing those searching the data to clearly identify which user performed an action. For more information on querying the logs see [where you can find logs](#where-you-can-find-logs).
 
 ### What gets logged
 

docs/support.mdx

@@ -9,7 +9,7 @@ import CardGroup from "/src/components/CardGroup"
 
 # Need Help?
 
-We’re here to assist when you get stuck. Basic support is included with every Gruntwork subscription, providing access to our knowledge base and an active community of users. Our [paid support plans](#paid-support-tiers) offer additional avenues for obtaining support, and guaranteed response times. Lastly, our [Pro Serve](#pro-serve) team offers personalized services via paid engagements to help your team overcome any hurdles you have using your Gruntwork subscription to realize its goals.
+We’re here to assist when you get stuck. Basic support is included with every Gruntwork subscription, providing access to our knowledge base and an active community of users. Our [paid support plans](#paid-support-tiers) offer additional avenues for obtaining support, and guaranteed response times. Lastly, our Pro Serve team offers personalized services via paid engagements to help your team overcome any hurdles you have using your Gruntwork subscription to realize its goals.
 
 ## Get Support
 

src/components/HclListItem.tsx

@@ -1,5 +1,6 @@
 import React, { PropsWithChildren } from "react"
 import styles from "./HclListItem.module.css"
+import useBrokenLinks from '@docusaurus/useBrokenLinks';
 
 interface HclListItemProps {
   name: string
@@ -10,6 +11,7 @@ interface HclListItemProps {
 export const HclListItem: React.FunctionComponent<
   PropsWithChildren<HclListItemProps>
 > = ({ name, requirement, type, children }) => {
+  useBrokenLinks().collectAnchor(name);
   return (
     <div className={styles.container}>
       <div>