Apply suggestions from code review

Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>

website/docs/cli/cloud/command-line-arguments.html.md

@@ -10,18 +10,17 @@ When your configuration includes a `cloud` block, commands that
 make local modifications to Terraform state and then push them back up to the remote workspace
 accept the following option to modify that behavior:
 
-* `-ignore-remote-version` - Override checking that the local and remote
+- `-ignore-remote-version` - Override checking that the local and remote
   Terraform versions agree, making an operation proceed even when there is
   a mismatch.
 
-    Normally state-modification operations require using a local version of
+    State-modification operations usually require using a local version of the
     Terraform CLI that is compatible with the Terraform version selected
-    for the remote workspace as part of its settings. This is to avoid the
+    in the remote workspace settings. This prevents the
-    local operation creating a new state snapshot that the workspace's
+    local operation from creating a new state snapshot that the workspace's
-    remote execution environment would then be unable to decode.
+    remote execution environment cannot decode.
 
-    Overriding this check can result in a Terraform Cloud workspace that is no
+    We recommend against using this option unless absolutely necessary. Overriding this check can result 
-    longer able to complete remote operations with the currently selected
+     in a Terraform Cloud workspace that is no longer able to complete remote operations with the currently 
-    version of Terraform, so we recommend against using this option unless
+     selected version of Terraform.
-    absolutely necessary.
 

website/docs/cli/cloud/index.html.md

@@ -12,15 +12,9 @@ Using Terraform Cloud through the command line is called the [CLI-driven run wor
 Workspaces can also be configured for local execution, in which case only state is stored in
 Terraform Cloud. In this mode, Terraform Cloud behaves just like a standard state backend.
 
--> **Note:** The Cloud integration for Terraform was added in Terraform 1.1.0; for previous
+-> **Note:** The CLI integration is available in Terraform 1.1.0 and later, and Terraform Enterprise 202201-1 and later. Previous versions can use the [`remote` backend](/docs/language/settings/backends/remote.html). Refer to [Migrating from the remote
-versions, see the [remote backend documentation](/docs/language/settings/backends/remote.html). See
+backend](/docs/cli/cloud/migrating.html) for details about switching to the CLI integration.
-also: [Migrating from the remote
-backend](/docs/cli/cloud/migrating.html)
 
--> **Note:** This integration supports Terraform Enterprise as well. Throughout all the
-documentation, the platform will be referred to as Terraform Cloud, with any Terraform
-Enterprise-specific details explicitly stated. The minimum required version of Terraform Enterprise
-is 202201-1.
 
 ## Documentation Summary
 

website/docs/cli/cloud/migrating.html.md

@@ -5,7 +5,7 @@ page_title: "Initializing and Migrating to Terraform Cloud - Terraform CLI"
 
 # Initializing and Migrating
 
-After [configuring Terraform Cloud settings](/docs/cli/cloud/settings.html) for a working directory, you must run `terraform init` to finish setting up. When running this command, Terraform may guide you through an interactive process where you may choose whether or not you'd like to migrate state from any existing workspaces.
+After [configuring Terraform Cloud settings](/docs/cli/cloud/settings.html) for a working directory, you must run `terraform init` to finish setting up. When running this command, Terraform may guide you through an interactive process where you may choose whether or not to migrate state from any existing workspaces.
 
 There are three potential scenarios:
 
@@ -47,7 +47,7 @@ When switching from the `remote` backend to a `cloud` block, Terraform will cont
 set of Terraform Cloud workspaces. Replace your `backend "remote"` block with an equivalent `cloud`
 block:
 
-- If you were using a single workspace via the `name` argument, change the block
+- If you were using a single workspace with the `name` argument, change the block
   label to `cloud`.
 
     ```diff
@@ -68,8 +68,7 @@ block:
   distinguish the workspaces for your working directory, but a good starting point may be to use
   whatever the prefix was before.
 
-    The existing workspaces don't need to already have these tags — when you
+    The tags you configure do not need to be present on the existing workspaces. When you initialize, Terraform will add the specified tags to the workspaces if necessary.
-    initialize, Terraform will add the specified tags to them.
 
     ```diff
      terraform {

website/docs/cli/cloud/settings.html.md

@@ -43,7 +43,7 @@ The `cloud` block has some special restrictions:
 - A configuration can only provide one `cloud` block.
 - A `cloud` block cannot be used with [state backends](/docs/language/settings/backends/index.html).
   A configuration can use one or the other, but not both.
-- A cloud block cannot refer to named values (like input variables, locals, or
+- A `cloud` block cannot refer to named values (like input variables, locals, or
   data source attributes).
 
 The `cloud` block only affects Terraform CLI's behavior. When Terraform Cloud uses a configuration
@@ -54,10 +54,10 @@ directly - it ignores the block and behaves according to its own workspace setti
 
 The `cloud` block supports the following configuration arguments:
 
-* `organization` - (Required) The name of the organization containing the
+- `organization` - (Required) The name of the organization containing the
   workspace(s) the current configuration should use.
 
-* `workspaces` - (Required) A nested block that specifies which remote Terraform Cloud workspaces to
+- `workspaces` - (Required) A nested block that specifies which remote Terraform Cloud workspaces to
 use for the current configuration. The `workspaces` block must contain **exactly one** of the
 following arguments, each denoting a strategy for how workspaces should be mapped:
 
@@ -67,7 +67,7 @@ following arguments, each denoting a strategy for how workspaces should be mappe
       to switch between them or create new workspaces; new workspaces will automatically have
       the specified tags. This option conflicts with `name`.
 
-    * `name` - (Optional) The name of a single Terraform Cloud workspace. You will
+    - `name` - (Optional) The name of a single Terraform Cloud workspace. You will
       only be able to use the workspace specified in the configuration with this working
       directory, and cannot manage workspaces from the CLI (e.g. `terraform workspace select` or
       `terraform workspace new`). This option conflicts with `tags`.
@@ -75,7 +75,7 @@ following arguments, each denoting a strategy for how workspaces should be mappe
 * `hostname` - (Optional) The hostname of a Terraform Enterprise installation, if using Terraform
   Enterprise. Defaults to Terraform Cloud (app.terraform.io).
 
-* `token` - (Optional) The token used to authenticate with Terraform Cloud.
+- `token` - (Optional) The token used to authenticate with Terraform Cloud.
   We recommend omitting the token from the configuration, and instead using
   [`terraform login`](/docs/cli/commands/login.html) or manually configuring
   `credentials` in the
@@ -89,15 +89,14 @@ paths to exclude from upload by adding a `.terraformignore` file at the root of
 configuration directory. If this file is not present, the upload will exclude
 the following by default:
 
-* `.git/` directories
+- `.git/` directories
-* `.terraform/` directories (exclusive of `.terraform/modules`)
+- `.terraform/` directories (exclusive of `.terraform/modules`)
 
 The rules in `.terraformignore` file resemble the rules allowed in a
 [.gitignore file](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring):
 
-* Comments (starting with `#`) or blank lines are ignored.
+- Comments (starting with `#`) or blank lines are ignored.
-* End a pattern with a forward slash `/` to specify a directory.
+- End a pattern with a forward slash `/` to specify a directory.
-* Negate a pattern by starting it with an exclamation point `!`.
+- Negate a pattern by starting it with an exclamation point `!`.
 
-Note that unlike `.gitignore`, only the `.terraformignore` at the root of the configuration
+-> **Note:** Unlike `.gitignore`, only the `.terraformignore` at the root of the configuration directory is considered.
-directory is considered.

website/docs/language/settings/backends/azurerm.html.md

@@ -11,7 +11,7 @@ description: |-
 
 Stores the state as a Blob with the given Key within the Blob Container within [the Blob Storage Account](https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction).
 
-This backend supports state locking and consistency checking via native capabilities of Azure Blob Storage.
+This backend supports state locking and consistency checking with Azure Blob Storage native capabilities.
 
 -> **Note:** By default the Azure Backend uses ADAL for authentication which is deprecated in favour of MSAL - MSAL can be used by setting `use_microsoft_graph` to `true`. **The default for this will change in Terraform 1.2**, so that MSAL authentication is used by default. 
 

website/docs/language/settings/backends/configuration.html.md

@@ -8,11 +8,8 @@ page_title: "Backend Configuration - Configuration Language"
 Each Terraform configuration can specify a backend, which defines where
 [state](/docs/language/state/index.html) snapshots are stored.
 
-Backend configuration is not needed when using Terraform Cloud, because
+You do not need to configure a backend when using Terraform Cloud because
-Terraform Cloud automatically manages state in the workspaces your configuration
+Terraform Cloud automatically manages state in the workspaces associated with your configuration. If your configuration includes [a `cloud` block](/docs/language/settings/terraform-cloud.html), it cannot include a `backend` block.
-is associated with. If your configuration includes
-[a `cloud` block](/docs/language/settings/terraform-cloud.html),
-it cannot include a `backend` block.
 
 Most non-trivial Terraform configurations store state remotely so that multiple
 people can work with the same infrastructure.

website/docs/language/settings/backends/remote.html.md

@@ -12,14 +12,8 @@ description: |-
 [`cloud` integration](/docs/language/settings/terraform-cloud.html) instead of this backend.
 The `cloud` option includes an improved user experience and more features.
 
--> **Note:** This backend is unique among all other Terraform backends in that it has the ability to
+The remote backend is unique among all other Terraform backends because it can both store state snapshots and execute operations for Terraform Cloud's [CLI-driven run workflow](/docs/cloud/run/cli.html). It used to be called an "enhanced" backend.
-execute operations for Terraform Cloud's [CLI-driven run workflow](/docs/cloud/run/cli.html), rather
-than only store state snapshots. (The documentation used to refer to this as "enhanced" backend
-behavior, but it's simpler to describe it as a quirk of the `remote` backend.)
 
--> **Note:** The remote backend requires Terraform v0.11.13 or newer, and requires either a
-Terraform Cloud account on [app.terraform.io](https://app.terraform.io) or a Terraform Enterprise
-instance (version v201809-1 or newer).
 
 
 When using full remote operations, operations like `terraform plan` or `terraform apply` can be executed in Terraform

website/docs/language/settings/index.html.md

@@ -34,12 +34,10 @@ following sections.
 The nested `cloud` block configures Terraform Cloud for enabling its
 [CLI-driven run workflow](/docs/cloud/run/cli.html).
 
-- For a summary of the `cloud` block's syntax, see 
+- Refer to [Terraform Cloud Configuration](/docs/language/settings/terraform-cloud.html) for a summary of the `cloud` block's syntax.
-[Terraform Cloud Configuration](/docs/language/settings/terraform-cloud.html).
 
-- For more complete details about configuring and using Terraform Cloud with Terraform CLI,
+- Refer to [Using Terraform Cloud](/docs/cli/cloud/index.html) in the
-see [Using Terraform Cloud](/docs/cli/cloud/index.html) in the
+Terraform CLI documentation for complete details about how to initialize and configure the Terraform Cloud CLI integration.
-Terraform CLI documentation.
 
 ## Configuring a Terraform Backend
 

website/docs/language/settings/terraform-cloud.html.md

@@ -8,11 +8,10 @@ description: "The nested `cloud` block configures Terraform's integration with T
 # Terraform Cloud Configuration
 
 The main module of a Terraform configuration can integrate with Terraform Cloud to enable its
-[CLI-driven run workflow](/docs/cloud/run/cli.html). These settings are only needed when
+[CLI-driven run workflow](/docs/cloud/run/cli.html). You only need to configure these settings when you want to use Terraform CLI to interact with Terraform Cloud. Terraform Cloud ignores them when interacting with
-using Terraform CLI to interact with Terraform Cloud, and are ignored when interacting with
+Terraform through version control or the API.
-Terraform Cloud via version control or the API.
 
-Terraform Cloud is configured with a nested `cloud` block within the top-level
+You can configure the Terraform Cloud CLI integration by adding a nested `cloud` block within the top-level
 `terraform` block:
 
 ```hcl
@@ -27,11 +26,6 @@ terraform {
 }
 ```
 
-Using the Cloud integration is mutually exclusive of declaring any [state backend](/docs/language/settings/backends/index.html); that is, a configuration
+You cannot use the CLI integration and a [state backend](/docs/language/settings/backends/index.html) in the same configuration; the are mutually exclusive. A configuration can only provide one `cloud` block and the `cloud` block cannot refer to named values like input variables, locals, or data source attributes.
-can only declare one or the other. Similar to backends...
 
-- A configuration can only provide one cloud block.
+Refer to [Using Terraform Cloud](/docs/cli/cloud/index.html) in the Terraform CLI docs for more information.
-- A cloud block cannot refer to named values (like input variables, locals, or data source attributes).
-
-See [Using Terraform Cloud](/docs/cli/cloud/index.html)
-in the Terraform CLI docs for more information.