Add latest changes from gitlab-org/gitlab@master

16 files changed, 736 insertions, 602 deletions

diff --git a/doc/api/graphql/reference/gitlab_schema.graphql b/doc/api/graphql/reference/gitlab_schema.graphql
index 18031185a18..df136e9c8c0 100644
--- a/doc/api/graphql/reference/gitlab_schema.graphql
+++ b/doc/api/graphql/reference/gitlab_schema.graphql
@@ -5955,7 +5955,7 @@ input DestroySnippetInput {
   """
   The global id of the snippet to destroy
   """
-  id: ID!
+  id: SnippetID!
 }
 
 """
@@ -11576,7 +11576,7 @@ input MarkAsSpamSnippetInput {
   """
   The global id of the snippet to update
   """
-  id: ID!
+  id: SnippetID!
 }
 
 """
@@ -15990,7 +15990,7 @@ type Project {
     """
     Array of global snippet ids, e.g., "gid://gitlab/ProjectSnippet/1"
     """
-    ids: [ID!]
+    ids: [SnippetID!]
 
     """
     Returns the last _n_ elements from the list.
@@ -17036,7 +17036,7 @@ type Query {
     """
     The ID of an author
     """
-    authorId: ID
+    authorId: UserID
 
     """
     Returns the elements in the list that come before the specified cursor.
@@ -17056,7 +17056,7 @@ type Query {
     """
     Array of global snippet ids, e.g., "gid://gitlab/ProjectSnippet/1"
     """
-    ids: [ID!]
+    ids: [SnippetID!]
 
     """
     Returns the last _n_ elements from the list.
@@ -17066,7 +17066,7 @@ type Query {
     """
     The ID of a project
     """
-    projectId: ID
+    projectId: ProjectID
 
     """
     The type of snippet
@@ -19638,7 +19638,7 @@ type Snippet implements Noteable {
   """
   ID of the snippet
   """
-  id: ID!
+  id: SnippetID!
 
   """
   All notes on this noteable
@@ -19916,6 +19916,11 @@ type SnippetEdge {
   node: Snippet
 }
 
+"""
+Identifier of Snippet
+"""
+scalar SnippetID
+
 type SnippetPermissions {
   """
   Indicates the user can perform `admin_snippet` on this resource
@@ -21831,7 +21836,7 @@ input UpdateSnippetInput {
   """
   The global id of the snippet to update
   """
-  id: ID!
+  id: SnippetID!
 
   """
   Title of the snippet
@@ -22139,7 +22144,7 @@ type User {
     """
     Array of global snippet ids, e.g., "gid://gitlab/ProjectSnippet/1"
     """
-    ids: [ID!]
+    ids: [SnippetID!]
 
     """
     Returns the last _n_ elements from the list.
diff --git a/doc/api/graphql/reference/gitlab_schema.json b/doc/api/graphql/reference/gitlab_schema.json
index 56752684541..375bdd036cc 100644
--- a/doc/api/graphql/reference/gitlab_schema.json
+++ b/doc/api/graphql/reference/gitlab_schema.json
@@ -16300,7 +16300,7 @@
                 "name": null,
                 "ofType": {
                   "kind": "SCALAR",
-                  "name": "ID",
+                  "name": "SnippetID",
                   "ofType": null
                 }
               },
@@ -31712,7 +31712,7 @@
                 "name": null,
                 "ofType": {
                   "kind": "SCALAR",
-                  "name": "ID",
+                  "name": "SnippetID",
                   "ofType": null
                 }
               },
@@ -46307,7 +46307,7 @@
                       "name": null,
                       "ofType": {
                         "kind": "SCALAR",
-                        "name": "ID",
+                        "name": "SnippetID",
                         "ofType": null
                       }
                     }
@@ -49373,7 +49373,7 @@
                       "name": null,
                       "ofType": {
                         "kind": "SCALAR",
-                        "name": "ID",
+                        "name": "SnippetID",
                         "ofType": null
                       }
                     }
@@ -49395,7 +49395,7 @@
                   "description": "The ID of an author",
                   "type": {
                     "kind": "SCALAR",
-                    "name": "ID",
+                    "name": "UserID",
                     "ofType": null
                   },
                   "defaultValue": null
@@ -49405,7 +49405,7 @@
                   "description": "The ID of a project",
                   "type": {
                     "kind": "SCALAR",
-                    "name": "ID",
+                    "name": "ProjectID",
                     "ofType": null
                   },
                   "defaultValue": null
@@ -56879,7 +56879,7 @@
                 "name": null,
                 "ofType": {
                   "kind": "SCALAR",
-                  "name": "ID",
+                  "name": "SnippetID",
                   "ofType": null
                 }
               },
@@ -57746,6 +57746,16 @@
           "possibleTypes": null
         },
         {
+          "kind": "SCALAR",
+          "name": "SnippetID",
+          "description": "Identifier of Snippet",
+          "fields": null,
+          "inputFields": null,
+          "interfaces": null,
+          "enumValues": null,
+          "possibleTypes": null
+        },
+        {
           "kind": "OBJECT",
           "name": "SnippetPermissions",
           "description": null,
@@ -63283,7 +63293,7 @@
                 "name": null,
                 "ofType": {
                   "kind": "SCALAR",
-                  "name": "ID",
+                  "name": "SnippetID",
                   "ofType": null
                 }
               },
@@ -64057,7 +64067,7 @@
                       "name": null,
                       "ofType": {
                         "kind": "SCALAR",
-                        "name": "ID",
+                        "name": "SnippetID",
                         "ofType": null
                       }
                     }
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 94171220fad..1eeaab813f1 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -2841,7 +2841,7 @@ Represents a snippet entry.
 | `discussions` | DiscussionConnection! | All discussions on this noteable |
 | `fileName` | String | File Name of the snippet |
 | `httpUrlToRepo` | String | HTTP URL to the snippet repository |
-| `id` | ID! | ID of the snippet |
+| `id` | SnippetID! | ID of the snippet |
 | `notes` | NoteConnection! | All notes on this noteable |
 | `project` | Project | The project the snippet is associated with |
 | `rawUrl` | String! | Raw URL of the snippet |
diff --git a/doc/api/releases/index.md b/doc/api/releases/index.md
index da35caa0811..7c65e9da74b 100644
--- a/doc/api/releases/index.md
+++ b/doc/api/releases/index.md
@@ -584,7 +584,7 @@ Example response:
          "id":53,
          "iid":3,
          "project_id":24,
-         "title":"v1.0",
+         "title":"v1.2",
          "description":"Voluptate fugiat possimus quis quod aliquam expedita.",
          "state":"active",
          "created_at":"2019-09-01T13:00:00.256Z",
diff --git a/doc/ci/pipelines/job_artifacts.md b/doc/ci/pipelines/job_artifacts.md
index 6a9ae0cdaf6..160399e4bc4 100644
--- a/doc/ci/pipelines/job_artifacts.md
+++ b/doc/ci/pipelines/job_artifacts.md
@@ -139,10 +139,10 @@ third party ports for other languages like JavaScript, Python, Ruby, and so on.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207528) in GitLab 13.0.
 > - Requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 and above.
 
-The `terraform` report obtains a Terraform `tfplan.json` file. [JQ processing required to remove credentials](../../user/infrastructure/index.md#output-terraform-plan-information-into-a-merge-request). The collected Terraform
+The `terraform` report obtains a Terraform `tfplan.json` file. [JQ processing required to remove credentials](../../user/infrastructure/mr_integration.md#setup). The collected Terraform
 plan report uploads to GitLab as an artifact and displays
 in merge requests. For more information, see
-[Output `terraform plan` information into a merge request](../../user/infrastructure/index.md#output-terraform-plan-information-into-a-merge-request).
+[Output `terraform plan` information into a merge request](../../user/infrastructure/mr_integration.md).
 
 #### `artifacts:reports:codequality`
 
diff --git a/doc/user/admin_area/approving_users.md b/doc/user/admin_area/approving_users.md
index cc66a0d56d1..430ad4f8899 100644
--- a/doc/user/admin_area/approving_users.md
+++ b/doc/user/admin_area/approving_users.md
@@ -9,7 +9,7 @@ type: howto
 
 > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4491) in GitLab 13.5.
 
-When [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-admin-approval-for-new-sign-ups) is enabled, any user that signs up for an account using the registration form is placed under a **Pending approval** state.
+When [Require admin approval for new sign-ups](settings/sign_up_restrictions.md#require-administrator-approval-for-new-sign-ups) is enabled, any user that signs up for an account using the registration form is placed under a **Pending approval** state.
 
 A user pending approval is functionally identical to a [blocked](blocking_unblocking_users.md) user.
 
diff --git a/doc/user/admin_area/settings/img/disable_signup_v12_7.png b/doc/user/admin_area/settings/img/disable_signup_v12_7.png
deleted file mode 100644
index be1a070a804..00000000000
--- a/doc/user/admin_area/settings/img/disable_signup_v12_7.png
+++ /dev/null
diff --git a/doc/user/admin_area/settings/img/sign_up_restrictions_v13_5.png b/doc/user/admin_area/settings/img/sign_up_restrictions_v13_5.png
deleted file mode 100644
index ebbfad77e69..00000000000
--- a/doc/user/admin_area/settings/img/sign_up_restrictions_v13_5.png
+++ /dev/null
diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md
index a890e8f9ee8..335ddce4e2d 100644
--- a/doc/user/admin_area/settings/sign_up_restrictions.md
+++ b/doc/user/admin_area/settings/sign_up_restrictions.md
@@ -7,49 +7,44 @@ type: reference
 
 # Sign-up restrictions **(CORE ONLY)**
 
-You can use sign-up restrictions to:
+You can enforce the following restrictions on sign ups:
 
-- Disable new sign-ups.
-- Require admin approval for new sign-ups.
+- Disable new sign ups.
+- Require administrator approval for new sign ups.
 - Require user email confirmation.
-- Denylist or allowlist email addresses belonging to specific domains.
+- Allow or deny sign ups using specific email domains.
 
-NOTE: **Note:**
-These restrictions are only applied during sign-up from an external user. An admin can add a user through the admin panel with a disallowed domain. Also, note that the users can change their email addresses after sign-up to
-disallowed domains.
+## Disable new sign ups
 
-## Disable new signups
+By default, any user visiting your GitLab domain can sign up for an account. For customers running
+public-facing GitLab instances, we **highly** recommend that you consider disabling new sign ups if
+you do not expect public users to sign up for an account.
 
-When this setting is enabled, any user visiting your GitLab domain will be able to sign up for an account.
+To disable sign ups:
 
-![Disable signups](img/disable_signup_v12_7.png)
+1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**.
+1. Clear the **Sign-up enabled** checkbox, then select **Save changes**.
 
-You can restrict new users from signing up by themselves for an account in your instance by disabling this setting.
-
-### Recommendations
-
-For customers running public-facing GitLab instances, we highly recommend that you
-consider disabling new sign-ups if you do not expect public users to sign up for an
-account.
-
-Alternatively, you could also consider setting up a
-[allowlist](#allowlist-email-domains) or [denylist](#denylist-email-domains) on
-email domains to prevent malicious users from creating accounts.
-
-## Require admin approval for new sign-ups
+## Require administrator approval for new sign ups
 
 > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4491) in GitLab 13.5.
 
-When this setting is enabled, any user visiting your GitLab domain and signing up for a new account will have to be explicitly [approved](../approving_users.md#approving-a-user) by an administrator before they can start using their account.
+When this setting is enabled, any user visiting your GitLab domain and signing up for a new account must be explicitly [approved](../approving_users.md#approving-a-user) by an administrator before they can start using their account. This setting is only applicable if sign ups are enabled.
+
+To require administrator approval for new sign ups:
 
-![Require admin approval for new signups](img/sign_up_restrictions_v13_5.png)
+1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**.
+1. Select the **Require admin approval for new sign-ups** checkbox, then select **Save changes**.
 
 ## Require email confirmation
 
-You can send confirmation emails during sign-up and require that users confirm
+You can send confirmation emails during sign up and require that users confirm
 their email address before they are allowed to sign in.
 
-![Email confirmation](img/sign_up_restrictions_v13_5.png)
+To enforce confirmation of the email address used for new sign ups:
+
+1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**.
+1. Select the **Enable email restrictions for sign ups** checkbox, then select **Save changes**.
 
 ## Minimum password length limit
 
@@ -58,40 +53,42 @@ their email address before they are allowed to sign in.
 You can [change](../../../security/password_length_limits.md#modify-minimum-password-length-using-gitlab-ui)
 the minimum number of characters a user must have in their password using the GitLab UI.
 
-## Allowlist email domains
+## Allow or deny sign ups using specific email domains
+
+You can specify an inclusive or exclusive list of email domains which can be used for user sign up.
+
+These restrictions are only applied during sign up from an external user. An administrator can add a
+user through the admin panel with a disallowed domain. Also, note that the users can change their
+email addresses to disallowed domains after sign up.
+
+### Allowlist email domains
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/598) in GitLab 7.11.0
 
 You can restrict users only to sign up using email addresses matching the given
 domains list.
 
-## Denylist email domains
+### Denylist email domains
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5259) in GitLab 8.10.
 
-With this feature enabled, you can block email addresses of a specific domain
-from creating an account on your GitLab server. This is particularly useful
-to prevent malicious users from creating spam accounts with disposable email
-addresses.
-
-## Settings
-
-To access this feature:
+You can block users from signing up when using an email addresses of specific domains. This can
+reduce the risk of malicious users creating spam accounts with disposable email addresses.
 
-1. Navigate to the **Admin Area > Settings > General**.
-1. Expand the **Sign-up restrictions** section.
+### Create email domain allowlist or denylist
 
-For the denylist, you can enter the list manually or upload a `.txt` file that
-contains list entries.
+To create an email domain allowlist or denylist:
 
-For the allowlist, you must enter the list manually.
+1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**.
+1. For the allowlist, you must enter the list manually. For the denylist, you can enter the list
+   manually or upload a `.txt` file that contains list entries.
 
-Both the allowlist and denylist accept wildcards. For example, you can use
+   Both the allowlist and denylist accept wildcards. For example, you can use
 `*.company.com` to accept every `company.com` subdomain, or `*.io` to block all
-domains ending in `.io`. Domains should be separated by a whitespace,
+domains ending in `.io`. Domains must be separated by a whitespace,
 semicolon, comma, or a new line.
 
-![Domain Denylist](img/domain_denylist.png)
+   ![Domain Denylist](img/domain_denylist.png)
 
 <!-- ## Troubleshooting
 
diff --git a/doc/user/application_security/coverage_fuzzing/img/coverage_fuzzing_report_v13_6.png b/doc/user/application_security/coverage_fuzzing/img/coverage_fuzzing_report_v13_6.png
new file mode 100644
index 00000000000..b3b0e5def86
--- /dev/null
+++ b/doc/user/application_security/coverage_fuzzing/img/coverage_fuzzing_report_v13_6.png
diff --git a/doc/user/application_security/coverage_fuzzing/index.md b/doc/user/application_security/coverage_fuzzing/index.md
index 0d619659bd1..4c5afcee3d0 100644
--- a/doc/user/application_security/coverage_fuzzing/index.md
+++ b/doc/user/application_security/coverage_fuzzing/index.md
@@ -222,6 +222,34 @@ This essentially creates two steps:
 
 The `covfuzz-ci.yml` is the same as that in the [original synchronous example](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/go-fuzzing-example#running-go-fuzz-from-ci).
 
+## Interacting with the vulnerabilities
+
+After a vulnerability is found, you can [interact with it](../index.md#interacting-with-the-vulnerabilities).
+The merge request widget lists the vulnerability and contains a button for downloading the fuzzing
+artifacts. By clicking one of the detected vulnerabilities, you can see its details.
+
+![Coverage Fuzzing Security Report](img/coverage_fuzzing_report_v13_6.png)
+
+You can also view the vulnerability from the [Security Dashboard](../security_dashboard/index.md),
+which shows an overview of all the security vulnerabilities in your groups, projects, and pipelines.
+
+Clicking the vulnerability opens a modal that provides additional information about the
+vulnerability:
+
+- Status: The vulnerability's status. As with any type of vulnerability, a coverage fuzzing
+  vulnerability can be Detected, Confirmed, Dismissed, or Resolved.
+- Project: The project in which the vulnerability exists.
+- Crash type: The type of crash or weakness in the code. This typically maps to a [CWE](https://cwe.mitre.org/).
+- Crash state: A normalized version of the stacktrace, containing the last three functions of the
+  crash (without random addresses).
+- Stacktrace snippet: The last few lines of the stacktrace, which shows details about the crash.
+- Identifier: The vulnerability's identifier. This maps to either a [CVE](https://cve.mitre.org/)
+  or [CWE](https://cwe.mitre.org/).
+- Severity: The vulnerability's severity. This can be Critical, High, Medium, Low, Info, or Unknown.
+- Scanner: The scanner that detected the vulnerability (for example, Coverage Fuzzing).
+- Scanner Provider: The engine that did the scan. For Coverage Fuzzing, this can be any of the
+  engines listed in [Supported fuzzing engines and languages](#supported-fuzzing-engines-and-languages).
+
 ### Glossary
 
 - Seed corpus: The set of test cases given as initial input to the fuzz target. This usually speeds
diff --git a/doc/user/infrastructure/img/terraform_list_view.png b/doc/user/infrastructure/img/terraform_list_view.png
new file mode 100644
index 00000000000..f1af3225833
--- /dev/null
+++ b/doc/user/infrastructure/img/terraform_list_view.png
diff --git a/doc/user/infrastructure/index.md b/doc/user/infrastructure/index.md
index 9373743bf2c..ed79b819c00 100644
--- a/doc/user/infrastructure/index.md
+++ b/doc/user/infrastructure/index.md
@@ -13,35 +13,7 @@ workflows to tie into GitLab's authentication and authorization. These features
 lowering the barrier to entry for teams to adopt Terraform, collaborate effectively within
 GitLab, and support Terraform best practices.
 
-## Quick Start
-
-Use the following `.gitlab-ci.yml` to set up a simple Terraform project integration
-for GitLab versions 13.5 and greater:
-
-```yaml
-include:
-  - template: Terraform.latest.gitlab-ci.yml
-
-variables:
-  # If not using GitLab's HTTP backend, remove this line and specify TF_HTTP_* variables
-  TF_STATE_NAME: default
-  TF_CACHE_KEY: default
-```
-
-This template uses `.latest.`, instead of stable, and may include breaking changes.
-This template also includes some opinionated decisions, which you can override:
-
-- Including the latest [GitLab Terraform Image](https://gitlab.com/gitlab-org/terraform-images).
-- Using the [GitLab managed Terraform State](#gitlab-managed-terraform-state) as
-  the Terraform state storage backend.
-- Creating [four pipeline stages](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.latest.gitlab-ci.yml):
-  `init`, `validate`, `build`, and `deploy`. These stages
-  [run the Terraform commands](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform/Base.latest.gitlab-ci.yml)
-  `init`, `validate`, `plan`, `plan-json`, and `apply`. The `apply` command only runs on `master`.
-
-## GitLab managed Terraform State
-
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2673) in GitLab 13.0.
+## GitLab Managed Terraform state
 
 [Terraform remote backends](https://www.terraform.io/docs/backends/index.html)
 enable you to store the state file in a remote, shared store. GitLab uses the
@@ -57,517 +29,34 @@ Amazon S3 or Google Cloud Storage. Its features include:
 - Locking and unlocking state.
 - Remote Terraform plan and apply execution.
 
-To get started with a GitLab-managed Terraform State, there are two different options:
-
-- [Use a local machine](#get-started-using-local-development).
-- [Use GitLab CI](#get-started-using-gitlab-ci).
-
-Terraform States can be found by navigating to a Project's **{cloud-gear}** **Operations > Terraform** page.
-
-## Permissions for using Terraform
-
-In GitLab version 13.1, [Maintainer access](../permissions.md) was required to use a
-GitLab managed Terraform state backend. In GitLab versions 13.2 and greater,
-[Maintainer access](../permissions.md) is required to lock, unlock and write to the state
-(using `terraform apply`), while [Developer access](../permissions.md) is required to read
-the state (using `terraform plan -lock=false`).
-
-## Get started using local development
-
-If you plan to only run `terraform plan` and `terraform apply` commands from your
-local machine, this is a simple way to get started:
-
-1. Create your project on your GitLab instance.
-1. Navigate to **Settings > General** and note your **Project name**
-   and **Project ID**.
-1. Define the Terraform backend in your Terraform project to be:
-
-   ```hcl
-   terraform {
-     backend "http" {
-     }
-   }
-   ```
-
-1. Create a [Personal Access Token](../profile/personal_access_tokens.md) with
-   the `api` scope.
-
-1. On your local machine, run `terraform init`, passing in the following options,
-   replacing `<YOUR-STATE-NAME>`, `<YOUR-PROJECT-ID>`,  `<YOUR-USERNAME>` and
-   `<YOUR-ACCESS-TOKEN>` with the relevant values. This command initializes your
-   Terraform state, and stores that state within your GitLab project. The name of
-   your state can contain only uppercase and lowercase letters, decimal digits,
-   hyphens, and underscores. This example uses `gitlab.com`:
-
-   ```shell
-   terraform init \
-       -backend-config="address=https://gitlab.com/api/v4/projects/<YOUR-PROJECT-ID>/terraform/state/<YOUR-STATE-NAME>" \
-       -backend-config="lock_address=https://gitlab.com/api/v4/projects/<YOUR-PROJECT-ID>/terraform/state/<YOUR-STATE-NAME>/lock" \
-       -backend-config="unlock_address=https://gitlab.com/api/v4/projects/<YOUR-PROJECT-ID>/terraform/state/<YOUR-STATE-NAME>/lock" \
-       -backend-config="username=<YOUR-USERNAME>" \
-       -backend-config="password=<YOUR-ACCESS-TOKEN>" \
-       -backend-config="lock_method=POST" \
-       -backend-config="unlock_method=DELETE" \
-       -backend-config="retry_wait_min=5"
-   ```
-
-You can now run `terraform plan` and `terraform apply` as you normally would.
-
-## Get started using GitLab CI
-
-If you don't want to start with local development, you can also use GitLab CI to
-run your `terraform plan` and `terraform apply` commands.
-
-Next, [configure the backend](#configure-the-backend).
-
-## Configure the backend
-
-After executing the `terraform init` command, you must configure the Terraform backend
-and the CI YAML file:
-
-1. In your Terraform project, define the [HTTP backend](https://www.terraform.io/docs/backends/types/http.html)
-   by adding the following code block in a `.tf` file (such as `backend.tf`) to
-   define the remote backend:
-
-   ```hcl
-   terraform {
-     backend "http" {
-     }
-   }
-   ```
-
-1. In the root directory of your project repository, configure a
-   `.gitlab-ci.yaml` file. This example uses a pre-built image which includes a
-   `gitlab-terraform` helper. For supported Terraform versions, see the [GitLab
-   Terraform Images project](https://gitlab.com/gitlab-org/terraform-images).
-
-   ```yaml
-   image: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
-   ```
-
-1. In the `.gitlab-ci.yaml` file, define some environment variables to ease
-   development. In this example, `TF_ROOT` is the directory where the Terraform
-   commands must be executed, `TF_ADDRESS` is the URL to the state on the GitLab
-   instance where this pipeline runs, and the final path segment in `TF_ADDRESS`
-   is the name of the Terraform state. Projects may have multiple states, and
-   this name is arbitrary, so in this example we set it to `example-production`
-   which corresponds with the directory we're using as our `TF_ROOT`, and we
-   ensure that the `.terraform` directory is cached between jobs in the pipeline
-   using a cache key based on the state name (`example-production`):
-
-   ```yaml
-   variables:
-     TF_ROOT: ${CI_PROJECT_DIR}/environments/example/production
-     TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/example-production
-
-   cache:
-     key: example-production
-     paths:
-       - ${TF_ROOT}/.terraform
-   ```
-
-1. In a `before_script`, change to your `TF_ROOT`:
-
-   ```yaml
-   before_script:
-     - cd ${TF_ROOT}
-
-   stages:
-     - prepare
-     - validate
-     - build
-     - deploy
-
-   init:
-     stage: prepare
-     script:
-       - gitlab-terraform init
-
-   validate:
-     stage: validate
-     script:
-       - gitlab-terraform validate
-
-   plan:
-     stage: build
-     script:
-       - gitlab-terraform plan
-       - gitlab-terraform plan-json
-     artifacts:
-       name: plan
-       paths:
-         - ${TF_ROOT}/plan.cache
-       reports:
-         terraform: ${TF_ROOT}/plan.json
-
-   apply:
-     stage: deploy
-     environment:
-       name: production
-     script:
-       - gitlab-terraform apply
-     dependencies:
-       - plan
-     when: manual
-     only:
-       - master
-   ```
-
-1. Push your project to GitLab, which triggers a CI job pipeline. This pipeline
-   runs the `gitlab-terraform init`, `gitlab-terraform validate`, and
-   `gitlab-terraform plan` commands.
-
-The output from the above `terraform` commands should be viewable in the job logs.
-
-CAUTION: **Caution:**
-Like any other job artifact, Terraform plan data is [viewable by anyone with Guest access](../permissions.md) to the repository.
-Neither Terraform nor GitLab encrypts the plan file by default. If your Terraform plan
-includes sensitive data such as passwords, access tokens, or certificates, GitLab strongly
-recommends encrypting plan output or modifying the project visibility settings.
-
-## Example project
-
-See [this reference project](https://gitlab.com/gitlab-org/configure/examples/gitlab-terraform-aws) using GitLab and Terraform to deploy a basic AWS EC2 within a custom VPC.
-
-## Copy Terraform state between backends
-
-Terraform supports copying the state when the backend is changed or
-reconfigured. This can be useful if you need to migrate from another backend to
-GitLab managed Terraform state. It's also useful if you need to change the state
-name as in the following example:
-
-```shell
-PROJECT_ID="<gitlab-project-id>"
-TF_USERNAME="<gitlab-username>"
-TF_PASSWORD="<gitlab-personal-access-token>"
-TF_ADDRESS="https://gitlab.com/api/v4/projects/${PROJECT_ID}/terraform/state/old-state-name"
-
-terraform init \
-  -backend-config=address=${TF_ADDRESS} \
-  -backend-config=lock_address=${TF_ADDRESS}/lock \
-  -backend-config=unlock_address=${TF_ADDRESS}/lock \
-  -backend-config=username=${TF_USERNAME} \
-  -backend-config=password=${TF_PASSWORD} \
-  -backend-config=lock_method=POST \
-  -backend-config=unlock_method=DELETE \
-  -backend-config=retry_wait_min=5
-```
-
-```plaintext
-Initializing the backend...
-
-Successfully configured the backend "http"! Terraform will automatically
-use this backend unless the backend configuration changes.
-
-Initializing provider plugins...
-
-Terraform has been successfully initialized!
-
-You may now begin working with Terraform. Try running "terraform plan" to see
-any changes that are required for your infrastructure. All Terraform commands
-should now work.
-
-If you ever set or change modules or backend configuration for Terraform,
-rerun this command to reinitialize your working directory. If you forget, other
-commands will detect it and remind you to do so if necessary.
-```
-
-Now that `terraform init` has created a `.terraform/` directory that knows where
-the old state is, you can tell it about the new location:
-
-```shell
-TF_ADDRESS="https://gitlab.com/api/v4/projects/${PROJECT_ID}/terraform/state/new-state-name"
+Read more on setting up and [using GitLab Managed Terraform states](terraform_state.md)
 
-terraform init \
-  -backend-config=address=${TF_ADDRESS} \
-  -backend-config=lock_address=${TF_ADDRESS}/lock \
-  -backend-config=unlock_address=${TF_ADDRESS}/lock \
-  -backend-config=username=${TF_USERNAME} \
-  -backend-config=password=${TF_PASSWORD} \
-  -backend-config=lock_method=POST \
-  -backend-config=unlock_method=DELETE \
-  -backend-config=retry_wait_min=5
-```
-
-```plaintext
-Initializing the backend...
-Backend configuration changed!
-
-Terraform has detected that the configuration specified for the backend
-has changed. Terraform will now check for existing state in the backends.
-
-
-Acquiring state lock. This may take a few moments...
-Do you want to copy existing state to the new backend?
-  Pre-existing state was found while migrating the previous "http" backend to the
-  newly configured "http" backend. No existing state was found in the newly
-  configured "http" backend. Do you want to copy this state to the new "http"
-  backend? Enter "yes" to copy and "no" to start with an empty state.
-
-  Enter a value: yes
-
-
-Successfully configured the backend "http"! Terraform will automatically
-use this backend unless the backend configuration changes.
-
-Initializing provider plugins...
-
-Terraform has been successfully initialized!
-
-You may now begin working with Terraform. Try running "terraform plan" to see
-any changes that are required for your infrastructure. All Terraform commands
-should now work.
-
-If you ever set or change modules or backend configuration for Terraform,
-rerun this command to reinitialize your working directory. If you forget, other
-commands will detect it and remind you to do so if necessary.
-```
-
-If you type `yes`, it copies your state from the old location to the new
-location. You can then go back to running it from within GitLab CI.
-
-## Removing a State file 
-
-You can only remove a state file by making a request to the API, like the following example:
-
-```shell
-curl --header "Private-Token: <your_access_token>" --request DELETE "https://gitlab.example.com/api/v4/projects/<your_project_id/terraform/state/<your_state_name>"
-```
-
-## Output Terraform Plan information into a merge request
-
-Using the [GitLab Terraform Report artifact](../../ci/pipelines/job_artifacts.md#artifactsreportsterraform),
-you can expose details from `terraform plan` runs directly into a merge request widget,
-enabling you to see statistics about the resources that Terraform creates,
-modifies, or destroys.
+## Terraform integration in Merge Requests
 
-Let's explore how to configure a GitLab Terraform Report artifact. You can
-either use a pre-built image which includes a `gitlab-terraform` helper as
-above, where `gitlab-terraform plan-json` outputs the required artifact, or you
-can configure this manually as follows:
+Collaborating around Infrastructure as Code (IaC) changes requires both code changes and expected infrastructure changes to be checked and approved. GitLab provides a solution to help collaboration around Terraform code changes and their expected effects using the Merge Request pages. This way users don't have to build custom tools or rely on 3rd party solutions to streamline their IaC workflows.
 
-1. For simplicity, let's define a few reusable variables to allow us to
-   refer to these files multiple times:
-
-   ```yaml
-   variables:
-     PLAN: plan.cache
-     PLAN_JSON: plan.json
-   ```
-
-1. Install `jq`, a
-   [lightweight and flexible command-line JSON processor](https://stedolan.github.io/jq/).
-1. Create an alias for a specific `jq` command that parses out the information we
-   want to extract from the `terraform plan` output:
-
-   ```yaml
-   before_script:
-     - apk --no-cache add jq
-     - alias convert_report="jq -r '([.resource_changes[]?.change.actions?]|flatten)|{\"create\":(map(select(.==\"create\"))|length),\"update\":(map(select(.==\"update\"))|length),\"delete\":(map(select(.==\"delete\"))|length)}'"
-   ```
-
-   NOTE: **Note:**
-   In distributions that use Bash (for example, Ubuntu), `alias` statements are not
-   expanded in non-interactive mode. If your pipelines fail with the error
-   `convert_report: command not found`, alias expansion can be activated explicitly
-   by adding a `shopt` command to your script:
-
-   ```yaml
-   before_script:
-     - shopt -s expand_aliases
-     - alias convert_report="jq -r '([.resource_changes[]?.change.actions?]|flatten)|{\"create\":(map(select(.==\"create\"))|length),\"update\":(map(select(.==\"update\"))|length),\"delete\":(map(select(.==\"delete\"))|length)}'"
-   ```
-
-1. Define a `script` that runs `terraform plan` and `terraform show`. These commands
-   pipe the output and convert the relevant bits into a store variable `PLAN_JSON`.
-   This JSON is used to create a
-   [GitLab Terraform Report artifact](../../ci/pipelines/job_artifacts.md#artifactsreportsterraform).
-   The Terraform report obtains a Terraform `tfplan.json` file. The collected
-   Terraform plan report is uploaded to GitLab as an artifact, and is shown in merge requests.
-
-   ```yaml
-   plan:
-     stage: build
-     script:
-       - terraform plan -out=$PLAN
-       - terraform show --json $PLAN | convert_report > $PLAN_JSON
-     artifacts:
-       reports:
-         terraform: $PLAN_JSON
-   ```
-
-   For a full example using the pre-built image, see [Example `.gitlab-ci.yaml`
-   file](#example-gitlab-ciyaml-file).
-
-   For an example displaying multiple reports, see [`.gitlab-ci.yaml` multiple reports file](#multiple-terraform-plan-reports).
-
-1. Running the pipeline displays the widget in the merge request, like this:
-
-   ![Merge Request Terraform widget](img/terraform_plan_widget_v13_2.png)
-
-1. Clicking the **View Full Log** button in the widget takes you directly to the
-   plan output present in the pipeline logs:
-
-   ![Terraform plan logs](img/terraform_plan_log_v13_0.png)
+## Quick Start
 
-### Example `.gitlab-ci.yaml` file
+Use the following `.gitlab-ci.yml` to set up a simple Terraform project integration
+for GitLab versions 13.5 and greater:
 
 ```yaml
-default:
-  image: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
-
-  cache:
-    key: example-production
-    paths:
-      - ${TF_ROOT}/.terraform
+include:
+  - template: Terraform.latest.gitlab-ci.yml
 
 variables:
-  TF_ROOT: ${CI_PROJECT_DIR}/environments/example/production
-  TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/example-production
-
-before_script:
-  - cd ${TF_ROOT}
-
-stages:
-  - prepare
-  - validate
-  - build
-  - deploy
-
-init:
-  stage: prepare
-  script:
-    - gitlab-terraform init
-
-validate:
-  stage: validate
-  script:
-    - gitlab-terraform validate
-
-plan:
-  stage: build
-  script:
-    - gitlab-terraform plan
-    - gitlab-terraform plan-json
-  artifacts:
-    name: plan
-    paths:
-      - ${TF_ROOT}/plan.cache
-    reports:
-      terraform: ${TF_ROOT}/plan.json
-
-apply:
-  stage: deploy
-  environment:
-    name: production
-  script:
-    - gitlab-terraform apply
-  dependencies:
-    - plan
-  when: manual
-  only:
-    - master
-```
-
-### Multiple Terraform Plan reports
-
-Starting with GitLab version 13.2, you can display multiple reports on the Merge Request
-page. The reports also display the `artifacts: name:`. See example below for a suggested setup.
-
-```yaml
-default:
-  image:
-    name: registry.gitlab.com/gitlab-org/gitlab-build-images:terraform
-    entrypoint:
-      - '/usr/bin/env'
-      - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
-
-  cache:
-    paths:
-      - .terraform
-
-stages:
-  - build
-
-.terraform-plan-generation:
-  stage: build
-  variables:
-    PLAN: plan.tfplan
-    JSON_PLAN_FILE: tfplan.json
-  before_script:
-    - cd ${TERRAFORM_DIRECTORY}
-    - terraform --version
-    - terraform init
-    - apk --no-cache add jq
-  script:
-    - terraform validate
-    - terraform plan -out=${PLAN}
-    - terraform show --json ${PLAN} | jq -r '([.resource_changes[]?.change.actions?]|flatten)|{"create":(map(select(.=="create"))|length),"update":(map(select(.=="update"))|length),"delete":(map(select(.=="delete"))|length)}' > ${JSON_PLAN_FILE}
-  artifacts:
-    reports:
-      terraform: ${TERRAFORM_DIRECTORY}/${JSON_PLAN_FILE}
-
-review_plan:
-  extends: .terraform-plan-generation
-  variables:
-    TERRAFORM_DIRECTORY: "review/"
-  # Review will not include an artifact name
-
-staging_plan:
-  extends: .terraform-plan-generation
-  variables:
-    TERRAFORM_DIRECTORY: "staging/"
-  artifacts:
-    name: Staging
-
-production_plan:
-  extends: .terraform-plan-generation
-  variables:
-    TERRAFORM_DIRECTORY: "production/"
-  artifacts:
-    name: Production
+  # If not using GitLab's HTTP backend, remove this line and specify TF_HTTP_* variables
+  TF_STATE_NAME: default
+  TF_CACHE_KEY: default
 ```
 
-## Using a GitLab managed Terraform state backend as a remote data source
-
-You can use a GitLab-managed Terraform state as a
-[Terraform data source](https://www.terraform.io/docs/providers/terraform/d/remote_state.html).
-To use your existing Terraform state backend as a data source, provide the following details
-as [Terraform input variables](https://www.terraform.io/docs/configuration/variables.html):
-
-- **address**: The URL of the remote state backend you want to use as a data source.
-  For example, `https://gitlab.com/api/v4/projects/<TARGET-PROJECT-ID>/terraform/state/<TARGET-STATE-NAME>`.
-- **username**: The username to authenticate with the data source. If you are using a [Personal Access Token](../profile/personal_access_tokens.md) for
-  authentication, this is your GitLab username. If you are using GitLab CI, this is `'gitlab-ci-token'`.
-- **password**: The password to authenticate with the data source. If you are using a Personal Access Token for
-  authentication, this is the token value. If you are using GitLab CI, it is the contents of the `${CI_JOB_TOKEN}` CI variable.
-
-An example setup is shown below:
-
-1. Create a file named `example.auto.tfvars` with the following contents:
-
-   ```plaintext
-   example_remote_state_address=https://gitlab.com/api/v4/projects/<TARGET-PROJECT-ID>/terraform/state/<TARGET-STATE-NAME>
-   example_username=<GitLab username>
-   example_access_token=<GitLab Personal Acceess Token>
-   ```
-
-1. Define the data source by adding the following code block in a `.tf` file (such as `data.tf`):
-
-   ```hcl
-   data "terraform_remote_state" "example" {
-     backend = "http"
-
-     config = {
-       address = var.example_remote_state_address
-       username = var.example_username
-       password = var.example_access_token
-     }
-   }
-   ```
-
-Outputs from the data source can now be referenced within your Terraform resources
-using `data.terraform_remote_state.example.outputs.<OUTPUT-NAME>`.
+This template uses `.latest.`, instead of stable, and may include breaking changes.
+This template also includes some opinionated decisions, which you can override:
 
-You need at least [developer access](../permissions.md) to the target project
-to read the Terraform state.
+- Including the latest [GitLab Terraform Image](https://gitlab.com/gitlab-org/terraform-images).
+- Using the [GitLab managed Terraform State](#gitlab-managed-terraform-state) as
+  the Terraform state storage backend.
+- Creating [four pipeline stages](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.latest.gitlab-ci.yml):
+  `init`, `validate`, `build`, and `deploy`. These stages
+  [run the Terraform commands](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform/Base.latest.gitlab-ci.yml)
+  `init`, `validate`, `plan`, `plan-json`, and `apply`. The `apply` command only runs on `master`.
diff --git a/doc/user/infrastructure/mr_integration.md b/doc/user/infrastructure/mr_integration.md
new file mode 100644
index 00000000000..7d9a036cac8
--- /dev/null
+++ b/doc/user/infrastructure/mr_integration.md
@@ -0,0 +1,205 @@
+---
+stage: Configure
+group: Configure
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# Terraform integration in Merge Requests
+
+Collaborating around Infrastructure as Code (IaC) changes requires both code changes and expected infrastructure changes to be checked and approved. GitLab provides a solution to help collaboration around Terraform code changes and their expected effects using the Merge Request pages. This way users don't have to build custom tools or rely on 3rd party solutions to streamline their IaC workflows.
+
+## Output Terraform Plan information into a merge request
+
+Using the [GitLab Terraform Report artifact](../../ci/pipelines/job_artifacts.md#artifactsreportsterraform),
+you can expose details from `terraform plan` runs directly into a merge request widget,
+enabling you to see statistics about the resources that Terraform creates,
+modifies, or destroys.
+
+## Setup
+
+NOTE: **Note:**
+GitLab ships with a [pre-built CI template](index.md#quick-start) that uses GitLab Managed Terraform state and integrates Terraform changes into merge requests. We recommend customizing the pre-built image and relying on the `gitlab-terraform` helper provided within for a quick setup.
+
+To manually configure a GitLab Terraform Report artifact requires the following steps:
+
+1. For simplicity, let's define a few reusable variables to allow us to
+   refer to these files multiple times:
+
+   ```yaml
+   variables:
+     PLAN: plan.cache
+     PLAN_JSON: plan.json
+   ```
+
+1. Install `jq`, a
+   [lightweight and flexible command-line JSON processor](https://stedolan.github.io/jq/).
+1. Create an alias for a specific `jq` command that parses out the information we
+   want to extract from the `terraform plan` output:
+
+   ```yaml
+   before_script:
+     - apk --no-cache add jq
+     - alias convert_report="jq -r '([.resource_changes[]?.change.actions?]|flatten)|{\"create\":(map(select(.==\"create\"))|length),\"update\":(map(select(.==\"update\"))|length),\"delete\":(map(select(.==\"delete\"))|length)}'"
+   ```
+
+   NOTE: **Note:**
+   In distributions that use Bash (for example, Ubuntu), `alias` statements are not
+   expanded in non-interactive mode. If your pipelines fail with the error
+   `convert_report: command not found`, alias expansion can be activated explicitly
+   by adding a `shopt` command to your script:
+
+   ```yaml
+   before_script:
+     - shopt -s expand_aliases
+     - alias convert_report="jq -r '([.resource_changes[]?.change.actions?]|flatten)|{\"create\":(map(select(.==\"create\"))|length),\"update\":(map(select(.==\"update\"))|length),\"delete\":(map(select(.==\"delete\"))|length)}'"
+   ```
+
+1. Define a `script` that runs `terraform plan` and `terraform show`. These commands
+   pipe the output and convert the relevant bits into a store variable `PLAN_JSON`.
+   This JSON is used to create a
+   [GitLab Terraform Report artifact](../../ci/pipelines/job_artifacts.md#artifactsreportsterraform).
+   The Terraform report obtains a Terraform `tfplan.json` file. The collected
+   Terraform plan report is uploaded to GitLab as an artifact, and is shown in merge requests.
+
+   ```yaml
+   plan:
+     stage: build
+     script:
+       - terraform plan -out=$PLAN
+       - terraform show --json $PLAN | convert_report > $PLAN_JSON
+     artifacts:
+       reports:
+         terraform: $PLAN_JSON
+   ```
+
+   For a full example using the pre-built image, see [Example `.gitlab-ci.yaml`
+   file](#example-gitlab-ciyaml-file).
+
+   For an example displaying multiple reports, see [`.gitlab-ci.yaml` multiple reports file](#multiple-terraform-plan-reports).
+
+1. Running the pipeline displays the widget in the merge request, like this:
+
+   ![Merge Request Terraform widget](img/terraform_plan_widget_v13_2.png)
+
+1. Clicking the **View Full Log** button in the widget takes you directly to the
+   plan output present in the pipeline logs:
+
+   ![Terraform plan logs](img/terraform_plan_log_v13_0.png)
+
+### Example `.gitlab-ci.yaml` file
+
+```yaml
+default:
+  image: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
+
+  cache:
+    key: example-production
+    paths:
+      - ${TF_ROOT}/.terraform
+
+variables:
+  TF_ROOT: ${CI_PROJECT_DIR}/environments/example/production
+  TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/example-production
+
+before_script:
+  - cd ${TF_ROOT}
+
+stages:
+  - prepare
+  - validate
+  - build
+  - deploy
+
+init:
+  stage: prepare
+  script:
+    - gitlab-terraform init
+
+validate:
+  stage: validate
+  script:
+    - gitlab-terraform validate
+
+plan:
+  stage: build
+  script:
+    - gitlab-terraform plan
+    - gitlab-terraform plan-json
+  artifacts:
+    name: plan
+    paths:
+      - ${TF_ROOT}/plan.cache
+    reports:
+      terraform: ${TF_ROOT}/plan.json
+
+apply:
+  stage: deploy
+  environment:
+    name: production
+  script:
+    - gitlab-terraform apply
+  dependencies:
+    - plan
+  when: manual
+  only:
+    - master
+```
+
+### Multiple Terraform Plan reports
+
+Starting with GitLab version 13.2, you can display multiple reports on the Merge Request
+page. The reports also display the `artifacts: name:`. See example below for a suggested setup.
+
+```yaml
+default:
+  image:
+    name: registry.gitlab.com/gitlab-org/gitlab-build-images:terraform
+    entrypoint:
+      - '/usr/bin/env'
+      - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
+
+  cache:
+    paths:
+      - .terraform
+
+stages:
+  - build
+
+.terraform-plan-generation:
+  stage: build
+  variables:
+    PLAN: plan.tfplan
+    JSON_PLAN_FILE: tfplan.json
+  before_script:
+    - cd ${TERRAFORM_DIRECTORY}
+    - terraform --version
+    - terraform init
+    - apk --no-cache add jq
+  script:
+    - terraform validate
+    - terraform plan -out=${PLAN}
+    - terraform show --json ${PLAN} | jq -r '([.resource_changes[]?.change.actions?]|flatten)|{"create":(map(select(.=="create"))|length),"update":(map(select(.=="update"))|length),"delete":(map(select(.=="delete"))|length)}' > ${JSON_PLAN_FILE}
+  artifacts:
+    reports:
+      terraform: ${TERRAFORM_DIRECTORY}/${JSON_PLAN_FILE}
+
+review_plan:
+  extends: .terraform-plan-generation
+  variables:
+    TERRAFORM_DIRECTORY: "review/"
+  # Review will not include an artifact name
+
+staging_plan:
+  extends: .terraform-plan-generation
+  variables:
+    TERRAFORM_DIRECTORY: "staging/"
+  artifacts:
+    name: Staging
+
+production_plan:
+  extends: .terraform-plan-generation
+  variables:
+    TERRAFORM_DIRECTORY: "production/"
+  artifacts:
+    name: Production
+```
diff --git a/doc/user/infrastructure/terraform_state.md b/doc/user/infrastructure/terraform_state.md
new file mode 100644
index 00000000000..e85a34a8de8
--- /dev/null
+++ b/doc/user/infrastructure/terraform_state.md
@@ -0,0 +1,360 @@
+---
+stage: Configure
+group: Configure
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# GitLab managed Terraform State
+
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2673) in GitLab 13.0.
+
+[Terraform remote backends](https://www.terraform.io/docs/backends/index.html)
+enable you to store the state file in a remote, shared store. GitLab uses the
+[Terraform HTTP backend](https://www.terraform.io/docs/backends/types/http.html)
+to securely store the state files in local storage (the default) or
+[the remote store of your choice](../../administration/terraform_state.md).
+
+The GitLab managed Terraform state backend can store your Terraform state easily and
+securely, and spares you from setting up additional remote resources like
+Amazon S3 or Google Cloud Storage. Its features include:
+
+- Supporting encryption of the state file both in transit and at rest.
+- Locking and unlocking state.
+- Remote Terraform plan and apply execution.
+
+## Permissions for using Terraform
+
+In GitLab version 13.1, [Maintainer access](../permissions.md) was required to use a
+GitLab managed Terraform state backend. In GitLab versions 13.2 and greater,
+[Maintainer access](../permissions.md) is required to lock, unlock and write to the state
+(using `terraform apply`), while [Developer access](../permissions.md) is required to read
+the state (using `terraform plan -lock=false`).
+
+## Set up GitLab-managed Terraform state
+
+To get started with a GitLab-managed Terraform state, there are two different options:
+
+- [Use a local machine](#get-started-using-local-development).
+- [Use GitLab CI](#get-started-using-gitlab-ci).
+
+Terraform States can be found by navigating to a Project's **{cloud-gear}** **Operations > Terraform** page.
+
+### Get started using local development
+
+If you plan to only run `terraform plan` and `terraform apply` commands from your
+local machine, this is a simple way to get started:
+
+1. Create your project on your GitLab instance.
+1. Navigate to **Settings > General** and note your **Project name**
+   and **Project ID**.
+1. Define the Terraform backend in your Terraform project to be:
+
+   ```hcl
+   terraform {
+     backend "http" {
+     }
+   }
+   ```
+
+1. Create a [Personal Access Token](../profile/personal_access_tokens.md) with
+   the `api` scope.
+
+1. On your local machine, run `terraform init`, passing in the following options,
+   replacing `<YOUR-STATE-NAME>`, `<YOUR-PROJECT-ID>`,  `<YOUR-USERNAME>` and
+   `<YOUR-ACCESS-TOKEN>` with the relevant values. This command initializes your
+   Terraform state, and stores that state within your GitLab project. The name of
+   your state can contain only uppercase and lowercase letters, decimal digits,
+   hyphens, and underscores. This example uses `gitlab.com`:
+
+   ```shell
+   terraform init \
+       -backend-config="address=https://gitlab.com/api/v4/projects/<YOUR-PROJECT-ID>/terraform/state/<YOUR-STATE-NAME>" \
+       -backend-config="lock_address=https://gitlab.com/api/v4/projects/<YOUR-PROJECT-ID>/terraform/state/<YOUR-STATE-NAME>/lock" \
+       -backend-config="unlock_address=https://gitlab.com/api/v4/projects/<YOUR-PROJECT-ID>/terraform/state/<YOUR-STATE-NAME>/lock" \
+       -backend-config="username=<YOUR-USERNAME>" \
+       -backend-config="password=<YOUR-ACCESS-TOKEN>" \
+       -backend-config="lock_method=POST" \
+       -backend-config="unlock_method=DELETE" \
+       -backend-config="retry_wait_min=5"
+   ```
+
+You can now run `terraform plan` and `terraform apply` as you normally would.
+
+### Get started using GitLab CI
+
+If you don't want to start with local development, you can also use GitLab CI to
+run your `terraform plan` and `terraform apply` commands.
+
+Next, [configure the backend](#configure-the-backend).
+
+#### Configure the backend
+
+After executing the `terraform init` command, you must configure the Terraform backend
+and the CI YAML file:
+
+1. In your Terraform project, define the [HTTP backend](https://www.terraform.io/docs/backends/types/http.html)
+   by adding the following code block in a `.tf` file (such as `backend.tf`) to
+   define the remote backend:
+
+   ```hcl
+   terraform {
+     backend "http" {
+     }
+   }
+   ```
+
+1. In the root directory of your project repository, configure a
+   `.gitlab-ci.yaml` file. This example uses a pre-built image which includes a
+   `gitlab-terraform` helper. For supported Terraform versions, see the [GitLab
+   Terraform Images project](https://gitlab.com/gitlab-org/terraform-images).
+
+   ```yaml
+   image: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
+   ```
+
+1. In the `.gitlab-ci.yaml` file, define some environment variables to ease
+   development. In this example, `TF_ROOT` is the directory where the Terraform
+   commands must be executed, `TF_ADDRESS` is the URL to the state on the GitLab
+   instance where this pipeline runs, and the final path segment in `TF_ADDRESS`
+   is the name of the Terraform state. Projects may have multiple states, and
+   this name is arbitrary, so in this example we set it to `example-production`
+   which corresponds with the directory we're using as our `TF_ROOT`, and we
+   ensure that the `.terraform` directory is cached between jobs in the pipeline
+   using a cache key based on the state name (`example-production`):
+
+   ```yaml
+   variables:
+     TF_ROOT: ${CI_PROJECT_DIR}/environments/example/production
+     TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/example-production
+
+   cache:
+     key: example-production
+     paths:
+       - ${TF_ROOT}/.terraform
+   ```
+
+1. In a `before_script`, change to your `TF_ROOT`:
+
+   ```yaml
+   before_script:
+     - cd ${TF_ROOT}
+
+   stages:
+     - prepare
+     - validate
+     - build
+     - deploy
+
+   init:
+     stage: prepare
+     script:
+       - gitlab-terraform init
+
+   validate:
+     stage: validate
+     script:
+       - gitlab-terraform validate
+
+   plan:
+     stage: build
+     script:
+       - gitlab-terraform plan
+       - gitlab-terraform plan-json
+     artifacts:
+       name: plan
+       paths:
+         - ${TF_ROOT}/plan.cache
+       reports:
+         terraform: ${TF_ROOT}/plan.json
+
+   apply:
+     stage: deploy
+     environment:
+       name: production
+     script:
+       - gitlab-terraform apply
+     dependencies:
+       - plan
+     when: manual
+     only:
+       - master
+   ```
+
+1. Push your project to GitLab, which triggers a CI job pipeline. This pipeline
+   runs the `gitlab-terraform init`, `gitlab-terraform validate`, and
+   `gitlab-terraform plan` commands.
+
+The output from the above `terraform` commands should be viewable in the job logs.
+
+CAUTION: **Caution:**
+Like any other job artifact, Terraform plan data is [viewable by anyone with Guest access](../permissions.md) to the repository.
+Neither Terraform nor GitLab encrypts the plan file by default. If your Terraform plan
+includes sensitive data such as passwords, access tokens, or certificates, GitLab strongly
+recommends encrypting plan output or modifying the project visibility settings.
+
+### Example project
+
+See [this reference project](https://gitlab.com/gitlab-org/configure/examples/gitlab-terraform-aws) using GitLab and Terraform to deploy a basic AWS EC2 within a custom VPC.
+
+## Using a GitLab managed Terraform state backend as a remote data source
+
+You can use a GitLab-managed Terraform state as a
+[Terraform data source](https://www.terraform.io/docs/providers/terraform/d/remote_state.html).
+To use your existing Terraform state backend as a data source, provide the following details
+as [Terraform input variables](https://www.terraform.io/docs/configuration/variables.html):
+
+- **address**: The URL of the remote state backend you want to use as a data source.
+  For example, `https://gitlab.com/api/v4/projects/<TARGET-PROJECT-ID>/terraform/state/<TARGET-STATE-NAME>`.
+- **username**: The username to authenticate with the data source. If you are using a [Personal Access Token](../profile/personal_access_tokens.md) for
+  authentication, this is your GitLab username. If you are using GitLab CI, this is `'gitlab-ci-token'`.
+- **password**: The password to authenticate with the data source. If you are using a Personal Access Token for
+  authentication, this is the token value. If you are using GitLab CI, it is the contents of the `${CI_JOB_TOKEN}` CI variable.
+
+An example setup is shown below:
+
+1. Create a file named `example.auto.tfvars` with the following contents:
+
+   ```plaintext
+   example_remote_state_address=https://gitlab.com/api/v4/projects/<TARGET-PROJECT-ID>/terraform/state/<TARGET-STATE-NAME>
+   example_username=<GitLab username>
+   example_access_token=<GitLab Personal Acceess Token>
+   ```
+
+1. Define the data source by adding the following code block in a `.tf` file (such as `data.tf`):
+
+   ```hcl
+   data "terraform_remote_state" "example" {
+     backend = "http"
+
+     config = {
+       address = var.example_remote_state_address
+       username = var.example_username
+       password = var.example_access_token
+     }
+   }
+   ```
+
+Outputs from the data source can now be referenced within your Terraform resources
+using `data.terraform_remote_state.example.outputs.<OUTPUT-NAME>`.
+
+You need at least [developer access](../permissions.md) to the target project
+to read the Terraform state.
+
+## Migrating to GitLab Managed Terraform state
+
+Terraform supports copying the state when the backend is changed or
+reconfigured. This can be useful if you need to migrate from another backend to
+GitLab managed Terraform state. Using a local terminal is recommended to run the commands needed for migrating to GitLab Managed Terraform state.
+
+The following example demonstrates how to change the state name, the same workflow is needed to migrate to GitLab Managed Terraform state from a different state storage backend.
+
+### Setting up the initial backend
+
+```shell
+PROJECT_ID="<gitlab-project-id>"
+TF_USERNAME="<gitlab-username>"
+TF_PASSWORD="<gitlab-personal-access-token>"
+TF_ADDRESS="https://gitlab.com/api/v4/projects/${PROJECT_ID}/terraform/state/old-state-name"
+
+terraform init \
+  -backend-config=address=${TF_ADDRESS} \
+  -backend-config=lock_address=${TF_ADDRESS}/lock \
+  -backend-config=unlock_address=${TF_ADDRESS}/lock \
+  -backend-config=username=${TF_USERNAME} \
+  -backend-config=password=${TF_PASSWORD} \
+  -backend-config=lock_method=POST \
+  -backend-config=unlock_method=DELETE \
+  -backend-config=retry_wait_min=5
+```
+
+```plaintext
+Initializing the backend...
+
+Successfully configured the backend "http"! Terraform will automatically
+use this backend unless the backend configuration changes.
+
+Initializing provider plugins...
+
+Terraform has been successfully initialized!
+
+You may now begin working with Terraform. Try running "terraform plan" to see
+any changes that are required for your infrastructure. All Terraform commands
+should now work.
+
+If you ever set or change modules or backend configuration for Terraform,
+rerun this command to reinitialize your working directory. If you forget, other
+commands will detect it and remind you to do so if necessary.
+```
+
+### Changing the backend
+
+Now that `terraform init` has created a `.terraform/` directory that knows where
+the old state is, you can tell it about the new location:
+
+```shell
+TF_ADDRESS="https://gitlab.com/api/v4/projects/${PROJECT_ID}/terraform/state/new-state-name"
+
+terraform init \
+  -backend-config=address=${TF_ADDRESS} \
+  -backend-config=lock_address=${TF_ADDRESS}/lock \
+  -backend-config=unlock_address=${TF_ADDRESS}/lock \
+  -backend-config=username=${TF_USERNAME} \
+  -backend-config=password=${TF_PASSWORD} \
+  -backend-config=lock_method=POST \
+  -backend-config=unlock_method=DELETE \
+  -backend-config=retry_wait_min=5
+```
+
+```plaintext
+Initializing the backend...
+Backend configuration changed!
+
+Terraform has detected that the configuration specified for the backend
+has changed. Terraform will now check for existing state in the backends.
+
+
+Acquiring state lock. This may take a few moments...
+Do you want to copy existing state to the new backend?
+  Pre-existing state was found while migrating the previous "http" backend to the
+  newly configured "http" backend. No existing state was found in the newly
+  configured "http" backend. Do you want to copy this state to the new "http"
+  backend? Enter "yes" to copy and "no" to start with an empty state.
+
+  Enter a value: yes
+
+
+Successfully configured the backend "http"! Terraform will automatically
+use this backend unless the backend configuration changes.
+
+Initializing provider plugins...
+
+Terraform has been successfully initialized!
+
+You may now begin working with Terraform. Try running "terraform plan" to see
+any changes that are required for your infrastructure. All Terraform commands
+should now work.
+
+If you ever set or change modules or backend configuration for Terraform,
+rerun this command to reinitialize your working directory. If you forget, other
+commands will detect it and remind you to do so if necessary.
+```
+
+If you type `yes`, it copies your state from the old location to the new
+location. You can then go back to running it from within GitLab CI.
+
+## Managing state files
+
+NOTE: **Note:**
+We are currently working on [providing a graphical for managing state files](https://gitlab.com/groups/gitlab-org/-/epics/4563).
+
+![Terraform state list](img/terraform_list_view.png)
+
+The state files attached to a project can be found under Operations / Terraform.
+
+## Removing a State file
+
+You can only remove a state file by making a request to the API, like the following example:
+
+```shell
+curl --header "Private-Token: <your_access_token>" --request DELETE "https://gitlab.example.com/api/v4/projects/<your_project_id/terraform/state/<your_state_name>"
+```
diff --git a/doc/user/profile/notifications.md b/doc/user/profile/notifications.md
index 73a83b08a23..64bc6e48b81 100644
--- a/doc/user/profile/notifications.md
+++ b/doc/user/profile/notifications.md
@@ -7,13 +7,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # GitLab Notification Emails
 
-GitLab Notifications allow you to stay informed about what's happening in GitLab. With notifications enabled, you can receive updates about activity in issues, merge requests, and epics. Notifications are sent via email.
+GitLab Notifications allow you to stay informed about what's happening in GitLab. With notifications
+enabled, you can receive updates about activity in issues, merge requests, epics, and designs.
+Notifications are sent via email.
 
 ## Receiving notifications
 
 You will receive notifications for one of the following reasons:
 
-- You participate in an issue, merge request, or epic. In this context, _participate_ means comment, or edit.
+- You participate in an issue, merge request, epic or design. In this context, _participate_ means comment, or edit.
 - You enable notifications in an issue, merge request, or epic. To enable notifications, click the **Notifications** toggle in the sidebar to _on_.
 
 While notifications are enabled, you will receive notification of actions occurring in that issue, merge request, or epic.
@@ -209,6 +211,44 @@ If an open merge request becomes unmergeable due to conflict, its author will be
 If a user has also set the merge request to automatically merge once pipeline succeeds,
 then that user will also be notified.
 
+## Design email notifications
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217095) in GitLab 13.6.
+> - It's [deployed behind a feature flag](../../user/feature_flags.md), disabled by default.
+> - It's disabled on GitLab.com.
+> - It's not recommended for production use.
+> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-design-email-notifications). **(CORE ONLY)**
+
+CAUTION: **Warning:**
+This feature might not be available to you. Check the **version history** note above for details.
+
+Email notifications are sent to the participants when comments are made on a design.
+
+The participants are:
+
+- Authors of the design (can be multiple people if different authors have uploaded different versions of the design).
+- Authors of comments on the design.
+- Anyone that is `@mentioned` in a comment on the design.
+
+### Enable or disable design email notifications **(CORE ONLY)**
+
+The design email notifications feature is under development and not ready for production use. It is
+deployed behind a feature flag that is **disabled by default**.
+[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md)
+can enable it.
+
+To enable it:
+
+```ruby
+Feature.enable(:design_management_design_notification_participants)
+```
+
+To disable it:
+
+```ruby
+Feature.disable(:design_management_design_notification_participants)
+```
+
 ## Filtering email
 
 Notification email messages include GitLab-specific headers. You can filter the notification emails based on the content of these headers to better manage your notifications. For example, you could filter all emails for a specific project where you are being assigned either a merge request or issue.