Merge branch 'master' into master

.github/workflows/tests.yml

@@ -58,7 +58,7 @@ jobs:
         run: |
           mkdir -p ${{ env.TF_PLUGIN_CACHE_DIR }}
           pip install -r tests/requirements.txt
-          pytest -vv tests/doc_examples
+          pytest -vv tests/examples
 
   examples:
     runs-on: ubuntu-latest
@@ -91,7 +91,7 @@ jobs:
         run: |
           mkdir -p ${{ env.TF_PLUGIN_CACHE_DIR }}
           pip install -r tests/requirements.txt
-          pytest -vv tests/examples
+          pytest -vv tests/blueprints
 
   modules:
     runs-on: ubuntu-latest

CHANGELOG.md

@@ -107,7 +107,7 @@ All notable changes to this project will be documented in this file.
 ### TOOLS
 
 - [[#796](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/pull/796)] Remove duplicate path component from doc_examples test names. ([juliocc](https://github.com/juliocc)) <!-- 2022-09-07 09:37:19+00:00 -->
-- [[#794](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/pull/794)] Test documentation examples in the `examples/` folder ([juliocc](https://github.com/juliocc)) <!-- 2022-09-06 19:38:26+00:00 -->
+- [[#794](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/pull/794)] Test documentation examples in the `blueprints/` folder ([juliocc](https://github.com/juliocc)) <!-- 2022-09-06 19:38:26+00:00 -->
 - [[#788](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/pull/788)] fix yaml quotes for merge-pr workflow ([drebes](https://github.com/drebes)) <!-- 2022-08-31 13:47:33+00:00 -->
 - [[#763](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/pull/763)] Changelog generator ([ludoo](https://github.com/ludoo)) <!-- 2022-08-02 09:45:06+00:00 -->
 - [[#762](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/pull/762)] Update changelog on pull request merge ([ludoo](https://github.com/ludoo)) <!-- 2022-07-30 17:04:00+00:00 -->
@@ -145,7 +145,7 @@ All notable changes to this project will be documented in this file.
 - **incompatible change** the variable for PSA ranges in the `net-vpc` module has changed to support configuring peering routes
 - fix permadiff in `net-vpc-firewall` module rules
 - new [gke-hub](modules/gke-hub) module
-- new [unmanaged-instances-healthcheck](examples/cloud-operations/unmanaged-instances-healthcheck) example
+- new [unmanaged-instances-healthcheck](blueprints/cloud-operations/unmanaged-instances-healthcheck) example
 - add support for IAM to `data-catalog-policy-tag` module
 - add support for IAM additive to `folder` module, fixes #580
 - optionally turn off gcplogs driver in COS modules
@@ -164,12 +164,12 @@ All notable changes to this project will be documented in this file.
 - **incompatible change** the variables for host and service Shared VPCs have changed in the project module
 - **incompatible change** the variable for service identities IAM has changed in the project factory
 - add `data-catalog-policy-tag` module
-- new [workload identity federetion example](examples/cloud-operations/workload-identity-federation)
+- new [workload identity federetion example](blueprints/cloud-operations/workload-identity-federation)
-- new `api-gateway` [module](./modules/api-gateway) and [example](examples/serverless/api-gateway).
+- new `api-gateway` [module](./modules/api-gateway) and [example](blueprints/serverless/api-gateway).
 - **incompatible change** the `psn_ranges` variable has been renamed to `psa_ranges` in the `net-vpc` module and its type changed from `list(string)` to `map(string)`
 - **incompatible change** removed `iam` flag for organization and folder level sinks
 - **incompatible change** removed `ingress_settings` configuration option in the `cloud-functions` module.
-- new [m4ce VM example](examples/cloud-operations/vm-migration/)
+- new [m4ce VM example](blueprints/cloud-operations/vm-migration/)
 - Support for resource management tags in the `organization`, `folder`, `project`, `compute-vm`, and `kms` modules
 - new [data platform](fast/stages/03-data-platform) stage 3
 - new [02-networking-nva](fast/stages/02-networking-nva) networking stage
@@ -186,7 +186,7 @@ All notable changes to this project will be documented in this file.
 
 - **initial Fabric FAST implementation**
 - new `net-glb` module for Global External Load balancer
-- new `project-factory` module in [`examples/factories`](./examples/factories)
+- new `project-factory` module in [`blueprints/factories`](./blueprints/factories)
 - add missing service identity accounts (artifactregistry, composer) in project module
 - new "Cloud Storage to Bigquery with Cloud Dataflow with least privileges" example
 - support service dependencies for crypto key bindings in project module
@@ -252,7 +252,7 @@ All notable changes to this project will be documented in this file.
 
 ## [7.0.0] - 2021-10-21
 
-- new cloud operations example showing how to deploy infrastructure for [Compute Engine image builder based on Hashicorp Packer](./examples/cloud-operations/packer-image-builder)
+- new cloud operations example showing how to deploy infrastructure for [Compute Engine image builder based on Hashicorp Packer](./blueprints/cloud-operations/packer-image-builder)
 - **incompatible change** the format of the `records` variable in the `dns` module has changed, to better support dynamic values
 - new `naming-convention` module
 - new `cloudsql-instance` module
@@ -277,7 +277,7 @@ All notable changes to this project will be documented in this file.
 - fix `scheduled-asset-inventory-export-bq` module
 - output custom role information from the `organization` module
 - enable multiple `vpc-sc` perimeters over multiple modules
-- new cloud operations example showing how to [restrict service usage using delegated role grants](./examples/cloud-operations/iam-delegated-role-grants)
+- new cloud operations example showing how to [restrict service usage using delegated role grants](./blueprints/cloud-operations/iam-delegated-role-grants)
 - **incompatible change** multiple instance support has been removed from the `compute-vm` module, to bring its interface in line with other modules and enable simple use of `for_each` at the module level; its variables have also slightly changed (`attached_disks`, `boot_disk_delete`, `crate_template`, `zone`)
 - **incompatible change** dropped the `admin_ranges_enabled` variable in `net-vpc-firewall`. Set `admin_ranges = []` to get the same effect
 - added the `named_ranges` variable to `net-vpc-firewall`
@@ -290,8 +290,8 @@ All notable changes to this project will be documented in this file.
 - add support for CMEK keys in Data Foundation end to end example
 - add support for VPC-SC perimeters in Data Foundation end to end example
 - fix `vpc-sc` module
-- new networking example showing how to use [Private Service Connect to call a Cloud Function from on-premises](./examples/networking/private-cloud-function-from-onprem/)
+- new networking example showing how to use [Private Service Connect to call a Cloud Function from on-premises](./blueprints/networking/private-cloud-function-from-onprem/)
-- new networking example showing how to organize [decentralized firewall](./examples/networking/decentralized-firewall/) management on GCP
+- new networking example showing how to organize [decentralized firewall](./blueprints/networking/decentralized-firewall/) management on GCP
 
 ## [5.0.0] - 2021-06-17
 

CONTRIBUTING.md

@@ -66,7 +66,7 @@ Keep in mind we also test documentation examples so even if your PR only changes
 
 ```bash
 # use if you only changed README examples, ignore if you ran all tests
-pytest tests/doc_examples
+pytest tests/examples
 ```
 
 Once everything looks good, add/commit any pending changes then push and open a PR on GitHub. We typically enforce a set of design and style conventions, so please make sure you have familiarized yourself with the following sections and implemented them in your code, to avoid lengthy review cycles.
@@ -535,7 +535,7 @@ locals {
 
 ### Interacting with checks, tests and tools
 
-Our modules are designed for composition and live in a monorepo together with several end-to-end examples, so it was inevitable that over time we found ways of ensuring that a change does not break consumers.
+Our modules are designed for composition and live in a monorepo together with several end-to-end blueprints, so it was inevitable that over time we found ways of ensuring that a change does not break consumers.
 
 Our tests exercise most of the code in the repo including documentation examples, and leverages the [tftest Python library](https://pypi.org/project/tftest/) we developed and independently published on PyPi.
 
@@ -606,14 +606,14 @@ As our testing needs are very simple, we also wanted to reduce the friction requ
 
 The last piece of our testing framework is our [`tftest`](https://pypi.org/project/tftest/) library, which wraps the Terraform executable and returns familiar data structures for most commands.
 
-##### Testing end to end examples
+##### Testing end-to-end examples
 
-Putting it all together, here is how an end-to-end example test works.
+Putting it all together, here is how an end-to-end blueprint test works.
 
 Each example is a Python module in its own directory, and a Terraform fixture that calls the example as a module:
 
 ```bash
-tests/examples/cloud_operations/iam_delegated_role_grants/
+tests/blueprints/cloud_operations/iam_delegated_role_grants/
 ├── fixture
 │   ├── main.tf
 │   └── variables.tf
@@ -637,23 +637,23 @@ The Terraform fixture is a single block that runs the whole example as a module,
 
 ```hcl
 module "test" {
-  source         = "../../../../../examples/cloud-operations/asset-inventory-feed-remediation"
+  source         = "../../../../../blueprints/cloud-operations/asset-inventory-feed-remediation"
   project_create = var.project_create
   project_id     = var.project_id
 }
 ```
 
-You can run this test as part of or entire suite of tests, the examples suite, or individually:
+You can run this test as part of or entire suite of tests, the blueprints suite, or individually:
 
 ```bash
 # run all tests
 pytest
 # only run example tests
-pytest tests/examples
+pytest tests/blueprints
 # only run this example tests
-pytest tests/examples/cloud_operations/iam_delegated_role_grants/
+pytest tests/blueprints/cloud_operations/iam_delegated_role_grants/
 # only run a single unit
-pytest tests/examples/cloud_operations/iam_delegated_role_grants/test_plan.py::test_resources
+pytest tests/blueprints/cloud_operations/iam_delegated_role_grants/test_plan.py::test_resources
 ```
 
 ##### Testing modules
@@ -679,7 +679,7 @@ def test_iam(plan_runner):
 
 #### Testing documentation examples
 
-Most of our documentation examples are also tested via the `doc_examples` test suite. To enable an example for testing just use the special `tftest` comment as the last line in the example, listing the number of modules and resources tested.
+Most of our documentation examples are also tested via the `examples` test suite. To enable an example for testing just use the special `tftest` comment as the last line in the example, listing the number of modules and resources tested.
 
 A few preset variables are available for use, as shown in this example from the `dns` module documentation.
 

README.md

@@ -7,10 +7,10 @@
 
 # Terraform Examples and Modules for Google Cloud
 
-This repository provides **end-to-end examples** and a **suite of Terraform modules** for Google Cloud, which support different use cases:
+This repository provides **end-to-end blueprints** and a **suite of Terraform modules** for Google Cloud, which support different use cases:
 
 - organization-wide [landing zone blueprint](fast/) used to bootstrap real-world cloud foundations
-- reference [examples](./examples/) used to deep dive on network patterns or product features
+- reference [blueprints](./blueprints/) used to deep dive on network patterns or product features
 - a comprehensive source of lean [modules](./modules/dns) that lend themselves well to changes
 
 The whole repository is meant to be cloned as a single unit, and then forked into separate owned repositories to seed production usage, or used as-is and periodically updated as a complete toolkit for prototyping. You can read more on this approach in our [contributing guide](./CONTRIBUTING.md).
@@ -39,6 +39,6 @@ Currently available modules:
 
 For more information and usage examples see each module's README file.
 
-## End-to-end examples
+## End-to-end blueprints
 
-The [examples](./examples/) in this repository are split in several main sections: **[foundational examples](./examples/foundations/)** that bootstrap the organizational hierarchy and automation prerequisites, **[networking examples](./examples/networking/)** that implement core patterns or features, **[data solutions examples](./examples/data-solutions/)** that demonstrate how to integrate data services in complete scenarios, **[cloud operations examples](./examples/cloud-operations/)** that leverage specific products to meet specific operational needs and **[factories](./examples/factories/)** that implement resource factories for the repetitive creation of specific resources.
+The [blueprints](./blueprints/) in this repository are split in several main sections: **[foundational blueprints](./blueprints/foundations/)** that bootstrap the organizational hierarchy and automation prerequisites, **[networking blueprints](./blueprints/networking/)** that implement core patterns or features, **[data solutions blueprints](./blueprints/data-solutions/)** that demonstrate how to integrate data services in complete scenarios, **[cloud operations blueprints](./blueprints/cloud-operations/)** that leverage specific products to meet specific operational needs and **[factories](./blueprints/factories/)** that implement resource factories for the repetitive creation of specific resources.

blueprints/README.md

@@ -1,11 +1,11 @@
-# Terraform end-to-end examples for Google Cloud
+# Terraform end-to-end blueprints for Google Cloud
 
-This section contains **[foundational examples](./foundations/)** that bootstrap the organizational hierarchy and automation prerequisites, **[networking examples](./networking/)** that implement core patterns or features, **[data solutions examples](./data-solutions/)** that demonstrate how to integrate data services in complete scenarios, **[cloud operations examples](./cloud-operations/)** that leverage specific products to meet specific operational needs and **[factories](./factories/)** that implement resource factories for the repetitive creation of specific resources.
+This section contains **[foundational blueprints](./foundations/)** that bootstrap the organizational hierarchy and automation prerequisites, **[networking blueprints](./networking/)** that implement core patterns or features, **[data solutions blueprints](./data-solutions/)** that demonstrate how to integrate data services in complete scenarios, **[cloud operations blueprints](./cloud-operations/)** that leverage specific products to meet specific operational needs and **[factories](./factories/)** that implement resource factories for the repetitive creation of specific resources.
 
-Currently available examples:
+Currently available blueprints:
 
 - **cloud operations** - [Resource tracking and remediation via Cloud Asset feeds](./cloud-operations/asset-inventory-feed-remediation), [Granular Cloud DNS IAM via Service Directory](./cloud-operations/dns-fine-grained-iam), [Granular Cloud DNS IAM for Shared VPC](./cloud-operations/dns-shared-vpc), [Compute Engine quota monitoring](./cloud-operations/quota-monitoring), [Scheduled Cloud Asset Inventory Export to Bigquery](./cloud-operations/scheduled-asset-inventory-export-bq), [Packer image builder](./cloud-operations/packer-image-builder), [On-prem SA key management](./cloud-operations/onprem-sa-key-management), [TCP healthcheck for unmanaged GCE instances](./cloud-operations/unmanaged-instances-healthcheck), [HTTP Load Balancer with Cloud Armor](./cloud-operations/glb_and_armor)
-- **data solutions** - [GCE/GCS CMEK via centralized Cloud KMS](./data-solutions/gcs-to-bq-with-least-privileges/), [Cloud Storage to Bigquery with Cloud Dataflow with least privileges](./data-solutions/gcs-to-bq-with-least-privileges/), [Data Platform Foundations](./data-solutions/data-platform-foundations/), [SQL Server AlwaysOn availability groups example](./data-solutions/sqlserver-alwayson), [Cloud SQL instance with multi-region read replicas](./data-solutions/cloudsql-multiregion/)
+- **data solutions** - [GCE/GCS CMEK via centralized Cloud KMS](./data-solutions/gcs-to-bq-with-least-privileges/), [Cloud Storage to Bigquery with Cloud Dataflow with least privileges](./data-solutions/gcs-to-bq-with-least-privileges/), [Data Platform Foundations](./data-solutions/data-platform-foundations/), [SQL Server AlwaysOn availability groups blueprint](./data-solutions/sqlserver-alwayson), [Cloud SQL instance with multi-region read replicas](./data-solutions/cloudsql-multiregion/)
 - **factories** - [The why and the how of resource factories](./factories/README.md)
 - **foundations** - [single level hierarchy](./foundations/environments/) (environments), [multiple level hierarchy](./foundations/business-units/) (business units + environments)
 - **networking** - [hub and spoke via peering](./networking/hub-and-spoke-peering/), [hub and spoke via VPN](./networking/hub-and-spoke-vpn/), [DNS and Google Private Access for on-premises](./networking/onprem-google-access-dns/), [Shared VPC with GKE support](./networking/shared-vpc-gke/), [ILB as next hop](./networking/ilb-next-hop), [PSC for on-premises Cloud Function invocation](./networking/private-cloud-function-from-onprem/), [decentralized firewall](./networking/decentralized-firewall)

blueprints/cloud-operations/README.md

@@ -0,0 +1,64 @@
+# Operations blueprints
+
+The blueprints in this folder show how to wire together different Google Cloud services to simplify operations, and are meant for testing, or as minimal but sufficiently complete starting points for actual use.
+
+## Resource tracking and remediation via Cloud Asset feeds
+
+<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 [blueprint](./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 blueprint'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 blueprint can easily be adapted to suit different use cases.
+
+<br clear="left">
+
+## Scheduled Cloud Asset Inventory Export to Bigquery
+
+<a href="./scheduled-asset-inventory-export-bq" title="Scheduled Cloud Asset Inventory Export to Bigquery"><img src="./scheduled-asset-inventory-export-bq/diagram.png" align="left" width="280px"></a> This [blueprint](./scheduled-asset-inventory-export-bq) shows how to leverage the [Cloud Asset Inventory Exporting to Bigquery](https://cloud.google.com/asset-inventory/docs/exporting-to-bigquery) feature, to keep track of your organization's assets over time storing information in Bigquery. Data stored in Bigquery can then be used for different purposes like dashboarding or analysis.
+
+<br clear="left">
+
+## Granular Cloud DNS IAM via Service Directory
+
+<a href="./dns-fine-grained-iam" title="Fine-grained Cloud DNS IAM with Service Directory"><img src="./dns-fine-grained-iam/diagram.png" align="left" width="280px"></a> This [blueprint](./dns-fine-grained-iam) shows how to leverage [Service Directory](https://cloud.google.com/blog/products/networking/introducing-service-directory) and Cloud DNS Service Directory private zones, to implement fine-grained IAM controls on DNS. The blueprint creates a Service Directory namespace, a Cloud DNS private zone that uses it as its authoritative source, service accounts with different levels of permissions, and VMs to test them.
+
+<br clear="left">
+
+## Granular Cloud DNS IAM for Shared VPC
+
+<a href="./dns-shared-vpc" title="Fine-grained Cloud DNS IAM via Shared VPC"><img src="./dns-shared-vpc/diagram.png" align="left" width="280px"></a> This [blueprint](./dns-shared-vpc) shows how to create reusable and modular Cloud DNS architectures, by provisioning dedicated Cloud DNS instances for application teams that want to manage their own DNS records, and configuring DNS peering to ensure name resolution works in a common Shared VPC.
+
+<br clear="left">
+
+## Compute Engine quota monitoring
+
+<a href="./quota-monitoring" title="Compute Engine quota monitoring"><img src="./quota-monitoring/diagram.png" align="left" width="280px"></a> This [blueprint](./quota-monitoring) shows a practical way of collecting and monitoring [Compute Engine resource quotas](https://cloud.google.com/compute/quotas) via Cloud Monitoring metrics as an alternative to the recently released [built-in quota metrics](https://cloud.google.com/monitoring/alerts/using-quota-metrics). A simple alert on quota thresholds is also part of the blueprint.
+
+<br clear="left">
+
+## Delegated Role Grants
+
+<a href="./iam-delegated-role-grants" title="Delegated Role Grants"><img src="./iam-delegated-role-grants/diagram.png" align="left" width="280px"></a> This [blueprint](./iam-delegated-role-grants) shows how to use delegated role grants to restrict service usage.
+
+<br clear="left">
+
+## Packer image builder
+
+<a href="./packer-image-builder" title="Packer image builder"><img src="./packer-image-builder/diagram.png" align="left" width="280px"></a> This [blueprint](./packer-image-builder) shows how to deploy infrastructure for a Compute Engine image builder based on [Hashicorp's Packer tool](https://www.packer.io).
+
+<br clear="left">
+
+## On-prem Service Account key management
+
+
+This [blueprint](./onprem-sa-key-management) shows how to manage IAM Service Account Keys by manually generating a key pair and uploading the public part of the key to GCP.
+
+<br clear="left">
+
+## Migrate for Compute Engine (v5)
+<a href="./vm-migration" title="Packer image builder"><img src="./vm-migration/host-target-projects/diagram.png" align="left" width="280px"></a> This set of [blueprints](./vm-migration) shows how to deploy Migrate for Compute Engine (v5) on top of existing Cloud Foundations on different scenarios. An blueprint on how to deploy the M4CE connector on VMWare ESXi is also part of the blueprints.
+
+<br clear="left">
+
+## TCP healthcheck for unmanaged GCE instances
+<a href="./unmanaged-instances-healthcheck" title="Unmanaged GCE Instance healthchecker"><img src="./unmanaged-instances-healthcheck/diagram.png" align="left" width="280px"></a> This [blueprint](./unmanaged-instances-healthcheck) shows how to leverage [Serverless VPC Access](https://cloud.google.com/vpc/docs/configure-serverless-vpc-access) and Cloud Functions to organize a highly performant TCP healtheck for unmanaged GCE instances.
+
+<br clear="left">

blueprints/cloud-operations/adfs/README.md

@@ -1,6 +1,6 @@
 # AD FS
 
-This example does the following: 
+This blueprint does the following: 
 
 Terraform:
 
@@ -18,13 +18,13 @@ Ansible:
 
 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.
 
-The diagram below depicts the architecture of the example:
+The diagram below depicts the architecture of the blueprint:
 
 ![Architecture](architecture.png)
 
-## Running the example
+## Running the blueprint
 
-Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fadfs), then go through the following steps to create resources:
+Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fadfs), then go through the following steps to create resources:
 
 * `terraform init`
 * `terraform apply -var project_id=my-project-id -var ad_dns_domain_name=my-domain.org -var adfs_dns_domain_name=adfs.my-domain.org`
@@ -36,7 +36,7 @@ Once the resources have been created, do the following:
 
         ansible-playbook playbook.yaml
 
-# Testing the example
+# Testing the blueprint
 
 1. In your browser open the following URL:
 

blueprints/cloud-operations/asset-inventory-feed-remediation/README.md

@@ -1,6 +1,6 @@
 # Cloud Asset Inventory feeds for resource change tracking and remediation
 
-This example 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 react to changes by wiring a Cloud Function to the feed outputs.
+This blueprint 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 react to changes by wiring a Cloud Function to the feed outputs.
 
 The Cloud Function can then be used for different purposes:
 
@@ -9,36 +9,36 @@ The Cloud Function can then be used for different purposes:
 - adapting the configuration of separate related resources
 - implementing remediation steps that enforce policy compliance by tweaking or reverting the changes.
 
-A [companion Medium article](https://medium.com/google-cloud/using-cloud-asset-inventory-feeds-for-dynamic-configuration-and-policy-enforcement-c37b6a590c49) has been published for this example, refer to it for more details on the context and the specifics of running the example.
+A [companion Medium article](https://medium.com/google-cloud/using-cloud-asset-inventory-feeds-for-dynamic-configuration-and-policy-enforcement-c37b6a590c49) has been published for this blueprint, refer to it for more details on the context and the specifics of running the blueprint.
 
-This example shows a simple remediation use case: how to enforce policies on instance tags and revert non-compliant changes in near-real time, thus adding an additional measure of control when using tags for firewall rule scoping. Changing the [monitored asset](https://cloud.google.com/asset-inventory/docs/supported-asset-types) and the function logic allows simple adaptation to other common use cases:
+This blueprint shows a simple remediation use case: how to enforce policies on instance tags and revert non-compliant changes in near-real time, thus adding an additional measure of control when using tags for firewall rule scoping. Changing the [monitored asset](https://cloud.google.com/asset-inventory/docs/supported-asset-types) and the function logic allows simple adaptation to other common use cases:
 
 - enforcing a centrally defined Cloud Armor policy in backend services
 - creating custom DNS records for instances or forwarding rules
 
-The example uses a single project for ease of testing, in actual use a few changes are needed to operate at the resource hierarchy level:
+The blueprint uses a single project for ease of testing, in actual use a few changes are needed to operate at the resource hierarchy level:
 
 - the feed should be set at the folder or organization level
 - the custom role used to assign tag changing permissions should be defined at the organization level
 - the role binding that grants the custom role to the Cloud Function service account should be set at the same level as the feed (folder or organization)
 
-The resources created in this example are shown in the high level diagram below:
+The resources created in this blueprint are shown in the high level diagram below:
 
 <img src="diagram.png" width="640px">
 
 
-## Running the example
+## Running the blueprint
 
-Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fasset-inventory-feed-remediation), then go through the following steps to create resources:
+Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fasset-inventory-feed-remediation), then go through the following steps to create resources:
 
 - `terraform init`
 - `terraform apply -var project_id=my-project-id`
 
 Once done testing, you can clean up resources by running `terraform destroy`. To persist state, check out the `backend.tf.sample` file.
 
-## Testing the example
+## Testing the blueprint
 
-The terraform outputs generate preset `gcloud` commands that you can copy and run in the console, to complete configuration and test the example:
+The terraform outputs generate preset `gcloud` commands that you can copy and run in the console, to complete configuration and test the blueprint:
 
 - `subscription_pull` shows messages in the PubSub queue, to check feed message format if the Cloud Function is disabled
 - `cf_logs` shows Cloud Function logs to check that remediation works

blueprints/cloud-operations/binauthz/README.md

@@ -1,8 +1,8 @@
 # Binary Authorization
 
-The following example shows to how to create a CI and a CD pipeline in Cloud Build for the deployment of an application to a private GKE cluster with unrestricted access to a public endpoint. The example enables a Binary Authorization policy in the project so only images that have been attested can be deployed to the cluster. The attestations are created using a cryptographic key pair that has been provisioned in KMS.
+The following blueprint shows to how to create a CI and a CD pipeline in Cloud Build for the deployment of an application to a private GKE cluster with unrestricted access to a public endpoint. The blueprint enables a Binary Authorization policy in the project so only images that have been attested can be deployed to the cluster. The attestations are created using a cryptographic key pair that has been provisioned in KMS.
 
-The diagram below depicts the architecture used in the example.
+The diagram below depicts the architecture used in the blueprint.
 
 ![Architecture](diagram.png)
 
@@ -15,16 +15,16 @@ The CI pipeline does the following:
 
 The CD pipeline deploys the application to the cluster.
 
-## Running the example
+## Running the blueprint
 
-Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fbinauthz), then go through the following steps to create resources:
+Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fbinauthz), then go through the following steps to create resources:
 
 * `terraform init`
 * `terraform apply -var project_id=my-project-id`
 
-WARNING: The example requires the activation of the Binary Authorization API. That API does not support authentication with user credentials. A service account will need to be used to run the example
+WARNING: The blueprint requires the activation of the Binary Authorization API. That API does not support authentication with user credentials. A service account will need to be used to run the blueprint
 
-## Testing the example
+## Testing the blueprint
 
 Once the resources have been created, do the following to verify that everything works as expected.
 

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

@@ -1,28 +1,28 @@
 # Fine-grained Cloud DNS IAM via Service Directory
 
-This example shows how to leverage [Service Directory](https://cloud.google.com/blog/products/networking/introducing-service-directory) and Cloud DNS Service Directory private zones, to implement fine-grained IAM controls on DNS by
+This blueprint shows how to leverage [Service Directory](https://cloud.google.com/blog/products/networking/introducing-service-directory) and Cloud DNS Service Directory private zones, to implement fine-grained IAM controls on DNS by
 
 - creating a Service Directory namespace with two services and their endpoints
 - creating a Cloud DNS private zone that uses the namespace as its authoritative source
 - creating two service accounts and assigning them the `roles/servicedirectory.editor` role on the namespace and on one service respectively
 - creating two VMs and setting them to use the two service accounts, so that DNS queries and `gcloud` commands can be used to verify the setup
 
-The resources created in this example are shown in the high level diagram below:
+The resources created in this blueprint are shown in the high level diagram below:
 
 <img src="diagram.png" width="640px">
 
-A [companion Medium article](https://medium.com/google-cloud/fine-grained-cloud-dns-iam-via-service-directory-446058b4362e) has been published for this example, you can refer to it for more details on the context, and the specifics of running the example.
+A [companion Medium article](https://medium.com/google-cloud/fine-grained-cloud-dns-iam-via-service-directory-446058b4362e) has been published for this blueprint, you can refer to it for more details on the context, and the specifics of running the blueprint.
 
-## Running the example
+## Running the blueprint
 
-Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fdns-fine-grained-iam&cloudshell_open_in_editor=cloudshell_open%2Fcloud-foundation-fabric%2Fexamples%2Fcloud-operations%2Fdns-fine-grained-iam%2Fvariables.tf), then go through the following steps to create resources:
+Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fdns-fine-grained-iam&cloudshell_open_in_editor=cloudshell_open%2Fcloud-foundation-fabric%2Fblueprints%2Fcloud-operations%2Fdns-fine-grained-iam%2Fvariables.tf), then go through the following steps to create resources:
 
 - `terraform init`
 - `terraform apply -var project_id=my-project-id`
 
 Once done testing, you can clean up resources by running `terraform destroy`. To persist state, check out the `backend.tf.sample` file.
 
-## Testing the example
+## Testing the blueprint
 
 The terraform outputs generate preset `gcloud compute ssh` commands that you can copy and run in the console to connect to each VM. Remember to adapt the testing commands below if you changed the default values for the `name`, `region`, or `zone_domain` variables.
 

blueprints/cloud-operations/dns-shared-vpc/README.md

@@ -2,18 +2,18 @@
 
 ## Usage
 
-This example shows how to create reusable and modular Cloud DNS architectures when using Shared VPC.
+This blueprint shows how to create reusable and modular Cloud DNS architectures when using Shared VPC.
 
 The goal is to provision dedicated Cloud DNS instances for application teams that want to manage their own DNS records, and configure DNS peering to ensure name resolution works in a common Shared VPC.
 
-The example will:
+The blueprint will:
 
 - Create a GCP project per application team based on the `teams` input variable
 - Create a VPC and Cloud DNS instance per application team
 - Create a Cloud DNS private zone per application team in the form of `[teamname].[dns_domain]`, with `teamname` and `dns_domain` based on input variables
 - Configure DNS peering for each private zone from the Shared VPC to the DNS VPC of each application team
 
-The resources created in this example are shown in the high level diagram below:
+The resources created in this blueprint are shown in the high level diagram below:
 
 <img src="diagram.png" width="640px">
 

blueprints/cloud-operations/glb_and_armor/README.md

@@ -42,7 +42,7 @@ Pricing Estimates - We have created a sample estimate based on some usage we see
 
 ## Setup
 
-This solution assumes you already have a project created and set up where you wish to host these resources. If not, and you would like for the project to create a new project as well,  please refer to the [github repository](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/tree/master/examples/data-solutions/gcs-to-bq-with-least-privileges) for instructions.
+This solution assumes you already have a project created and set up where you wish to host these resources. If not, and you would like for the project to create a new project as well,  please refer to the [github repository](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/tree/master/blueprints/data-solutions/gcs-to-bq-with-least-privileges) for instructions.
 
 ### Prerequisites
 
@@ -77,7 +77,7 @@ Before we deploy the architecture, you will need the following information:
 1. After cloning the repo, and going through the prerequisites, head back to the cloud shell editor.
 2. Make sure you’re in the following directory. if not, you can change your directory to it via the ‘cd’ command:
 
-       cloudshell_open/cloud-foundation-fabric/examples/cloud-operations/glb_and_armor
+       cloudshell_open/cloud-foundation-fabric/blueprints/cloud-operations/glb_and_armor
 
 3. Run the following command to initialize the terraform working directory:
 

blueprints/cloud-operations/iam-delegated-role-grants/README.md

@@ -1,13 +1,13 @@
 # Delegated Role Grants
 
-This example shows two applications of [delegated role grants](https://cloud.google.com/iam/docs/setting-limits-on-granting-roles):
+This blueprint shows two applications of [delegated role grants](https://cloud.google.com/iam/docs/setting-limits-on-granting-roles):
 
 - how to use them to restrict service usage in a GCP project
 - how to use them to allow administrative access to a service via a predefined role, while restricting administrators from minting other admins.
 
 ## Restricting service usage
 
-In its default configuration, the example provisions two sets of permissions:
+In its default configuration, the blueprint provisions two sets of permissions:
 
 - the roles listed in `direct_role_grants` will be granted unconditionally to the users listed in `project_administrators`.
 - additionally, `project_administrators` will be granted the role `roles/resourcemanager.projectIamAdmin` in a restricted fashion, allowing them to only grant the roles listed in `delegated_role_grants` to other users.
@@ -19,13 +19,13 @@ This diagram shows the resources and expected behaviour:
 <img src="diagram.png" width="572px">
 
 
-A [Medium article](https://medium.com/@jccb/managing-gcp-service-usage-through-delegated-role-grants-a843610f2226) has been published for this example, refer to it for more details on the context and the specifics of running the example.
+A [Medium article](https://medium.com/@jccb/managing-gcp-service-usage-through-delegated-role-grants-a843610f2226) has been published for this blueprint, refer to it for more details on the context and the specifics of running the blueprint.
 
 ## Restricting a predefined role
 
-By changing the `restricted_role_grant`, the example can be used to grant administrators a predefined role like `roles/compute.networkAdmin`, which allows setting IAM policies on service resources like subnetworks, but restrict the roles that those administrators are able to confer to other users.
+By changing the `restricted_role_grant`, the blueprint can be used to grant administrators a predefined role like `roles/compute.networkAdmin`, which allows setting IAM policies on service resources like subnetworks, but restrict the roles that those administrators are able to confer to other users.
 
-You can easily configure the example for this use case:
+You can easily configure the blueprint for this use case:
 
 ```hcl
 # terraform.tfvars
@@ -40,9 +40,9 @@ This diagram shows the resources and expected behaviour:
 
 <img src="diagram-2.png" width="572px">
 
-## Running the example
+## Running the blueprint
 
-Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fiam-delegated-role-grants), then go through the following steps to create resources:
+Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fiam-delegated-role-grants), then go through the following steps to create resources:
 
 - `terraform init`
 - `terraform apply -var project_id=my-project-id 'project_administrators=["user:project-admin@example.com"]'`
@@ -51,7 +51,7 @@ Once done testing, you can clean up resources by running `terraform destroy`.
 
 ## Auditing Roles
 
-This example includes a python script that audits a list of roles to ensure you're not granting the `setIamPolicy` permission at the project, folder or organization level. To audit all the predefined compute roles, run it like this:
+This blueprint includes a python script that audits a list of roles to ensure you're not granting the `setIamPolicy` permission at the project, folder or organization level. To audit all the predefined compute roles, run it like this:
 
 ```bash
 pip3 install -r requirements.txt

blueprints/cloud-operations/multi-cluster-mesh-gke-fleet-api/README.md

@@ -1,8 +1,8 @@
 # Multi-cluster mesh on GKE (fleet API)
 
-The following example shows how to create a multi-cluster mesh for two private clusters on GKE. Anthos Service Mesh with automatic control plane management is set up for clusters using the Fleet API. This can only be done if the clusters are in a single project and in the same VPC. In this particular case both clusters having being deployed to different subnets in a shared VPC. 
+The following blueprint shows how to create a multi-cluster mesh for two private clusters on GKE. Anthos Service Mesh with automatic control plane management is set up for clusters using the Fleet API. This can only be done if the clusters are in a single project and in the same VPC. In this particular case both clusters having being deployed to different subnets in a shared VPC. 
 
-The diagram below depicts the architecture of the example.
+The diagram below depicts the architecture of the blueprint.
 
 ![Architecture](architecture.png)
 
@@ -22,9 +22,9 @@ Ansible is used to execute commands in the management VM. From this VM there is
 10. Deploy a sleep service in both clusters.
 11. Send requests from a sleep pod to the hello-world service from both clusters, to verify that we get responses from alternative versions.
 
-## Running the example
+## Running the blueprint
 
-Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fmulti-cluster-mesh-gke-fleet-api), then go through the following steps to create resources:
+Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=blueprints%2Fcloud-operations%2Fmulti-cluster-mesh-gke-fleet-api), then go through the following steps to create resources:
 
 * `terraform init`
 * `terraform apply -var billing_account_id=my-billing-account-id -var parent=folders/my-folder-id -var host_project_id=my-host-project-id -var fleet_project_id=my-fleet-project-id -var mgmt_project_id=my-mgmt-project-id`
@@ -40,7 +40,7 @@ Once terraform completes do the following:
         ansible-playbook -v playbook.yaml
 
 
-## Testing the example
+## Testing the blueprint
 
 The last two commands executed with Ansible Send requests from a sleep pod to the hello-world service from both clusters. If you see in the output of those two commands responses from alternative versions, everything works as expected.