[APT-1630] Fix Refarch guide lists numbering

_docs-sources/guides/reference-architecture/02-authenticate/01-intro.md

@@ -9,20 +9,20 @@ In the last section, you got a basic [overview of the architecture](../01-overvi
 a variety of infrastructure deployed across multiple AWS accounts. In this section, you'll learn about authenticating
 and connecting to all the resources in your AWS accounts:
 
-* [Set up initial access](setting-up-initial-access): If this is your first time using this infrastructure—that is,
+* [Set up initial access](./02-setting-up-initial-access.md): If this is your first time using this infrastructure—that is,
   if Gruntwork just deployed and handed over the Reference Architecture to you—go through this section first!
 
-* [Authenticate to the AWS Web Console](authenticate-to-the-aws-web-console): Learn how to access each of your AWS
+* [Authenticate to the AWS Web Console](./03-authenticate-to-the-aws-web-console.md): Learn how to access each of your AWS
   accounts using a web browser. Since all the infrastructure is managed as code, you shouldn't be making many changes
   from the web console, but it's still useful for debugging, troubleshooting, learning, and looking at metrics, and logs.
 
-* [Authenticate to AWS via the CLI](authenticate-to-aws-via-the-cli): Learn how to access each of your AWS accounts
+* [Authenticate to AWS via the CLI](./04-authenticate-to-aws-via-the-cli.md): Learn how to access each of your AWS accounts
   from the command line. You'll need this to work with CLI tools such as the `aws`, `terraform`, `terragrunt`, and
   `packer`.
 
-* [Authenticate to the VPN server](authenticate-to-the-vpn-server): Just about all of the infrastructure is deployed
+* [Authenticate to the VPN server](./06-authenticate-to-the-vpn-server.md): Just about all of the infrastructure is deployed
   in private subnets, so it is not accessible directly from the public Internet. To be able to SSH to an EC2 instance
   or connect to a database, you'll first need to get "inside" the networking by connecting to the VPN server.
 
-* [Authenticate to EC2 Instances via SSH](authenticate-to-ec2-instances-via-ssh): If you need to debug something on
+* [Authenticate to EC2 Instances via SSH](./05-authenticate-to-ec2-instances-via-ssh.md): If you need to debug something on
   an EC2 instance, you'll need to connect over SSH.

_docs-sources/guides/reference-architecture/03-deploy-apps/05-publish-docker-image.md

@@ -11,25 +11,25 @@ First, you'll need to create the new ECR repository.
 add the desired repository name of your app. For the purposes of our example, let's call
 ours `simple-web-app`:
 
-```yaml
-simple-web-app:
-  external_account_ids_with_read_access:
-  # NOTE: we have to comment out the directives so that the python based data merger (see the `merge-data` hook under
-  # blueprints in this repository) can parse this yaml file. This still works when feeding through templatefile, as it
-  # will interleave blank comments with the list items, which yaml handles gracefully.
-  # %{ for account in accounts }
-  - '${account}'
-  # %{ endfor }
-  external_account_ids_with_write_access: []
-  tags: {}
-  enable_automatic_image_scanning: true
-```
+  ```yaml
+  simple-web-app:
+    external_account_ids_with_read_access:
+    # NOTE: we have to comment out the directives so that the python based data merger (see the `merge-data` hook under
+    # blueprints in this repository) can parse this yaml file. This still works when feeding through templatefile, as it
+    # will interleave blank comments with the list items, which yaml handles gracefully.
+    # %{ for account in accounts }
+    - '${account}'
+    # %{ endfor }
+    external_account_ids_with_write_access: []
+    tags: {}
+    enable_automatic_image_scanning: true
+  ```
 
 1. Commit and push the change:
 
-```bash
-git add shared/us-west-2/shared/data-stores/ecr-repos/terragrunt.hcl && git commit -m 'Added simple-web-app repo' && git push
-```
+  ```bash
+  git add shared/us-west-2/shared/data-stores/ecr-repos/terragrunt.hcl && git commit -m 'Added simple-web-app repo' && git push
+  ```
 
 1. Now open a pull request on the `simple-web-app-repo` branch.
 

_docs-sources/guides/reference-architecture/04-configure-gw-pipelines/01-intro.md

@@ -12,11 +12,11 @@ If you are not familiar with Gruntwork Pipelines, you can learn more by reading
 [How to configure a production-grade CI-CD workflow for infrastructure
 code](https://gruntwork.io/guides/automations/how-to-configure-a-production-grade-ci-cd-setup-for-apps-and-infrastructure-code/).
 
-* [CI / CD pipeline for infrastructure code](ci--cd-pipeline-for-infrastructure-code): How to configure a CI / CD
+* [CI / CD pipeline for infrastructure code](./02-ci--cd-pipeline-for-infrastructure-code.md): How to configure a CI / CD
   pipeline for infrastructure code, such as Terraform modules that configure your VPCs, databases, DNS settings, etc.
 
-* [CI / CD pipeline for app code](ci--cd-pipeline-for-app-code): How to configure a CI / CD pipeline for application
+* [CI / CD pipeline for app code](./03-ci--cd-pipeline-for-app-code.md): How to configure a CI / CD pipeline for application
   code, such as a Ruby, Python, PHP, or Java web service packaged with Packer or Docker.
 
-* [Update the CI / CD pipeline itself](update-the-ci--cd-pipeline-itself): How to pull in changes to the pipeline from
+* [Update the CI / CD pipeline itself](./04-update-the-ci--cd-pipeline-itself.md): How to pull in changes to the pipeline from
   `terraform-aws-ci` and redeploy pipeline containers.

_docs-sources/guides/reference-architecture/04-configure-gw-pipelines/02-ci--cd-pipeline-for-infrastructure-code.md

@@ -36,25 +36,25 @@ If you'd like to send Slack notifications when the pipeline is running, follow t
 
    ![Slack Workflow Builder](/img/guides/reference-architecture/slack-workflow-1.png)
 
-2. Create a new Webhook workflow called "Gruntwork Pipelines"
+1. Create a new Webhook workflow called "Gruntwork Pipelines"
 
    ![Slack Webhook workflow](/img/guides/reference-architecture/slack-workflow-2.png)
 
-3. Add the following text variables to the workflow: `branch`, `status`, `url`, `repo`, and `actor`
+1. Add the following text variables to the workflow: `branch`, `status`, `url`, `repo`, and `actor`
 
    ![Slack workflow variables](/img/guides/reference-architecture/slack-workflow-3.png)
 
-4. Once all of the variables are added, click Next.
+1. Once all of the variables are added, click Next.
 
-5. Now add another step to the workflow
+1. Now add another step to the workflow
 
    ![Slack workflow add step](/img/guides/reference-architecture/slack-workflow-4.png)
 
-6. Add the "Send a message"  step
+1. Add the "Send a message"  step
 
-7. Choose a channel from the dropdown menu
+1. Choose a channel from the dropdown menu
 
-8. In the Message Text field, paste the following contents:
+1. In the Message Text field, paste the following contents:
 
    ```bash
    Repo: <insert the repo variable>
@@ -64,17 +64,17 @@ If you'd like to send Slack notifications when the pipeline is running, follow t
    Workflow URL: <<insert the url variable>
    ```
 
-9. Use the "Insert a variable" button to insert a variable for each of the placeholders in the message above.
+1. Use the "Insert a variable" button to insert a variable for each of the placeholders in the message above.
 
-10. Save the Send a message step.
+1. Save the Send a message step.
 
-11. Hit the Publish button to make the Workflow live.
+1. Hit the Publish button to make the Workflow live.
 
-12. Copy the webhook URL and save it. We will use this value below.
+1. Copy the webhook URL and save it. We will use this value below.
 
    ![Slack workflow add step](/img/guides/reference-architecture/slack-workflow-5.png)
 
-13. Note that the webhook URL should be treated as sensitive. Anyone with the URL can send HTTP requests to the webhook!
+1. Note that the webhook URL should be treated as sensitive. Anyone with the URL can send HTTP requests to the webhook!
 
 ### Add secrets to GitHub
 

_docs-sources/guides/reference-architecture/04-configure-gw-pipelines/04-update-the-ci--cd-pipeline-itself.md

@@ -11,41 +11,41 @@ Here are the manual steps for this process:
 
 1. Run each script while authenticating to the `shared` account.
 
-```bash
-aws-vault exec your-shared -- shared/us-west-2/_regional/container_images/build_deploy_runner_image.sh
-aws-vault exec your-shared -- shared/us-west-2/_regional/container_images/build_kaniko_image.sh
-```
+  ```bash
+  aws-vault exec your-shared -- shared/us-west-2/_regional/container_images/build_deploy_runner_image.sh
+  aws-vault exec your-shared -- shared/us-west-2/_regional/container_images/build_kaniko_image.sh
+  ```
 
 1. Update [`common.hcl`](https://github.com/gruntwork-io/terraform-aws-service-catalog/tree/master/examples/for-production/infrastructure-live/common.hcl) with new tag values for these images. The new tag value will be version of
 `terraform-aws-ci` that the images use. For example, if your newly created images are using the `v0.38.9` release of
 `terraform-aws-ci`, update [`common.hcl`](https://github.com/gruntwork-io/terraform-aws-service-catalog/tree/master/examples/for-production/infrastructure-live/common.hcl) to:
 
-```bash
-deploy_runner_container_image_tag = "v0.38.9"
-kaniko_container_image_tag = "v0.38.9"
-```
+  ```bash
+  deploy_runner_container_image_tag = "v0.38.9"
+  kaniko_container_image_tag = "v0.38.9"
+  ```
 
 1. Run `apply` on the `ecs-deploy-runner` modules in each account. These can be run simultaneously in different terminal sessions.
 
-```bash
-cd logs/us-west-2/mgmt/ecs-deploy-runner
-aws-vault exec your-logs -- terragrunt apply --terragrunt-source-update -auto-approve
+  ```bash
+  cd logs/us-west-2/mgmt/ecs-deploy-runner
+  aws-vault exec your-logs -- terragrunt apply --terragrunt-source-update -auto-approve
 
-cd shared/us-west-2/mgmt/ecs-deploy-runner
-aws-vault exec your-shared -- terragrunt apply --terragrunt-source-update -auto-approve
+  cd shared/us-west-2/mgmt/ecs-deploy-runner
+  aws-vault exec your-shared -- terragrunt apply --terragrunt-source-update -auto-approve
 
-cd security/us-west-2/mgmt/ecs-deploy-runner
-aws-vault exec your-security -- terragrunt apply --terragrunt-source-update -auto-approve
+  cd security/us-west-2/mgmt/ecs-deploy-runner
+  aws-vault exec your-security -- terragrunt apply --terragrunt-source-update -auto-approve
 
-cd dev/us-west-2/mgmt/ecs-deploy-runner
-aws-vault exec your-dev -- terragrunt apply --terragrunt-source-update -auto-approve
+  cd dev/us-west-2/mgmt/ecs-deploy-runner
+  aws-vault exec your-dev -- terragrunt apply --terragrunt-source-update -auto-approve
 
-cd stage/us-west-2/mgmt/ecs-deploy-runner
-aws-vault exec your-stage -- terragrunt apply --terragrunt-source-update -auto-approve
+  cd stage/us-west-2/mgmt/ecs-deploy-runner
+  aws-vault exec your-stage -- terragrunt apply --terragrunt-source-update -auto-approve
 
-cd prod/us-west-2/mgmt/ecs-deploy-runner
-aws-vault exec your-prod -- terragrunt apply --terragrunt-source-update -auto-approve
-```
+  cd prod/us-west-2/mgmt/ecs-deploy-runner
+  aws-vault exec your-prod -- terragrunt apply --terragrunt-source-update -auto-approve
+  ```
 
 ## Why manually?
 

_docs-sources/guides/reference-architecture/05-monitoring-alerting-logging/01-intro.md

@@ -5,9 +5,9 @@ title: Intro
 
 # Monitoring, Alerting and Logging
 
-Now that you've seen how to [configure Gruntwork Pipelines](../configure-gw-pipelines/intro) to automatically build, test,
+Now that you've seen how to [configure Gruntwork Pipelines](../04-configure-gw-pipelines/01-intro.md) to automatically build, test,
 and deploy your code, you'll want to see what's happening in your AWS account:
 
-* [Metrics](metrics)
-* [Alerts](alerts)
-* [Logs](logs)
+* [Metrics](./02-metrics.md)
+* [Alerts](./03-alerts.md)
+* [Logs](./04-logs.md)

_docs-sources/guides/reference-architecture/06-adding-a-new-account/01-intro.md

@@ -8,7 +8,7 @@ title: Intro
 This document is a guide to how to add a new AWS account into the Reference Architecture. This is useful if you have a
 need to expand the Reference Architecture with more accounts, like a test or sandbox account.
 
-1. [Create new Account in your AWS Org](create-new-account-in-your-aws-org)
-1. [Update Logs, Security, and Shared accounts to allow cross account access](update-logs-security-shared-accounts-to-allow-cross-account-access)
-1. [Deploy the security baseline](deploy-the-security-baseline)
-1. [Deploy the ECS Deploy Runner](deploy-the-ecs-deploy-runner)
+* [Create new Account in your AWS Org](./02-create-new-account-in-your-aws-org.md)
+* [Update Logs, Security, and Shared accounts to allow cross account access](./03-update-logs-security-shared-accounts-to-allow-cross-account-access.md)
+* [Deploy the security baseline](./04-deploy-the-security-baseline.md)
+* [Deploy the ECS Deploy Runner](./05-deploy-the-ecs-deploy-runner.md)

_docs-sources/guides/reference-architecture/07-undeploy/01-intro.md

@@ -8,12 +8,12 @@ title: Intro
 In a previous section, you learned how to check [metrics, logs, and alerts](../05-monitoring-alerting-logging/01-intro.md). In
 this section, we'll walk you through how to undeploy parts or all of the Reference Architecture.
 
-1. [Before you get started](before-you-get-started)
-2. [Pre-requisite: force_destroy on S3 buckets](pre-requisite-force-destroy-on-s3-buckets)
-3. [Pre-requisite: understand module dependencies](pre-requisite-understand-module-dependencies)
-4. [Undeploying modules using Gruntwork Pipelines](undeploying-modules-using-gruntwork-pipelines)
-5. [Manually undeploying a single module](manually-undeploying-a-single-module)
-6. [Manually undeploying multiple modules or an entire environment](manually-undeploying-multiple-modules-or-an-entire-environment)
-7. [Removing the terraform state](removing-the-terraform-state)
-8. [Useful Tips](useful-tips)
-9. [Known errors](known-errors)
+* [Before you get started](./02-before-you-get-started.md)
+* [Pre-requisite: force_destroy on S3 buckets](./03-pre-requisite-force-destroy-on-s3-buckets.md)
+* [Pre-requisite: understand module dependencies](./04-pre-requisite-understand-module-dependencies.md)
+* [Undeploying modules using Gruntwork Pipelines](./05-undeploying-modules-using-gruntwork-pipelines.md)
+* [Manually undeploying a single module](./06-manually-undeploying-a-single-module.md)
+* [Manually undeploying multiple modules or an entire environment](./07-manually-undeploying-multiple-modules-or-an-entire-environment.md)
+* [Removing the terraform state](./08-removing-the-terraform-state.md)
+* [Useful Tips](./09-useful-tips.md)
+* [Known errors](./10-known-errors.md)

_docs-sources/guides/stay-up-to-date/terraform/4-how-to-update-to-terraform-1-x/1-core-concepts.md

@@ -7,7 +7,7 @@
 2021](https://www.hashicorp.com/blog/announcing-hashicorp-terraform-1-0-general-availability).
 Some of the major new features in 0.15 include:
 
-1.  A more stable state file format that will be compatible with Terraform 0.14, 0.15, and, once it’s released, 1.0.
+- A more stable state file format that will be compatible with Terraform 0.14, 0.15, and, once it’s released, 1.0.
 
 For more info, check out the for a complete introduction, check out the
 [announcement blog

docs/guides/reference-architecture/02-authenticate/01-intro.md

@@ -9,25 +9,25 @@ In the last section, you got a basic [overview of the architecture](../01-overvi
 a variety of infrastructure deployed across multiple AWS accounts. In this section, you'll learn about authenticating
 and connecting to all the resources in your AWS accounts:
 
-* [Set up initial access](setting-up-initial-access): If this is your first time using this infrastructure—that is,
+* [Set up initial access](./02-setting-up-initial-access.md): If this is your first time using this infrastructure—that is,
   if Gruntwork just deployed and handed over the Reference Architecture to you—go through this section first!
 
-* [Authenticate to the AWS Web Console](authenticate-to-the-aws-web-console): Learn how to access each of your AWS
+* [Authenticate to the AWS Web Console](./03-authenticate-to-the-aws-web-console.md): Learn how to access each of your AWS
   accounts using a web browser. Since all the infrastructure is managed as code, you shouldn't be making many changes
   from the web console, but it's still useful for debugging, troubleshooting, learning, and looking at metrics, and logs.
 
-* [Authenticate to AWS via the CLI](authenticate-to-aws-via-the-cli): Learn how to access each of your AWS accounts
+* [Authenticate to AWS via the CLI](./04-authenticate-to-aws-via-the-cli.md): Learn how to access each of your AWS accounts
   from the command line. You'll need this to work with CLI tools such as the `aws`, `terraform`, `terragrunt`, and
   `packer`.
 
-* [Authenticate to the VPN server](authenticate-to-the-vpn-server): Just about all of the infrastructure is deployed
+* [Authenticate to the VPN server](./06-authenticate-to-the-vpn-server.md): Just about all of the infrastructure is deployed
   in private subnets, so it is not accessible directly from the public Internet. To be able to SSH to an EC2 instance
   or connect to a database, you'll first need to get "inside" the networking by connecting to the VPN server.
 
-* [Authenticate to EC2 Instances via SSH](authenticate-to-ec2-instances-via-ssh): If you need to debug something on
+* [Authenticate to EC2 Instances via SSH](./05-authenticate-to-ec2-instances-via-ssh.md): If you need to debug something on
   an EC2 instance, you'll need to connect over SSH.
 
 
 <!-- ##DOCS-SOURCER-START
-{"sourcePlugin":"Local File Copier","hash":"ce4a1512822da8c46bc92f584d43495a"}
+{"sourcePlugin":"Local File Copier","hash":"0084de7a2d193494fe22e937115960bf"}
 ##DOCS-SOURCER-END -->

docs/guides/reference-architecture/03-deploy-apps/05-publish-docker-image.md

@@ -11,25 +11,25 @@ First, you'll need to create the new ECR repository.
 add the desired repository name of your app. For the purposes of our example, let's call
 ours `simple-web-app`:
 
-```yaml
-simple-web-app:
-  external_account_ids_with_read_access:
-  # NOTE: we have to comment out the directives so that the python based data merger (see the `merge-data` hook under
-  # blueprints in this repository) can parse this yaml file. This still works when feeding through templatefile, as it
-  # will interleave blank comments with the list items, which yaml handles gracefully.
-  # %{ for account in accounts }
-  - '${account}'
-  # %{ endfor }
-  external_account_ids_with_write_access: []
-  tags: {}
-  enable_automatic_image_scanning: true
-```
+  ```yaml
+  simple-web-app:
+    external_account_ids_with_read_access:
+    # NOTE: we have to comment out the directives so that the python based data merger (see the `merge-data` hook under
+    # blueprints in this repository) can parse this yaml file. This still works when feeding through templatefile, as it
+    # will interleave blank comments with the list items, which yaml handles gracefully.
+    # %{ for account in accounts }
+    - '${account}'
+    # %{ endfor }
+    external_account_ids_with_write_access: []
+    tags: {}
+    enable_automatic_image_scanning: true
+  ```
 
 1. Commit and push the change:
 
-```bash
-git add shared/us-west-2/shared/data-stores/ecr-repos/terragrunt.hcl && git commit -m 'Added simple-web-app repo' && git push
-```
+  ```bash
+  git add shared/us-west-2/shared/data-stores/ecr-repos/terragrunt.hcl && git commit -m 'Added simple-web-app repo' && git push
+  ```
 
 1. Now open a pull request on the `simple-web-app-repo` branch.
 
@@ -62,5 +62,5 @@ docker push 234567890123.dkr.ecr.us-west-2.amazonaws.com/simple-web-app:v1
 
 
 <!-- ##DOCS-SOURCER-START
-{"sourcePlugin":"Local File Copier","hash":"260e4427bc6a600851112079bd56d57a"}
+{"sourcePlugin":"Local File Copier","hash":"4e7ca8a7e4911b5a9e0e63182b09cffc"}
 ##DOCS-SOURCER-END -->