Update to multiple READMEs

CONTRIBUTING.md

@@ -49,7 +49,7 @@ If you changed variables or outputs you need to regenerate the relevant tables i
 ./tools/tfdoc.py modules/my-changed-module
 ```
 
-If the folder contains files which won't be pushed to the repository, for example provider files used in FAST stages, you need to change the command above to specifically exclude them from `tfdoc` geerated output.
+If the folder contains files which won't be pushed to the repository, for example provider files used in FAST stages, you need to change the command above to specifically exclude them from `tfdoc` generated output.
 
 ```bash
 # exclude a local provider file from the generated documentation
@@ -106,7 +106,7 @@ This is probably our oldest and most important design principle. When designing
 
 It's a radically different approach from designing by product or feature, where boundaries are drawn around a single GCP functionality.
 
-Our modules -- and in a much broader sense our FAST stages -- are all designed to encapsulate a set of functionally related resources and their configurations. This achieves two main goals: to dramatically improve readabiity by using a single block of code -- a module declaration -- for a logical component; and to allow consumers to rely on outputs without having to worry about the dependency chain, as all related resources and configurations are managed internally in the module or stage.
+Our modules -- and in a much broader sense our FAST stages -- are all designed to encapsulate a set of functionally related resources and their configurations. This achieves two main goals: to dramatically improve readability by using a single block of code -- a module declaration -- for a logical component; and to allow consumers to rely on outputs without having to worry about the dependency chain, as all related resources and configurations are managed internally in the module or stage.
 
 Taking IAM as an example, we do not offer a single module to centrally manage role bindings (the product/feature based approach) but implement it instead in each module (the logical component approach) since:
 
@@ -335,7 +335,7 @@ module "simple-vm-example" {
 
 #### Depend outputs on internal resources
 
-We mentioned this principle when discussing encapsulation above but it's worth repating it explicitly: **set explicit dependencies in outputs so consumers will wait for full resource configuration**.
+We mentioned this principle when discussing encapsulation above but it's worth repeating it explicitly: **set explicit dependencies in outputs so consumers will wait for full resource configuration**.
 
 As an example, users can safely reference the project module's `project_id` output from other modules, knowing that the dependency tree for project configurations (service activation, IAM, etc.) has already been defined inside the module itself. In this particular example the output is also interpolated instead of derived from the resource, so as to avoid issues when used in `for_each` keys.
 
@@ -410,7 +410,7 @@ variable "folder_ids" {
 }
 ```
 
-When creating a new stage or adding a feature to an existing one, always try to leverage the existing interfaces when some of the information you produce needs to cross the stage boundary, so as to minimize impact on producers and consumers lofically dependent on your stage.
+When creating a new stage or adding a feature to an existing one, always try to leverage the existing interfaces when some of the information you produce needs to cross the stage boundary, so as to minimize impact on producers and consumers logically dependent on your stage.
 
 #### Output files
 
@@ -566,7 +566,7 @@ We run two GitHub workflows on PRs:
 The linting workflow tests:
 
 - that the correct copyright boilerplate is present in all files, using `tools/check_boilerplate.py`
-- that all Teraform code is linted via `terraform fmt`
+- that all Terraform code is linted via `terraform fmt`
 - that all README files have up to date outputs, variables, and files (where relevant) tables, via `tools/check_documentation.py`
 - that all links in README files are syntactically correct and valid if internal, via `tools/check_links.py`
 - that resource names used in FAST stages stay within a length limit, via `tools/check_names.py`

examples/cloud-operations/README.md

@@ -6,7 +6,7 @@ The examples in this folder show how to wire together different Google Cloud ser
 
 <a href="./asset-inventory-feed-remediation" title="Resource tracking and remediation via Cloud Asset feeds"><img src="./asset-inventory-feed-remediation/diagram.png" align="left" width="280px"></a> This [example](./asset-inventory-feed-remediation) shows how to leverage [Cloud Asset Inventory feeds](https://cloud.google.com/asset-inventory/docs/monitoring-asset-changes) to stream resource changes in real time, and how to programmatically use the feed change notifications for alerting or remediation, via a Cloud Function wired to the feed PubSub queue.
 
-The example's feed tracks changes to Google Compute instances, and the Cloud Function enforces policy compliance on each change so that tags match a set of simple rules. The obious use case is when instance tags are used to scope firewall rules, but the example can easily be adapted to suit different use cases.
+The example's feed tracks changes to Google Compute instances, and the Cloud Function enforces policy compliance on each change so that tags match a set of simple rules. The obvious use case is when instance tags are used to scope firewall rules, but the example can easily be adapted to suit different use cases.
 
 <br clear="left">
 

examples/cloud-operations/adfs/README.md

@@ -13,7 +13,7 @@ Terraform:
 Ansible:
 
 - Installs the required Windows features and joins the computer to the AD domain.
-- Provisions some tests users, groups and group memberships in AD. The data to provision is in the ifles directory of the ad-provisioning ansible role. There is script available in the scripts/ad-provisioning folder that you can use to generate an alternative users or memberships file. 
+- Provisions some tests users, groups and group memberships in AD. The data to provision is in the files directory of the ad-provisioning ansible role. There is script available in the scripts/ad-provisioning folder that you can use to generate an alternative users or memberships file. 
 - Installs AD FS
 
 In addition to this, we also include a Powershell script that facilitates the configuration required for Anthos when authenticating users with AD FS as IdP.
@@ -43,7 +43,7 @@ Once the resources have been created, do the following:
         https://adfs.my-domain.org/adfs/ls/IdpInitiatedSignOn.aspx
 
 2. Enter the username and password of one of the users provisioned. The username has to be in the format: [email protected]
-3. Verify that you have successfuly signed in.
+3. Verify that you have successfully signed in.
 
 Once done testing, you can clean up resources by running `terraform destroy`.
 <!-- BEGIN TFDOC -->

examples/cloud-operations/dns-fine-grained-iam/README.md

@@ -106,7 +106,7 @@ dig app1.svc.example.org +short
 |---|---|:---:|:---:|:---:|
 | [project_id](variables.tf#L29) | Existing project id. | <code>string</code> | ✓ |  |
 | [name](variables.tf#L17) | Arbitrary string used to name created resources. | <code>string</code> |  | <code>&#34;dns-sd-test&#34;</code> |
-| [project_create](variables.tf#L23) | Create project instead ofusing an existing one. | <code>bool</code> |  | <code>false</code> |
+| [project_create](variables.tf#L23) | Create project instead of using an existing one. | <code>bool</code> |  | <code>false</code> |
 | [region](variables.tf#L34) | Compute region used in the example. | <code>string</code> |  | <code>&#34;europe-west1&#34;</code> |
 | [zone_domain](variables.tf#L40) | Domain name used for the DNS zone. | <code>string</code> |  | <code>&#34;svc.example.org.&#34;</code> |
 

examples/cloud-operations/quota-monitoring/README.md

@@ -31,7 +31,7 @@ Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/c
 | [project_id](variables.tf#L35) | Project id that references existing project. | <code>string</code> | ✓ |  |
 | [bundle_path](variables.tf#L17) | Path used to write the intermediate Cloud Function code bundle. | <code>string</code> |  | <code>&#34;.&#47;bundle.zip&#34;</code> |
 | [name](variables.tf#L23) | Arbitrary string used to name created resources. | <code>string</code> |  | <code>&#34;quota-monitor&#34;</code> |
-| [project_create](variables.tf#L29) | Create project instead ofusing an existing one. | <code>bool</code> |  | <code>false</code> |
+| [project_create](variables.tf#L29) | Create project instead of using an existing one. | <code>bool</code> |  | <code>false</code> |
 | [quota_config](variables.tf#L40) | Cloud function configuration. | <code title="object&#40;&#123;&#10;  filters  &#61; list&#40;string&#41;&#10;  projects &#61; list&#40;string&#41;&#10;  regions  &#61; list&#40;string&#41;&#10;&#125;&#41;">object&#40;&#123;&#8230;&#125;&#41;</code> |  | <code title="&#123;&#10;  filters  &#61; null&#10;  projects &#61; null&#10;  regions  &#61; null&#10;&#125;">&#123;&#8230;&#125;</code> |
 | [region](variables.tf#L54) | Compute region used in the example. | <code>string</code> |  | <code>&#34;europe-west1&#34;</code> |
 | [schedule_config](variables.tf#L60) | Schedule timer configuration in crontab format. | <code>string</code> |  | <code>&#34;0 &#42; &#42; &#42; &#42;&#34;</code> |

examples/cloud-operations/vm-migration/README.md

@@ -10,7 +10,7 @@ They are meant to be used as minimal but complete starting points to create migr
 
 <a href="./single-project/" title="M4CE with single project"><img src="./single-project/diagram.png" align="left" width="280px"></a> This [example](./single-project/) implements a simple environment for Migrate for Compute Engine (v5) where both the API backend and the migration target environment are deployed on a single GCP project.
 
-This example represents the easiest sceario to implement a Migrate for Compute Engine (v5) enviroment suitable for small migrations on simple enviroments or for product showcases. 
+This example represents the easiest scenario to implement a Migrate for Compute Engine (v5) environment suitable for small migrations on simple environments or for product showcases. 
 <br clear="left">
 
 ### M4CE with host and target projects

examples/cloud-operations/vm-migration/esxi/README.md

@@ -2,7 +2,7 @@
 
 This example deploys a virtual machine from an OVA image and the security prerequisites to run the Migrate for Compute Engine (v5) [connector](https://cloud.google.com/migrate/compute-engine/docs/5.0/how-to/migrate-connector) on VMWare ESXi.
 
-The example is designed to deploy the M4CE (v5) connector on and existing VMWare environment. The [network configuration](https://cloud.google.com/migrate/compute-engine/docs/5.0/concepts/architecture#migration_architecture) required to allow the communication of the migrate connetor to the GCP API is not included in this example.
+The example is designed to deploy the M4CE (v5) connector on and existing VMWare environment. The [network configuration](https://cloud.google.com/migrate/compute-engine/docs/5.0/concepts/architecture#migration_architecture) required to allow the communication of the migrate connector to the GCP API is not included in this example.
 
 This is the high level diagram:
 
@@ -31,7 +31,7 @@ This sample creates several distinct groups of resources:
 <!-- END TFDOC -->
 ## Manual Steps
 Once this example is deployed a VCenter user has to be created and binded to the M4CE role in order to allow the connector access the VMWare resources.
-The user can be created manually through the VCenter web interface or througt GOV commandline if it is available:
+The user can be created manually through the VCenter web interface or through GOV commandline if it is available:
 ```bash
 export GOVC_URL=<VCENTER_URL> (eg. https://192.168.1.100/sdk)
 export GOVC_USERNAME=<VCENTER_ADMIN_USER> (eg. [email protected])

examples/cloud-operations/vm-migration/host-target-projects/README.md

@@ -27,7 +27,7 @@ This sample creates\updates several distinct groups of resources:
 |---|---|:---:|:---:|:---:|
 | [migration_admin_users](variables.tf#L15) | List of users authorized to create a new M4CE sources and perform all other migration operations, in IAM format | <code>list&#40;string&#41;</code> | ✓ |  |
 | [migration_target_projects](variables.tf#L20) | List of target projects for m4ce workload migrations | <code>list&#40;string&#41;</code> | ✓ |  |
-| [migration_viewer_users](variables.tf#L25) | List of users authorized to retrive information about M4CE in the Google Cloud Console, in IAM format | <code>list&#40;string&#41;</code> |  | <code>&#91;&#93;</code> |
+| [migration_viewer_users](variables.tf#L25) | List of users authorized to retrieve information about M4CE in the Google Cloud Console, in IAM format | <code>list&#40;string&#41;</code> |  | <code>&#91;&#93;</code> |
 | [project_create](variables.tf#L31) | Parameters for the creation of the new project to host the M4CE backend | <code title="object&#40;&#123;&#10;  billing_account_id &#61; string&#10;  parent             &#61; string&#10;&#125;&#41;">object&#40;&#123;&#8230;&#125;&#41;</code> |  | <code>null</code> |
 | [project_name](variables.tf#L40) | Name of an existing project or of the new project assigned as M4CE host project | <code>string</code> |  | <code>&#34;m4ce-host-project-000&#34;</code> |
 

examples/cloud-operations/vm-migration/host-target-sharedvpc/README.md

@@ -2,7 +2,7 @@
 
 This example creates a Migrate for Compute Engine (v5) environment deployed on an host project with multiple [target projects](https://cloud.google.com/migrate/compute-engine/docs/5.0/how-to/enable-services#identifying_your_host_project) and shared VPCs.
 
-The example is designed to implement a M4CE (v5) environment on-top of complex migration landing environment where VMs have to be migrated to multiple target projects. In this example targets are alse service projects for a shared VPC. It also includes the IAM wiring needed to make such scenarios work.
+The example is designed to implement a M4CE (v5) environment on-top of complex migration landing environment where VMs have to be migrated to multiple target projects. In this example targets are also service projects for a shared VPC. It also includes the IAM wiring needed to make such scenarios work.
 
 This is the high level diagram:
 
@@ -29,7 +29,7 @@ This sample creates\update several distinct groups of resources:
 | [migration_admin_users](variables.tf#L15) | List of users authorized to create a new M4CE sources and perform all other migration operations, in IAM format | <code>list&#40;string&#41;</code> | ✓ |  |
 | [migration_target_projects](variables.tf#L20) | List of target projects for m4ce workload migrations | <code>list&#40;string&#41;</code> | ✓ |  |
 | [sharedvpc_host_projects](variables.tf#L45) | List of host projects that share a VPC with the selected target projects | <code>list&#40;string&#41;</code> | ✓ |  |
-| [migration_viewer_users](variables.tf#L25) | List of users authorized to retrive information about M4CE in the Google Cloud Console, in IAM format | <code>list&#40;string&#41;</code> |  | <code>&#91;&#93;</code> |
+| [migration_viewer_users](variables.tf#L25) | List of users authorized to retrieve information about M4CE in the Google Cloud Console, in IAM format | <code>list&#40;string&#41;</code> |  | <code>&#91;&#93;</code> |
 | [project_create](variables.tf#L30) | Parameters for the creation of the new project to host the M4CE backend | <code title="object&#40;&#123;&#10;  billing_account_id &#61; string&#10;  parent             &#61; string&#10;&#125;&#41;">object&#40;&#123;&#8230;&#125;&#41;</code> |  | <code>null</code> |
 | [project_name](variables.tf#L39) | Name of an existing project or of the new project assigned as M4CE host project | <code>string</code> |  | <code>&#34;m4ce-host-project-000&#34;</code> |
 

examples/cloud-operations/vm-migration/single-project/README.md

@@ -1,6 +1,6 @@
 # M4CE(v5) - Single Project
 
-This sample creates a simple M4CE (v5) environment deployed on a signle [host project](https://cloud.google.com/migrate/compute-engine/docs/5.0/how-to/enable-services#identifying_your_host_project).
+This sample creates a simple M4CE (v5) environment deployed on a single [host project](https://cloud.google.com/migrate/compute-engine/docs/5.0/how-to/enable-services#identifying_your_host_project).
 
 The example is designed for quick tests or product demos where it is required to setup a simple and minimal M4CE (v5) environment. It also includes the IAM wiring needed to make such scenarios work.
 
@@ -27,7 +27,7 @@ This sample creates several distinct groups of resources:
 | name | description | type | required | default |
 |---|---|:---:|:---:|:---:|
 | [migration_admin_users](variables.tf#L15) | List of users authorized to create a new M4CE sources and perform all other migration operations, in IAM format | <code>list&#40;string&#41;</code> | ✓ |  |
-| [migration_viewer_users](variables.tf#L20) | List of users authorized to retrive information about M4CE in the Google Cloud Console, in IAM format | <code>list&#40;string&#41;</code> |  | <code>&#91;&#93;</code> |
+| [migration_viewer_users](variables.tf#L20) | List of users authorized to retrieve information about M4CE in the Google Cloud Console, in IAM format | <code>list&#40;string&#41;</code> |  | <code>&#91;&#93;</code> |
 | [project_create](variables.tf#L26) | Parameters for the creation of the new project to host the M4CE backend | <code title="object&#40;&#123;&#10;  billing_account_id &#61; string&#10;  parent             &#61; string&#10;&#125;&#41;">object&#40;&#123;&#8230;&#125;&#41;</code> |  | <code>null</code> |
 | [project_name](variables.tf#L35) | Name of an existing project or of the new project assigned as M4CE host an target project | <code>string</code> |  | <code>&#34;m4ce-host-project-000&#34;</code> |
 | [vpc_config](variables.tf#L41) | Parameters to create a simple VPC on the M4CE project | <code title="object&#40;&#123;&#10;  ip_cidr_range &#61; string,&#10;  region        &#61; string&#10;&#125;&#41;">object&#40;&#123;&#8230;&#125;&#41;</code> |  | <code title="&#123;&#10;  ip_cidr_range &#61; &#34;10.200.0.0&#47;20&#34;,&#10;  region        &#61; &#34;us-west2&#34;&#10;&#125;">&#123;&#8230;&#125;</code> |

examples/data-solutions/cloudsql-multiregion/README.md

@@ -7,7 +7,7 @@ The solution is resilient to a regional outage. To get familiar with the procedu
 The solution will use:
 - VPC with Private Service Access to deploy the instances and VM
 - Cloud SQL - Postgre SQL instanced with Private IP
-- Goocle Cloud Storage bucket to handle database import/export
+- Google Cloud Storage bucket to handle database import/export
 - Google Cloud Engine instance to connect to the Posgre SQL instance
 - Google Cloud NAT to access internet resources
 

examples/data-solutions/cmek-via-centralized-kms/README.md

@@ -23,8 +23,8 @@ This sample creates several distinct groups of resources:
   - One service account for the GGE instance
 - KMS
   - One key ring
-  - One crypto key (Procection level: softwere) for Cloud Engine
-  - One crypto key (Protection level: softwere) for Cloud Storage
+  - One crypto key (Protection level: software) for Cloud Engine
+  - One crypto key (Protection level: software) for Cloud Storage
 - GCE
   - One instance encrypted with a CMEK Cryptokey hosted in Cloud KMS
 - GCS
@@ -41,7 +41,7 @@ This sample creates several distinct groups of resources:
 | [project_kms_name](variables.tf#L27) | Name for the new KMS Project. | <code>string</code> |  | <code>&#34;my-project-kms-001&#34;</code> |
 | [project_service_name](variables.tf#L33) | Name for the new Service Project. | <code>string</code> |  | <code>&#34;my-project-service-001&#34;</code> |
 | [region](variables.tf#L39) | The region where resources will be deployed. | <code>string</code> |  | <code>&#34;europe-west1&#34;</code> |
-| [vpc_ip_cidr_range](variables.tf#L50) | Ip range used in the subnet deployef in the Service Project. | <code>string</code> |  | <code>&#34;10.0.0.0&#47;20&#34;</code> |
+| [vpc_ip_cidr_range](variables.tf#L50) | Ip range used in the subnet deployed in the Service Project. | <code>string</code> |  | <code>&#34;10.0.0.0&#47;20&#34;</code> |
 | [vpc_name](variables.tf#L56) | Name of the VPC created in the Service Project. | <code>string</code> |  | <code>&#34;local&#34;</code> |
 | [vpc_subnet_name](variables.tf#L62) | Name of the subnet created in the Service Project. | <code>string</code> |  | <code>&#34;subnet&#34;</code> |