Fix typos in markdown docs (#781)

osterman · web-flow · commit 2df1d2440afe · 2025-06-18T16:31:00.000-05:00
diff --git a/docs/best-practices/terraform.mdx b/docs/best-practices/terraform.mdx
@@ -212,7 +212,7 @@ restricted, you should not use a custom validator to enforce that for two reason
 2. If you use a custom validator to enforce that the string is one of those
    two values, and then a later version of the resource adds a new option to the
    enumeration, such as "HOURLY", the custom validator will prevent the
-   module from using the new value, even though the module woudl function
+   module from using the new value, even though the module would function
    perfectly were it not for the validator. This adds work and delay to the
    adoption of underlying enhancements to the resource, without providing
    enough benefit to be worth the extra effort.
diff --git a/docs/community/contribute/component-testing.mdx b/docs/community/contribute/component-testing.mdx
@@ -87,7 +87,7 @@ The difference with a regular atmos configuration are:
 1. All components deployed on one stack `default-test` in one `us-east-2` region.
 2. Use single aws account for all test resources. If component assumes the cross region or cross account interaction, the configuration still deploys it to the same actual aws account.
 3. Mock `account-map` component to skip role assuming and always use current AWS credentials provided with environment variables
-4. Configure teraform state files storage to local directory at a path provided by test framework with environment variable `COMPONENT_HELPER_STATE_DIR`
+4. Configure terraform state files storage to local directory at a path provided by test framework with environment variable `COMPONENT_HELPER_STATE_DIR`
 </Steps>
 
 This configuration is common for all components and could be copied from [template repo](https://github.com/cloudposse-terraform-components/template/tree/main/test).
@@ -218,7 +218,7 @@ A test suite run consists of the following phases all of which can be controlled
 | Test       | Deploy the component                      |`--only-deploy-dependencies`|
 | Teardown   | Destroy all dependencies                  |`--skip-teardown`           |
 
-This is possible to enable/disable steps on each phase more precisly
+This is possible to enable/disable steps on each phase more precisely
 
 | Phase      | Description                                            |         Skip flag           |
 |------------|--------------------------------------------------------|-----------------------------|
@@ -230,7 +230,7 @@ This is possible to enable/disable steps on each phase more precisly
 | Teardown   | Destroy all dependencies                               |`--skip-destroy-dependencies`|
 
 
-Here is the usefull combination of flags.
+Here is the useful combination of flags.
 
 |         Command                                                                                                             | Description                                                                                                                               |
 |-----------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------|
diff --git a/docs/community/contribute/contributor-tips.mdx b/docs/community/contribute/contributor-tips.mdx
@@ -34,7 +34,7 @@ Here is a standard usage pattern that contributors can adopt to specific changes
     1. `mkdir ~/mp_workspace && cd ~/mp_workspace`
   1. Initialize microplane:
     1. `mp init --all-repos "cloudposse"`
-    1. Initializing creates an `mp/` folder in your current directoy, finds all of the Cloud Posse public projects, and then creates an `mp/init.json` file describing them.
+    1. Initializing creates an `mp/` folder in your current directory, finds all of the Cloud Posse public projects, and then creates an `mp/init.json` file describing them.
     1. NOTE: microplane supposedly has the ability to search against an organization and narrow the returned repos that end up in `init.json`, but that functionality seems buggy and not working. We do our repo filtering manually in the next step.
   1. Manually edit `mp/init.json` to only include the repos which you want to make changes against.
     1. Your editor's multi-select and edit capabilities are your friend here! (or maybe some [`jq`](https://stedolan.github.io/jq/) if that's your thing)
diff --git a/docs/community/contribute/faq.mdx b/docs/community/contribute/faq.mdx
@@ -120,7 +120,7 @@ We're not accepting new features for pre-terraform-0.12 modules.
 
 ## Why is my Terraform Pull Request not yet reviewed or merged?
 
-If your Pull Request is to upgrade a Terraform module from HCLv1 to HCLv2, then chances are we haven't approved it because it does not have `terratest` integration tests. As a general policy, we're only upgrading modules to HCLv2 that have `terratest` integration tests. Attemting to maintain stability
+If your Pull Request is to upgrade a Terraform module from HCLv1 to HCLv2, then chances are we haven't approved it because it does not have `terratest` integration tests. As a general policy, we're only upgrading modules to HCLv2 that have `terratest` integration tests. Attempting to maintain stability
 with hundreds of modules is only possible with integration testing.
 
 :::info
diff --git a/docs/jumpstart/kickoff.mdx b/docs/jumpstart/kickoff.mdx
@@ -179,7 +179,7 @@ Cloud Posse has noticed several patterns that lead to successful projects.
   <Step>
     ### <StepNumber/> Cameras On
 
-    We recommend that all participants have their cameras on. This helps to build trust and rapport. It also helps to keep everyone engaged and focused. This also lets us gage how everyone is understanding the material. If you are having trouble understanding something, please ask questions.
+    We recommend that all participants have their cameras on. This helps to build trust and rapport. It also helps to keep everyone engaged and focused. This also lets us gauge how everyone is understanding the material. If you are having trouble understanding something, please ask questions.
 
   </Step>
 
diff --git a/docs/layers/accounts/tutorials/how-to-create-and-setup-aws-accounts.mdx b/docs/layers/accounts/tutorials/how-to-create-and-setup-aws-accounts.mdx
@@ -189,7 +189,7 @@ readonly profile_order=(
 Rebuild the container to update the script or use the `rootfs/usr/local/bin/aws-accounts` directly.
 
 ```
-# regnerate cicd profiles
+# regenerate cicd profiles
 aws-accounts gen-cicd > rootfs/etc/aws-config/aws-config-cicd-$TENANT
 
 # regenerate local saml profiles
diff --git a/docs/layers/accounts/tutorials/how-to-delete-aws-accounts.mdx b/docs/layers/accounts/tutorials/how-to-delete-aws-accounts.mdx
@@ -18,7 +18,7 @@ programmatic way to destroy accounts. The following ClickOps method is required
 
 :::caution
 
-Email accounts associated with AWS accounts are globally unique and cannot be re-used even after the account deletion.
+Email accounts associated with AWS accounts are globally unique and cannot be reused even after the account deletion.
 If you ever intend to use the email address again with AWS on another account, we strongly recommend that you first
 rename the email address on record before proceeding to delete the account.
 
diff --git a/docs/layers/alerting/opsgenie/opsgenie.mdx b/docs/layers/alerting/opsgenie/opsgenie.mdx
@@ -112,7 +112,7 @@ An important note here is the **Service** mapping from **Datadog** to **OpsGenie
 
 ## Incidents
 
-An Incident is an escalated alert with a business impact. All SLOs by definition have business impacts and therefore when violated should be considered an incident. We define anything of severity P1 or P2 as an incident and therefor having business impact. An alert is automatically escalated to an incident by its severity as defined in the monitor.
+An Incident is an escalated alert with a business impact. All SLOs by definition have business impacts and therefore when violated should be considered an incident. We define anything of severity P1 or P2 as an incident and therefore having business impact. An alert is automatically escalated to an incident by its severity as defined in the monitor.
 
 ## Component: `opsgenie-team`
 
diff --git a/docs/layers/identity/docs/dynamic-terraform-roles.mdx b/docs/layers/identity/docs/dynamic-terraform-roles.mdx
@@ -700,7 +700,7 @@ the `devops` team access to it, and perhaps including the CI/CD team(s).
 
 In the `identity` account, the `terraform` role should currently be
 controlled by the `aws-teams` configuration. You should have already added
-`mangers` the `trusted_teams` list for the `terraform` role via `aws-teams`,
+`managers` the `trusted_teams` list for the `terraform` role via `aws-teams`,
 but double-check now.
 
 Later, you will deploy the `aws-team-roles` stack to the `identity` account,
diff --git a/docs/layers/network/design-decisions/decide-on-primary-aws-region.mdx b/docs/layers/network/design-decisions/decide-on-primary-aws-region.mdx
@@ -29,7 +29,7 @@ This is especially true if most of the services in the default region will be co
 
 When operating on AWS, selecting a region other than `us-east-1` is advisable as this is the default region (or used to
 be) for most AWS users. It has historically had the most service interruptions presumably because it is one of the most
-heavily-used regions and operates at a scale much larger than other AWS regions. Therefor we advise using `us-east-2`
+heavily-used regions and operates at a scale much larger than other AWS regions. Therefore we advise using `us-east-2`
 over `us-east-1` and the latencies between these regions is very minimal.
 
 ### High Availability / Availability Zones
diff --git a/docs/layers/network/design-decisions/decide-on-service-discovery-domain.mdx b/docs/layers/network/design-decisions/decide-on-service-discovery-domain.mdx
@@ -30,7 +30,7 @@ Our recommendation is to keep it short and simple.
 
 The length of the domain doesn’t technically matter, but your engineers will be typing this out all the time.
 
-### Buy New or Re-use
+### Buy New or Reuse
 
 :::tip We usually recommend registering a net-new domain (e.g. on route53) rather than repurposing an existing one.
 Domains are too inexpensive these days to worry about the cost.
diff --git a/docs/layers/network/design-decisions/decide-on-vanity-branded-domain.mdx b/docs/layers/network/design-decisions/decide-on-vanity-branded-domain.mdx
@@ -40,7 +40,7 @@ This is not the same as
   features.
 
 - **CORS headers should prevent cross-origin requests from staging and product.** We want to prevent wildcards from
-  permitting cross-staging requests which could lead to staging hammering production (vise versa)
+  permitting cross-staging requests which could lead to staging hammering production (vice versa)
 
 ```
 Access-Control-Allow-Origin: https://*.acme.com
diff --git a/docs/layers/software-delivery/design-decisions/decide-on-pipeline-strategy.mdx b/docs/layers/software-delivery/design-decisions/decide-on-pipeline-strategy.mdx
@@ -98,7 +98,7 @@ What we implement as part of our approach and the specific use cases we address
 
 ### CI QA Environments
 
-- QA environments are a discreet set of static environments running on Kubernetes with preprovisioned third party services. They are similar to preview environments, except that environments are shared by QA engineers to verify PR changes in “close to real live” environment. QA engineer can deploy/undeploy PR changes to one of the QA environments by adding or removing the `deploy/qa{number}` label.
+- QA environments are a discrete set of static environments running on Kubernetes with preprovisioned third party services. They are similar to preview environments, except that environments are shared by QA engineers to verify PR changes in “close to real live” environment. QA engineer can deploy/undeploy PR changes to one of the QA environments by adding or removing the `deploy/qa{number}` label.
 - If several PRs of one repo have `deploy/qa{number}` label then the latest deployment (commit & push) will override each other.
 - It is responsibility of QA engineers to avoid this conflict. GitHub environments UI is useful for seeing what is deployed.
 
@@ -119,7 +119,7 @@ What we implement as part of our approach and the specific use cases we address
 
 ### Automated Releases with Approval Gates
 
-- When a Developer (or Release Manager) decides to issue a new release they need just to publish the _Draft Release_ that will trigger the “_Release workflow_“. The workflow should create a new “Release branch” `release/{version}`, promote docker image with release version and consequentially deploy it to `Staging` and `Production` environments with approval gates. Developer need to approve deployment on `Staging` environment, wait the deployment would be successfully completed and then repeat the same for `Production` environment.
+- When a Developer (or Release Manager) decides to issue a new release they need just to publish the _Draft Release_ that will trigger the “_Release workflow_“. The workflow should create a new “Release branch” `release/{version}`, promote docker image with release version and consequently deploy it to `Staging` and `Production` environments with approval gates. Developer need to approve deployment on `Staging` environment, wait the deployment would be successfully completed and then repeat the same for `Production` environment.
 
 ### Staging Environment
 
diff --git a/docs/layers/software-delivery/design-decisions/decide-on-strategy-for-preview-environments-e-g-review-apps.mdx b/docs/layers/software-delivery/design-decisions/decide-on-strategy-for-preview-environments-e-g-review-apps.mdx
@@ -52,7 +52,7 @@ Slight improvement over using `helmfile` with the `raw` chart.
 
 #### Pros
 
-- Re-useable chart between services; very DRY
+- Reusable chart between services; very DRY
 
 - Chart can be tested and standardized to reduce the variations of applications deployed (e.g. NodeJS chart, Rails chart)
 
diff --git a/docs/layers/software-delivery/ecs-ecspresso/ecs-partial-task-definitions.mdx b/docs/layers/software-delivery/ecs-ecspresso/ecs-partial-task-definitions.mdx
@@ -119,7 +119,7 @@ This also means that when something goes wrong, it becomes harder to troubleshoo
                    days: 730
                # Never expire
                expiration: {}
-               # Versioning isnt enabled, but these default values are still required
+               # Versioning isn't enabled, but these default values are still required
                noncurrent_version_transition:
                  - storage_class: GLACIER
                    days: 90
diff --git a/docs/learn/conventions.mdx b/docs/learn/conventions.mdx
@@ -318,7 +318,7 @@ For proprietary apps deployed by your organization, we recommend taking a differ
 
 **What if we need more than one deployment (or XYZ) in a chart?**  That’s easy. You have a few options: a) Deploy the same chart twice; b) Decide if as an organization you want to support that interface and then extend the chart; c) Develop an additional chart interface.
 
-**What if we want to add a feature to our chart and don’t want to disrupt other services?** No problem. Charts are versioned. So think of the version of a chart as the version of your interface. Everytime you change the chart, bump the version. Ensure all your services pin to a version of the chart. Now when you change the version of the chart in your service, you know that your upgrading your interface as well.
+**What if we want to add a feature to our chart and don’t want to disrupt other services?** No problem. Charts are versioned. So think of the version of a chart as the version of your interface. Every time you change the chart, bump the version. Ensure all your services pin to a version of the chart. Now when you change the version of the chart in your service, you know that your upgrading your interface as well.
 
 **What if we need some backing services?** Good question. You can still use the features of umbrella charts, and even feature flag common things like deploying a database backend for development environments by using a `condition` in the `requirements.yaml` that can be toggled in the `values.yaml`. _Pro-tip:_ Use [https://artifacthub.io/](https://artifacthub.io/) to find ready-made charts you can use.
 
diff --git a/docs/learn/maintenance/tutorials/how-to-define-stacks-for-multiple-regions.mdx b/docs/learn/maintenance/tutorials/how-to-define-stacks-for-multiple-regions.mdx
@@ -17,7 +17,7 @@ We want to deploy a component or set of to multiple regions. The components migh
 First, make sure you’re familiar with [Stacks](/resources/legacy/fundamentals/stacks) and [How to Use Imports and Catalogs in Stacks](/learn/maintenance/tutorials/how-to-use-imports-and-catalogs-in-stacks) with [Components](/components) Inheritance.
 
 :::tip
-Define one stack configuration for every region and simply import the catalog configuration with all components you want to re-use per region.
+Define one stack configuration for every region and simply import the catalog configuration with all components you want to reuse per region.
 
 :::
 
diff --git a/docs/learn/maintenance/tutorials/how-to-update-components-yaml-to-new-organization.mdx b/docs/learn/maintenance/tutorials/how-to-update-components-yaml-to-new-organization.mdx
@@ -38,7 +38,7 @@ you will get `component.yaml` files updated automatically.
 
 1. For each component in your repository open the `component.yaml` file
 2. Find the `source` section and update the `version` field to `1.532.0`
-3. Find the `source` section and update the `uri` field to the new component repo accroding to this table
+3. Find the `source` section and update the `uri` field to the new component repo according to this table
 
 | Component                                       | Old URI                                                                                                                     |  New URI                                                                                                            |
 |-------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|
diff --git a/docs/learn/maintenance/tutorials/how-to-use-imports-and-catalogs-in-stacks.mdx b/docs/learn/maintenance/tutorials/how-to-use-imports-and-catalogs-in-stacks.mdx
@@ -15,7 +15,7 @@ As infrastructure grows, we end up with hundreds or thousands of settings for co
 
 :::tip
 
-Use the `import` together with the `catalog` convention to write DRY configurations you can re-use any number of times.
+Use the `import` together with the `catalog` convention to write DRY configurations you can reuse any number of times.
 
 :::
 
diff --git a/docs/learn/tips-and-tricks/docker.mdx b/docs/learn/tips-and-tricks/docker.mdx
@@ -70,4 +70,4 @@ By default, you are prompted to continue which can be bypassed by adding the `-f
 
 ## Simulate Multiple Inheritance
 
-Docker doesn't technically support multiple-inheritance, whereby an image can automatically merge multiple images using `FROM`. It does, however, support [multi-stage builds](/best-practices/docker#multi-stage-builds) that can be used to effectiely achive the same result.
+Docker doesn't technically support multiple-inheritance, whereby an image can automatically merge multiple images using `FROM`. It does, however, support [multi-stage builds](/best-practices/docker#multi-stage-builds) that can be used to effectively achieve the same result.
diff --git a/docs/quickstart/kickoff.mdx b/docs/quickstart/kickoff.mdx
@@ -164,7 +164,7 @@ Cloud Posse has noticed several patterns that lead to successful projects.
   <Step>
     ### <StepNumber/> Cameras On
 
-    We recommend that all participants have their cameras on during our Zoom calls. This helps to build trust and rapport. It also helps to keep everyone engaged and focused. This also lets us gage how everyone is understanding the material. If you are having trouble understanding something, please ask questions.
+    We recommend that all participants have their cameras on during our Zoom calls. This helps to build trust and rapport. It also helps to keep everyone engaged and focused. This also lets us gauge how everyone is understanding the material. If you are having trouble understanding something, please ask questions.
 
   </Step>
 
diff --git a/docs/quickstart/quickstart.mdx b/docs/quickstart/quickstart.mdx
@@ -76,6 +76,6 @@ import StepNumber from '@site/src/components/StepNumber';
   If you need more assistance, our [support options](/support) provide direct access to Cloud Posse to help you out.
   <div>
     <PrimaryCTA to="/quickstart/kickoff">Review Kick-off Agenda</PrimaryCTA>
-    <SecondaryCTA to="/layers/foundation">Read the Documetnation</SecondaryCTA>
+    <SecondaryCTA to="/layers/foundation">Read the Documentation</SecondaryCTA>
   </div>
 </ActionCard>
diff --git a/docs/resources/glossary/crud.mdx b/docs/resources/glossary/crud.mdx
@@ -1,7 +1,7 @@
 ---
 title: "Create, Read, Update, Delete (CRUD)"
-description: "CRUD is a frequently used acronym which means Create, Read, Update and Destroy. It refrers to the standard life-cycle events for data manipulation."
+description: "CRUD is a frequently used acronym which means Create, Read, Update and Destroy. It refers to the standard life-cycle events for data manipulation."
 tags:
 - CRUD
 ---
-CRUD is a frequently used acronym which means Create, Read, Update and Destroy. It refrers to the standard life-cycle events for data manipulation.
+CRUD is a frequently used acronym which means Create, Read, Update and Destroy. It refers to the standard life-cycle events for data manipulation.
diff --git a/docs/resources/glossary/docker-image.mdx b/docs/resources/glossary/docker-image.mdx
@@ -1,11 +1,11 @@
 ---
 title: "Docker Image"
-description: "A docker image is a self-contained, layered archive containing an application and all of its OS dependancies and is the artifact of running a `docker build`. The image is what gets stored in a [docker registry](https://docs.docker.com/registry)."
+description: "A docker image is a self-contained, layered archive containing an application and all of its OS dependencies and is the artifact of running a `docker build`. The image is what gets stored in a [docker registry](https://docs.docker.com/registry)."
 terms:
 - docker image
 - docker images
 tags:
 - docker
 - image
 ---
-A [docker image](https://docs.docker.com/engine/reference/commandline/images/) is a self-contained, layered archive containing an application and all of its OS dependancies and is the artifact of running a `docker build`. The image is what gets stored in a [docker registry](https://docs.docker.com/registry).
+A [docker image](https://docs.docker.com/engine/reference/commandline/images/) is a self-contained, layered archive containing an application and all of its OS dependencies and is the artifact of running a `docker build`. The image is what gets stored in a [docker registry](https://docs.docker.com/registry).
diff --git a/docs/resources/glossary/geodesic-module.mdx b/docs/resources/glossary/geodesic-module.mdx
diff --git a/docs/resources/glossary/git-workflow.mdx b/docs/resources/glossary/git-workflow.mdx
diff --git a/docs/resources/glossary/iap.mdx b/docs/resources/glossary/iap.mdx
diff --git a/docs/resources/legacy/fundamentals/atmos.mdx b/docs/resources/legacy/fundamentals/atmos.mdx
diff --git a/docs/resources/legacy/fundamentals/concepts.mdx b/docs/resources/legacy/fundamentals/concepts.mdx
diff --git a/docs/resources/legacy/fundamentals/geodesic.mdx b/docs/resources/legacy/fundamentals/geodesic.mdx
diff --git a/docs/resources/legacy/helm.mdx b/docs/resources/legacy/helm.mdx
diff --git a/docs/resources/legacy/howto/geodesic/authenticate-with-leapp.mdx b/docs/resources/legacy/howto/geodesic/authenticate-with-leapp.mdx
diff --git a/docs/resources/legacy/tools.mdx b/docs/resources/legacy/tools.mdx
