Nstrelkova/small readme fixes (#2584)

* typo (old rename of 00-bootstrap to 0-bootstrap) * resman purpose: not org policies, but tags * GCVE: several typos --------- Co-authored-by: Natalia Strelkova <[email protected]>
GoogleCloudPlatform · Sep 19, 2024 · 923a1e4 · 923a1e4
1 parent 0f28d26
commit 923a1e4
Show file tree

Hide file tree

Showing 4 changed files with 5 additions and 5 deletions.
diff --git a/blueprints/gcve/pc-minimal/README.md b/blueprints/gcve/pc-minimal/README.md
@@ -30,13 +30,13 @@ Based on our GCP best practices, a GCVE private cloud relies on user groups to a
 
 ### Network
 
-This blueprints expects the user to provision a VPC upfront, either from one of the FAST networking stages (e.g. [Networking with separated single environment](../../../fast/stages/2-networking-c-separate-envs)) or from an external source.
+This blueprint expects the user to provision a VPC upfront, either from one of the FAST networking stages (e.g. [Networking with separated single environment](../../../fast/stages/2-networking-c-separate-envs)) or from an external source.
 The blueprint can optionally configure the [VMware Engine Network peering](https://cloud.google.com/vmware-engine/docs/networking/peer-vpc-network) on the peer VPC by granting the following permissions on the project that hosts the VPC:
 - vmwareengine.networkPeerings.create
 - vmwareengine.networkPeerings.get
 - vmwareengine.networkPeerings.list
 - vmwareengine.operations.get
-The permissions can be assigned through the predefined role *vmwareengine.vmwareengineAdmin*. Anyway the creation of a dedicated custom roile is strogly recommended to comply with the least privilege principle.
+The permissions can be assigned through the predefined role *vmwareengine.vmwareengineAdmin*. The creation of a dedicated custom role is strongly recommended anyway to comply with the least privilege principle.
 
 ## Basic usage
 

diff --git a/fast/stages/1-resman/README.md b/fast/stages/1-resman/README.md
@@ -3,7 +3,7 @@
 This stage performs two important tasks:
 
 - create the top-level hierarchy of folders, and the associated resources used later on to automate each part of the hierarchy (eg. Networking)
-- set organization policies on the organization, and any exception required on specific folders
+- configure resource management tags used in scoping specific IAM roles on the resource hierarchy
 
 The code is intentionally simple, as it's intended to provide a generic initial setup (Networking, Security, etc.), and then allow easy customizations to complete the implementation of the intended hierarchy design.
 

diff --git a/fast/stages/3-gcve/prod/README.md b/fast/stages/3-gcve/prod/README.md
@@ -1,6 +1,6 @@
 # GCVE Private Clouds for Production Environment
 
-This stage provides the Terraform content for the creation and management of multiple GCVE private clouds which are connected to an existing network. The network infrastructure needs to be deployed before executing this stage by executing the respective Fabric FAST stage (`2-networking-*`). This stage can be replicated for complex GCVE designs requiring a separate management of the network infrastructure (VEN) and the access domain or for other constraints which make you decide to have independent GCVE environments (e.g dev/prod, region or team  serparation).
+This stage provides the Terraform content for the creation and management of multiple GCVE private clouds which are connected to an existing network. The network infrastructure needs to be deployed before executing this stage by executing the respective Fabric FAST stage (`2-networking-*`). This stage can be replicated for complex GCVE designs requiring a separate management of the network infrastructure (VEN) and the access domain or for other constraints which make you decide to have independent GCVE environments (e.g dev/prod, region or team separation).
 
 ## Design overview and choices
 

diff --git a/fast/stages/README.md b/fast/stages/README.md
@@ -9,7 +9,7 @@ When combined together, each stage is designed to leverage the previous stage's
 This has two important consequences
 
 - any stage can be swapped out and replaced by different code as long as it respects the contract by providing a predefined set of outputs and optionally accepting a predefined set of variables
-- data flow between stages can be partially automated (see [stage 00 documentation on output files](./0-bootstrap/README.md#output-files-and-cross-stage-variables)), reducing the effort and pain required to compile variables by hand
+- data flow between stages can be partially automated (see [stage 0 documentation on output files](./0-bootstrap/README.md#output-files-and-cross-stage-variables)), reducing the effort and pain required to compile variables by hand
 
 One important assumption is that the flow of data is always forward looking, so no stage needs to depend on outputs generated further down the chain. This greatly simplifies both the logic and the implementation, and allows stages to be effectively independent.