diff --git a/app/assets/javascripts/packages_and_registries/shared/components/cli_commands.vue b/app/assets/javascripts/packages_and_registries/shared/components/cli_commands.vue
index de7ab3e6d7b..dc61f3c788c 100644
--- a/app/assets/javascripts/packages_and_registries/shared/components/cli_commands.vue
+++ b/app/assets/javascripts/packages_and_registries/shared/components/cli_commands.vue
@@ -49,7 +49,7 @@ export default {
 <template>
   <gl-dropdown
     :text="$options.i18n.QUICK_START"
-    variant="info"
+    variant="confirm"
     right
     @shown="track('click_dropdown')"
   >
diff --git a/app/graphql/types/group_member_type.rb b/app/graphql/types/group_member_type.rb
index 18242f7b8b1..c4582f31bec 100644
--- a/app/graphql/types/group_member_type.rb
+++ b/app/graphql/types/group_member_type.rb
@@ -15,7 +15,7 @@ module Types
 
     field :notification_email,
           resolver: Resolvers::GroupMembers::NotificationEmailResolver,
-          description: "Group notification email for User. Only availble for admins."
+          description: "Group notification email for User. Only available for admins."
 
     def group
       Gitlab::Graphql::Loaders::BatchModelLoader.new(Group, object.source_id).find
diff --git a/config/feature_flags/development/container_security_policy_selection.yml b/config/feature_flags/development/container_security_policy_selection.yml
deleted file mode 100644
index e2407195ffc..00000000000
--- a/config/feature_flags/development/container_security_policy_selection.yml
+++ /dev/null
@@ -1,8 +0,0 @@
----
-name: container_security_policy_selection
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80272
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/353071
-milestone: '14.10'
-type: development
-group: group::container security
-default_enabled: true
diff --git a/config/feature_flags/development/omniauth_initializer_fullhost_proc.yml b/config/feature_flags/development/omniauth_initializer_fullhost_proc.yml
deleted file mode 100644
index 52743818b5a..00000000000
--- a/config/feature_flags/development/omniauth_initializer_fullhost_proc.yml
+++ /dev/null
@@ -1,8 +0,0 @@
----
-name: omniauth_initializer_fullhost_proc
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82703
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/355579
-milestone: '14.10'
-type: development
-group: group::geo
-default_enabled: true
diff --git a/config/initializers/omniauth.rb b/config/initializers/omniauth.rb
index 2c7034f758d..38bd1034b36 100644
--- a/config/initializers/omniauth.rb
+++ b/config/initializers/omniauth.rb
@@ -11,14 +11,7 @@ if Gitlab::Auth::Ldap::Config.enabled?
   end
 end
 
-OmniAuth.config.full_host =
-  if Feature.feature_flags_available? && ::Feature.enabled?(:omniauth_initializer_fullhost_proc)
-    Gitlab::AppLogger.debug("Using OmniAuth proc initializer")
-    Gitlab::OmniauthInitializer.full_host
-  else
-    Gitlab::AppLogger.debug("Fallback to OmniAuth static full_host")
-    Settings.gitlab['base_url']
-  end
+OmniAuth.config.full_host = Gitlab::OmniauthInitializer.full_host
 
 OmniAuth.config.allowed_request_methods = [:post]
 # In case of auto sign-in, the GET method is used (users don't get to click on a button)
diff --git a/data/deprecations/14-5-runner-s3-authenticationtype-nonexplicit-config-deprecation.yml b/data/deprecations/14-5-runner-s3-authenticationtype-nonexplicit-config-deprecation.yml
deleted file mode 100644
index 7026438f649..00000000000
--- a/data/deprecations/14-5-runner-s3-authenticationtype-nonexplicit-config-deprecation.yml
+++ /dev/null
@@ -1,14 +0,0 @@
-- name: "Must explicitly assign `AuthenticationType` for `[runners.cache.s3]`"
-  announcement_milestone: "14.5"  # The milestone when this feature was first announced as deprecated.
-  announcement_date: "2021-11-22"
-  removal_milestone: "15.0"  # the milestone when this feature is planned to be removed
-  removal_date: "2022-05-22"  # the date of the milestone release when this feature is planned to be removed
-  breaking_change: true
-  body: |  # Do not modify this line, instead modify the lines below.
-    In GitLab 15.0 and later, to access the AWS S3 cache, you must specify the `AuthenticationType` for [`[runners.cache.s3]`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscaches3-section). The `AuthenticationType` must be `IAM` or `credentials`.
-
-    Prior to 14.5, if you did not define the `AuthenticationType`, GitLab Runner chose a type for you.
-  stage: Verify
-  tiers: [Core, Premium, Ultimate]
-  issue_url: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28171
-  documentation_url: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscaches3-section
diff --git a/doc/administration/auth/authentiq.md b/doc/administration/auth/authentiq.md
index a4a085a494c..61ce2b5ab25 100644
--- a/doc/administration/auth/authentiq.md
+++ b/doc/administration/auth/authentiq.md
@@ -69,7 +69,7 @@ Authentiq generates a Client ID and the accompanying Client Secret for you to us
 
 1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
 
-On the sign in page there should now be an Authentiq icon below the regular sign in form. Click the
+On the sign in page there should now be an Authentiq icon below the regular sign in form. Select the
 icon to begin the authentication process. If the user:
 
 - Has the Authentiq ID app installed in their iOS or Android device, they can:
diff --git a/doc/administration/configure.md b/doc/administration/configure.md
index cba4a23d95a..94de3be612c 100644
--- a/doc/administration/configure.md
+++ b/doc/administration/configure.md
@@ -46,5 +46,5 @@ The following table outlines failure modes and mitigation paths for the product
 | Single Gitaly Node + Geo Secondary | Downtime - Must restore from backup, can perform a manual failover to secondary | Downtime - Must restore from Backup, errors could have propagated to secondary | Manual intervention - failover to Geo secondary | |
 | Sharded Gitaly Install | Partial Downtime - Only repositories on impacted node affected, must restore from backup | Partial Downtime - Only repositories on impacted node affected, must restore from backup | Downtime - Must wait for outage to end | |
 | Sharded Gitaly Install + Geo Secondary | Partial Downtime - Only repositories on impacted node affected, must restore from backup, could perform manual failover to secondary for impacted repositories | Partial Downtime - Only repositories on impacted node affected, must restore from backup, errors could have propagated to secondary | Manual intervention - failover to Geo secondary | |
-| Gitaly Cluster Install* | No Downtime - will swap repository primary to another node after 10 seconds | N/A - All writes are voted on by multiple Gitaly Cluster nodes | Downtime - Must wait for outage to end | Snapshot backups for Gitaly Cluster nodes not supported at this time |
-| Gitaly Cluster Install* + Geo Secondary | No Downtime - will swap repository primary to another node after 10 seconds | N/A - All writes are voted on by multiple Gitaly Cluster nodes | Manual intervention - failover to Geo secondary | Snapshot backups for Gitaly Cluster nodes not supported at this time |
+| Gitaly Cluster Install* | No Downtime - will swap repository primary to another node after 10 seconds | Not applicable; All writes are voted on by multiple Gitaly Cluster nodes | Downtime - Must wait for outage to end | Snapshot backups for Gitaly Cluster nodes not supported at this time |
+| Gitaly Cluster Install* + Geo Secondary | No Downtime - will swap repository primary to another node after 10 seconds | Not applicable; All writes are voted on by multiple Gitaly Cluster nodes | Manual intervention - failover to Geo secondary | Snapshot backups for Gitaly Cluster nodes not supported at this time |
diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md
index 8aff9226203..c1f1ffad74c 100644
--- a/doc/administration/geo/replication/datatypes.md
+++ b/doc/administration/geo/replication/datatypes.md
@@ -26,7 +26,7 @@ verification methods:
 | Type     | Feature / component                             | Replication method                    | Verification method    |
 |:---------|:------------------------------------------------|:--------------------------------------|:-----------------------|
 | Database | Application data in PostgreSQL                  | Native                                | Native                 |
-| Database | Redis                                           | _N/A_ (*1*)                           | _N/A_                  |
+| Database | Redis                                           | Not applicable (*1*)                  | Not applicable         |
 | Database | Elasticsearch                                   | Native                                | Native                 |
 | Database | SSH public keys                                 | PostgreSQL Replication                | PostgreSQL Replication |
 | Git      | Project repository                              | Geo with Gitaly                       | Gitaly Checksum        |
diff --git a/doc/administration/monitoring/gitlab_self_monitoring_project/index.md b/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
index 3cc05401e7c..2553638291d 100644
--- a/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
+++ b/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
@@ -54,7 +54,7 @@ you create the project again, it's created in its default state.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, go to **Settings > Metrics and profiling** and expand **Self monitoring**.
 1. Toggle **Self monitoring** off.
-1. In the confirmation dialog that opens, click **Delete self monitoring project**.
+1. In the confirmation dialog that opens, select **Delete self monitoring project**.
    It can take a few seconds for it to be deleted.
 1. After the project is deleted, GitLab displays a message confirming your action.
 
diff --git a/doc/administration/operations/puma.md b/doc/administration/operations/puma.md
index 12a8b2faadc..02ccd543ca1 100644
--- a/doc/administration/operations/puma.md
+++ b/doc/administration/operations/puma.md
@@ -252,19 +252,19 @@ To switch from Unicorn to Puma:
    | `unicorn['enable']`                  | `puma['enable']`                   |
    | `unicorn['worker_timeout']`          | `puma['worker_timeout']`           |
    | `unicorn['worker_processes']`        | `puma['worker_processes']`         |
-   | n/a                                  | `puma['ha']`                       |
-   | n/a                                  | `puma['min_threads']`              |
-   | n/a                                  | `puma['max_threads']`              |
+   | Not applicable                       | `puma['ha']`                       |
+   | Not applicable                       | `puma['min_threads']`              |
+   | Not applicable                       | `puma['max_threads']`              |
    | `unicorn['listen']`                  | `puma['listen']`                   |
    | `unicorn['port']`                    | `puma['port']`                     |
    | `unicorn['socket']`                  | `puma['socket']`                   |
    | `unicorn['pidfile']`                 | `puma['pidfile']`                  |
-   | `unicorn['tcp_nopush']`              | n/a                                |
-   | `unicorn['backlog_socket']`          | n/a                                |
+   | `unicorn['tcp_nopush']`              | Not applicable                     |
+   | `unicorn['backlog_socket']`          | Not applicable                     |
    | `unicorn['somaxconn']`               | `puma['somaxconn']`                |
-   | n/a                                  | `puma['state_path']`               |
+   | Not applicable                       | `puma['state_path']`               |
    | `unicorn['log_directory']`           | `puma['log_directory']`            |
-   | `unicorn['worker_memory_limit_min']` | n/a                                |
+   | `unicorn['worker_memory_limit_min']` | Not applicable                     |
    | `unicorn['worker_memory_limit_max']` | `puma['per_worker_max_memory_mb']` |
    | `unicorn['exporter_enabled']`        | `puma['exporter_enabled']`         |
    | `unicorn['exporter_address']`        | `puma['exporter_address']`         |
diff --git a/doc/administration/system_hooks.md b/doc/administration/system_hooks.md
index 71d7e7f1426..cb141a18ae6 100644
--- a/doc/administration/system_hooks.md
+++ b/doc/administration/system_hooks.md
@@ -61,7 +61,7 @@ To create a system hook:
 1. Provide the **URL** and **Secret Token**.
 1. Select the checkbox next to each optional **Trigger** you want to enable.
 1. Select **Enable SSL verification**, if desired.
-1. Click **Add system hook**.
+1. Select **Add system hook**.
 
 ## Hooks request example
 
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 0d957ed2d53..742383e411a 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -12081,7 +12081,7 @@ Represents a Group Membership.
 | <a id="groupmemberexpiresat"></a>`expiresAt` | [`Time`](#time) | Date and time the membership expires. |
 | <a id="groupmembergroup"></a>`group` | [`Group`](#group) | Group that a User is a member of. |
 | <a id="groupmemberid"></a>`id` | [`ID!`](#id) | ID of the member. |
-| <a id="groupmembernotificationemail"></a>`notificationEmail` | [`String`](#string) | Group notification email for User. Only availble for admins. |
+| <a id="groupmembernotificationemail"></a>`notificationEmail` | [`String`](#string) | Group notification email for User. Only available for admins. |
 | <a id="groupmemberupdatedat"></a>`updatedAt` | [`Time`](#time) | Date and time the membership was last updated. |
 | <a id="groupmemberuser"></a>`user` | [`UserCore`](#usercore) | User that is associated with the member object. |
 | <a id="groupmemberuserpermissions"></a>`userPermissions` | [`GroupPermissions!`](#grouppermissions) | Permissions for the current user on the resource. |
diff --git a/doc/ci/directed_acyclic_graph/index.md b/doc/ci/directed_acyclic_graph/index.md
index 5d0aaf7cc45..f63ecc57028 100644
--- a/doc/ci/directed_acyclic_graph/index.md
+++ b/doc/ci/directed_acyclic_graph/index.md
@@ -87,7 +87,7 @@ are certain use cases that you may need to work around. For more information, ch
 
 The needs visualization makes it easier to visualize the relationships between dependent jobs in a DAG. This graph displays all the jobs in a pipeline that need or are needed by other jobs. Jobs with no relationships are not displayed in this view.
 
-To see the needs visualization, click on the **Needs** tab when viewing a pipeline that uses the `needs` keyword.
+To see the needs visualization, select **Needs** when viewing a pipeline that uses the `needs` keyword.
 
 ![Needs visualization example](img/dag_graph_example_v13_1.png)
 
diff --git a/doc/ci/variables/where_variables_can_be_used.md b/doc/ci/variables/where_variables_can_be_used.md
index 64d61ec9f11..ce61ab996f6 100644
--- a/doc/ci/variables/where_variables_can_be_used.md
+++ b/doc/ci/variables/where_variables_can_be_used.md
@@ -30,12 +30,12 @@ There are two places defined variables can be used. On the:
 | `cache:key`           | yes              | Runner                 | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
 | `environment:name`    | yes              | GitLab                 | Similar to `environment:url`, but the variables expansion doesn't support the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
 | `environment:url`     | yes              | GitLab                 | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab.<br/><br/>Supported are all variables defined for a job (project/group variables, variables from `.gitlab-ci.yml`, variables from triggers, variables from pipeline schedules).<br/><br/>Not supported are variables defined in the GitLab Runner `config.toml` and variables created in the job's `script`. |
-| `except:variables:[]` | no               | n/a                    | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
+| `except:variables:[]` | no               | Not applicable         | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
 | `image`               | yes              | Runner                 | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
 | `include`             | yes              | GitLab                 | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. <br/><br/>Predefined project variables are supported: `GITLAB_FEATURES`, `CI_DEFAULT_BRANCH`, and all variables that start with `CI_PROJECT_` (for example `CI_PROJECT_NAME`). |
-| `only:variables:[]`   | no               | n/a                    | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
+| `only:variables:[]`   | no               | Not applicable         | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
 | `resource_group`      | yes              | GitLab                 | Similar to `environment:url`, but the variables expansion doesn't support the following:<br/>- `CI_ENVIRONMENT_URL`<br/>- [Persisted variables](#persisted-variables). |
-| `rules:if`            | no               | n/a                    | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
+| `rules:if`            | no               | Not applicable         | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
 | `script`              | yes              | Script execution shell | The variable expansion is made by the [execution shell environment](#execution-shell-environment). |
 | `services:[]:name`    | yes              | Runner                 | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
 | `services:[]`         | yes              | Runner                 | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 8ab17586b0a..31eaf645f37 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -272,7 +272,7 @@ This saves reviewers time and helps authors catch mistakes earlier.
 [Review the merge request](#reviewing-a-merge-request) thoroughly. When you are confident
 that it meets all requirements, you should:
 
-- Click the Approve button.
+- Select **Approve**.
 - `@` mention the author to generate a to-do notification, and advise them that their merge request has been reviewed and approved.
 - Request a review from a maintainer. Default to requests for a maintainer with [domain expertise](#domain-experts),
 however, if one isn't available or you think the merge request doesn't need a review by a [domain expert](#domain-experts), feel free to follow the [Reviewer roulette](#reviewer-roulette) suggestion.
diff --git a/doc/development/database_debugging.md b/doc/development/database_debugging.md
index 37b6fdf5e07..e749fd6453b 100644
--- a/doc/development/database_debugging.md
+++ b/doc/development/database_debugging.md
@@ -57,7 +57,7 @@ bundle exec rake db:reset RAILS_ENV=test
 
 Access the database via one of these commands (they all get you to the same place)
 
-```ruby
+```shell
 gdk psql -d gitlabhq_development
 bundle exec rails dbconsole -e development
 bundle exec rails db -e development
@@ -72,7 +72,7 @@ bundle exec rails db -e development
 
 ## Access the database with a GUI
 
-Most GUIs (DataGrid, RubyMine, DBeaver) require a TCP connection to the database, but by default
+Most GUIs (DataGrip, RubyMine, DBeaver) require a TCP connection to the database, but by default
 the database runs on a UNIX socket. To be able to access the database from these tools, some steps
 are needed:
 
diff --git a/doc/development/documentation/testing.md b/doc/development/documentation/testing.md
index 81e1eca8724..f69d6100c4e 100644
--- a/doc/development/documentation/testing.md
+++ b/doc/development/documentation/testing.md
@@ -321,12 +321,12 @@ To match the versions of `markdownlint-cli` and `vale` used in the GitLab projec
 [versions used (see `variables:` section)](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/.gitlab-ci.yml)
 when building the `image:docs-lint-markdown` Docker image containing these tools for CI/CD.
 
-| Tool               | Version   | Command                                   | Additional information |
-|--------------------|-----------|-------------------------------------------|------------------------|
-| `markdownlint-cli` | Latest    | `yarn global add markdownlint-cli`        | n/a                    |
-| `markdownlint-cli` | Specific  | `yarn global add markdownlint-cli@0.23.2` | The `@` indicates a specific version, and this example updates the tool to version `0.23.2`. |
-| Vale               | Latest    | `brew update && brew upgrade vale`        | This command is for macOS only. |
-| Vale               | Specific  | n/a                                       | Not possible using `brew`, but can be [directly downloaded](https://github.com/errata-ai/vale/releases). |
+| Tool               | Version   | Command                                                | Additional information |
+|--------------------|-----------|--------------------------------------------------------|------------------------|
+| `markdownlint-cli` | Latest    | `yarn global add markdownlint-cli`                     | None.                  |
+| `markdownlint-cli` | Specific  | `yarn global add markdownlint-cli@0.23.2`              | The `@` indicates a specific version, and this example updates the tool to version `0.23.2`. |
+| Vale               | Latest    | `brew update && brew upgrade vale`                     | This command is for macOS only. |
+| Vale               | Specific  | Not applicable.                                        | Binaries can be [directly downloaded](https://github.com/errata-ai/vale/releases). |
 
 ### Configure editors
 
diff --git a/doc/development/gemfile.md b/doc/development/gemfile.md
index e0f5a905831..389bdf1c5c9 100644
--- a/doc/development/gemfile.md
+++ b/doc/development/gemfile.md
@@ -138,8 +138,8 @@ To avoid upgrading indirect dependencies, we can use [`bundle update
 
 When submitting a merge request including a dependency update,
 include a link to the Gem diff between the 2 versions in the merge request
-description. You can find this link on `rubygems.org` under
-**Review Changes**. When you click it, RubyGems generates a comparison
+description. You can find this link on `rubygems.org`, select
+**Review Changes** to generate a comparison
 between the versions on `diffend.io`. For example, this is the gem
 diff for [`thor` 1.0.0 vs
 1.0.1](https://my.diffend.io/gems/thor/1.0.0/1.0.1). Use the
diff --git a/doc/development/uploads/working_with_uploads.md b/doc/development/uploads/working_with_uploads.md
index 9bc503e1fda..d44f2f69168 100644
--- a/doc/development/uploads/working_with_uploads.md
+++ b/doc/development/uploads/working_with_uploads.md
@@ -101,8 +101,8 @@ Therefore, document new uploads here by slotting them into the following tables:
 | Pipeline artifacts                       | `carrierwave`       | `sidekiq`               | `/artifacts/<proj_id_hash>/pipelines/<pipeline_id>/artifacts/<artifact_id>`                               |
 | Live job traces                          | `fog`               | `sidekiq`               | `/artifacts/tmp/builds/<job_id>/chunks/<chunk_index>.log`                                                 |
 | Job traces archive                       | `carrierwave`       | `sidekiq`               | `/artifacts/<proj_id_hash>/<date>/<job_id>/<artifact_id>/job.log`                                         |
-| Autoscale runner caching                 | N/A               | `gitlab-runner`         | `/gitlab-com-[platform-]runners-cache/???`                                                                |
-| Backups                                  | N/A               | `s3cmd`, `awscli`, or `gcs` | `/gitlab-backups/???`                                                                                     |
+| Autoscale runner caching                 | Not applicable      | `gitlab-runner`         | `/gitlab-com-[platform-]runners-cache/???`                                                                |
+| Backups                                  | Not applicable      | `s3cmd`, `awscli`, or `gcs` | `/gitlab-backups/???`                                                                                     |
 | Git LFS                                  | `direct upload`     | `workhorse`             | `/lfs-objects/<lfs_obj_oid[0:2]>/<lfs_obj_oid[2:2]>`                                                      |
 | Design management files                  | `disk buffering`    | `rails controller`      | `/lsf-objects/<lfs_obj_oid[0:2]>/<lfs_obj_oid[2:2]>`                                                      |
 | Design management thumbnails             | `carrierwave`       | `sidekiq`               | `/uploads/design_management/action/image_v432x230/<model_id>/<original_lfs_obj_oid[2:2]`                                             |
diff --git a/doc/install/aws/manual_install_aws.md b/doc/install/aws/manual_install_aws.md
index 0ec210856a0..efa71558856 100644
--- a/doc/install/aws/manual_install_aws.md
+++ b/doc/install/aws/manual_install_aws.md
@@ -705,7 +705,7 @@ From the EC2 dashboard:
 
 ### Create an auto scaling group
 
-1. As soon as the launch configuration is created, you'll see an option to **Create an Auto Scaling group using this launch configuration**. Click that to start creating the auto scaling group.
+1. After the launch configuration is created, select **Create an Auto Scaling group using this launch configuration** to start creating the auto scaling group.
 1. Enter a **Group name** (we'll use `gitlab-auto-scaling-group`).
 1. For **Group size**, enter the number of instances you want to start with (we'll enter `2`).
 1. Select the `gitlab-vpc` from the **Network** dropdown.
diff --git a/doc/install/google_cloud_platform/index.md b/doc/install/google_cloud_platform/index.md
index 76c1da74108..c30f9f49899 100644
--- a/doc/install/google_cloud_platform/index.md
+++ b/doc/install/google_cloud_platform/index.md
@@ -13,7 +13,7 @@ NOTE:
 To deploy production-ready GitLab on
 Google Kubernetes Engine,
 you can follow Google Cloud Platform's
-[Click to Deploy steps](https://github.com/GoogleCloudPlatform/click-to-deploy/blob/master/k8s/gitlab/README.md)
+[`Click to Deploy` steps](https://github.com/GoogleCloudPlatform/click-to-deploy/blob/master/k8s/gitlab/README.md)
 It's an alternative to using a GCP VM, and uses
 the [Cloud native GitLab Helm chart](https://docs.gitlab.com/charts/).
 
diff --git a/doc/operations/metrics/alerts.md b/doc/operations/metrics/alerts.md
index 37d9257bbc4..12bd975db5d 100644
--- a/doc/operations/metrics/alerts.md
+++ b/doc/operations/metrics/alerts.md
@@ -36,7 +36,7 @@ Alerts can be used to trigger actions, like opening an issue automatically
 1. Enable the option to create issues.
 1. Choose the [issue template](../../user/project/description_templates.md) to create the issue from.
 1. Optionally, select whether to send an email notification to the developers of the project.
-1. Click **Save changes**.
+1. Select **Save changes**.
 
 After enabling, GitLab automatically opens an issue when an alert is triggered containing
 values extracted from the [`alerts` field in webhook payload](https://prometheus.io/docs/alerting/latest/configuration/#webhook_config):
diff --git a/doc/operations/metrics/dashboards/develop.md b/doc/operations/metrics/dashboards/develop.md
index 513e5532bee..e09f56e27cf 100644
--- a/doc/operations/metrics/dashboards/develop.md
+++ b/doc/operations/metrics/dashboards/develop.md
@@ -23,14 +23,14 @@ Navigate to the browser-based editor of your choice:
 - In the **Repository view**:
 
   1. Navigate to **{doc-text}** **Repository > Files**.
-  1. Click **{plus}** **Add to tree** and select **New file**,
-     then click **Select a template type** to see a list of available templates:
+  1. Select **{plus}** **Add to tree** and select **New file**,
+     then select **Select a template type** to see a list of available templates:
      ![Metrics dashboard template selection](img/metrics_dashboard_template_selection_v13_3.png)
 
 - In the **[Web IDE](../../../user/project/web_ide/index.md)**:
 
-  1. Click **Web IDE** when viewing your repository.
-  1. Click **{doc-new}** **New file**, then click **Choose a template** to see a list of available templates:
+  1. Select **Web IDE** when viewing your repository.
+  1. Select **{doc-new}** **New file**, then select **Choose a template** to see a list of available templates:
      ![Metrics dashboard template selection WebIDE](img/metrics_dashboard_template_selection_web_ide_v13_3.png)
 
 ## Custom dashboard templates **(PREMIUM SELF)**
diff --git a/doc/operations/metrics/dashboards/settings.md b/doc/operations/metrics/dashboards/settings.md
index aae5a623420..45f0e906e9c 100644
--- a/doc/operations/metrics/dashboards/settings.md
+++ b/doc/operations/metrics/dashboards/settings.md
@@ -28,12 +28,12 @@ time zone:
 
 1. Sign in as a user with Manage Project Operations [permissions](../../../user/permissions.md).
 1. Navigate to **Settings > Monitor**.
-1. Scroll to **Metrics Dashboard** and click **Expand**.
+1. Scroll to **Metrics Dashboard** and select **Expand**.
 1. In the **Dashboard timezone** select box, select *User's local timezone*
    or *UTC*:
 
    ![Dashboard timezone setting](img/dashboard_local_timezone_v13_1.png)
-1. Click **Save changes**.
+1. Select **Save changes**.
 
 ## Link to an external dashboard
 
@@ -44,12 +44,12 @@ existing external dashboards:
 
 1. Sign in as a user with Manage Project Operations [permissions](../../../user/permissions.md).
 1. Navigate to **Settings > Monitor**.
-1. Scroll to **Metrics Dashboard** and click **Expand**.
+1. Scroll to **Metrics Dashboard** and select **Expand**.
 1. In **External dashboard URL**, provide the URL to your external dashboard:
 
    ![External Dashboard Setting](img/dashboard_external_link_v13_1.png)
 
-1. Click **Save changes**.
+1. Select **Save changes**.
 
 GitLab displays a **View full dashboard** button in the top right corner of your
 [monitoring dashboard](../../../ci/environments/index.md#monitor-environments)
diff --git a/doc/operations/metrics/embed.md b/doc/operations/metrics/embed.md
index 44b998dc3ee..3fd5daba4fb 100644
--- a/doc/operations/metrics/embed.md
+++ b/doc/operations/metrics/embed.md
@@ -48,8 +48,8 @@ GitLab unfurls the link as an embedded metrics panel:
 
 ![Embedded Metrics Rendered](img/embedded_metrics_rendered_v13_4.png)
 
-You can also embed a single chart. To get a link to a chart, click the
-**{ellipsis_v}** **More actions** menu in the upper right corner of the chart,
+You can also embed a single chart. To get a link to a chart, select
+**{ellipsis_v}** **More actions** in the upper right corner of the chart,
 and select **Copy link to chart**, as shown in this example:
 
 ![Copy Link To Chart](img/copy_link_to_chart_v12_10.png)
diff --git a/doc/operations/metrics/index.md b/doc/operations/metrics/index.md
index 937bd329570..916fe6b0ea9 100644
--- a/doc/operations/metrics/index.md
+++ b/doc/operations/metrics/index.md
@@ -87,7 +87,7 @@ navigation bar contains:
   [custom dashboards](dashboards/index.md).
   ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34779) in GitLab 12.5.)
   - **Duplicate current dashboard** - Save a [complete copy of a dashboard](dashboards/index.md#duplicate-a-gitlab-defined-dashboard). Only available on GitLab-defined dashboards.
-  - **Star dashboard** **{star-o}** - Click to mark a dashboard as a favorite.
+  - **Star dashboard** **{star-o}** - Mark a dashboard as a favorite.
   Starred dashboards display a solid star **{star}** button, and display first
   in the **Dashboard** dropdown list.
   ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214582) in GitLab 13.0.)
diff --git a/doc/subscriptions/index.md b/doc/subscriptions/index.md
index fbc68094f96..4caf69d6015 100644
--- a/doc/subscriptions/index.md
+++ b/doc/subscriptions/index.md
@@ -53,8 +53,8 @@ at each tier for each product, see:
 
 ## Find your subscription
 
-The following chart should help you determine your subscription model. Click
-on the list item to go to the respective help page.
+The following chart should help you determine your subscription model. Select
+the list item to go to the respective help page.
 
 ```mermaid
 graph TD
@@ -164,7 +164,7 @@ Only one namespace can be linked to a subscription.
 To change the password for this customers portal account:
 
 1. Log in to the [Customers Portal](https://customers.gitlab.com/customers/sign_in).
-1. Select the **My account** drop-down and select on **Account details**.
+1. Select the **My account** drop-down and select **Account details**.
 1. Make the required changes to the **Your password** section.
 1. Select **Save changes**.
 
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 44c7a781c2e..74915a88b50 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -1565,23 +1565,6 @@ In GitLab 15.0 and later, the default value for this configuration option will c
 **Planned removal milestone: <span class="removal-milestone">15.0</span> (2022-05-22)**
 </div>
 
-<div class="deprecation removal-150 breaking-change">
-
-### Must explicitly assign `AuthenticationType` for `[runners.cache.s3]`
-
-WARNING:
-This feature will be changed or removed in 15.0
-as a [breaking change](https://docs.gitlab.com/ee/development/contributing/#breaking-changes).
-Before updating GitLab, review the details carefully to determine if you need to make any
-changes to your code, settings, or workflow.
-
-In GitLab 15.0 and later, to access the AWS S3 cache, you must specify the `AuthenticationType` for [`[runners.cache.s3]`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscaches3-section). The `AuthenticationType` must be `IAM` or `credentials`.
-
-Prior to 14.5, if you did not define the `AuthenticationType`, GitLab Runner chose a type for you.
-
-**Planned removal milestone: <span class="removal-milestone">15.0</span> (2022-05-22)**
-</div>
-
 <div class="deprecation removal-160 breaking-change">
 
 ### Package pipelines in API payload is paginated
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 2828b56a5d1..3f80f52c97a 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -260,7 +260,7 @@ Support depends on which scanner is used:
 | Distribution   | Grype | Trivy |
 | -------------- | ----- | ----- |
 | Alma Linux     |       |  ✅   |
-| Alpine Linux   |  ✅   |       |
+| Alpine Linux   |  ✅   |  ✅   |
 | Amazon Linux   |  ✅   |  ✅   |
 | BusyBox        |  ✅   |       |
 | CentOS         |  ✅   |  ✅   |
diff --git a/doc/user/application_security/policies/scan-execution-policies.md b/doc/user/application_security/policies/scan-execution-policies.md
index 4ff1bb60c51..884b9ad7f0d 100644
--- a/doc/user/application_security/policies/scan-execution-policies.md
+++ b/doc/user/application_security/policies/scan-execution-policies.md
@@ -86,9 +86,8 @@ This rule enforces the defined actions and schedules a scan on the provided date
 | `type`     | `string` | `schedule` | The rule's type. |
 | `branches` | `array` of `string` | `*` or the branch's name | The branch the given policy applies to (supports wildcard). |
 | `cadence`  | `string` | CRON expression (for example, `0 0 * * *`) | A whitespace-separated string containing five fields that represents the scheduled time. |
-| `agents`   | `object` | | The name of the [GitLab agents](../../clusters/agent/index.md) where [cluster image scanning](../../clusters/agent/vulnerabilities.md) will run. The key of the object is the name of the Kubernetes cluster configured for your project in GitLab. In the optionally provided value of the object, you can precisely select Kubernetes resources that are scanned. | <!--- start_remove The following content will be removed on remove_date: '2022-08-22' -->
-| `clusters` (removed) | `object` | | This field was [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/356465) in 15.0. Use the `agents` field instead. The cluster where the given policy enforces running selected scans (only for `container_scanning`/`cluster_image_scanning` scans). The key of the object is the name of the Kubernetes cluster configured for your project in GitLab. In the optionally provided value of the object, you can precisely select Kubernetes resources that are scanned. |
-<!--- end_remove -->
+| `agents`   | `object` | | The name of the [GitLab agents](../../clusters/agent/index.md) where [cluster image scanning](../../clusters/agent/vulnerabilities.md) will run. The key of the object is the name of the Kubernetes cluster configured for your project in GitLab. In the optionally provided value of the object, you can precisely select Kubernetes resources that are scanned. <!--- start_remove The following content will be removed on remove_date: '2022-08-22' --> |
+| `clusters` (removed) | `object` | | This field was [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/356465) in 15.0. Use the `agents` field instead. The cluster where the given policy enforces running selected scans (only for `container_scanning`/`cluster_image_scanning` scans). The key of the object is the name of the Kubernetes cluster configured for your project in GitLab. In the optionally provided value of the object, you can precisely select Kubernetes resources that are scanned. <!--- end_remove --> |
 
 GitLab supports the following types of CRON syntax for the `cadence` field:
 
diff --git a/doc/user/application_security/vulnerabilities/index.md b/doc/user/application_security/vulnerabilities/index.md
index 87344e4ff65..f5b1192269d 100644
--- a/doc/user/application_security/vulnerabilities/index.md
+++ b/doc/user/application_security/vulnerabilities/index.md
@@ -4,13 +4,14 @@ group: Threat Insights
 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/#assignments
 ---
 
-# Vulnerability Pages **(ULTIMATE)**
+# Vulnerability Page **(ULTIMATE)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13561) in GitLab 13.0.
 
-Each vulnerability in a project has a Vulnerability Page. This page contains details of the
-vulnerability. The details included vary according to the type of vulnerability. Details of each
-vulnerability include:
+Each vulnerability in a project has a Vulnerability Page, containing details of the
+vulnerability. The details included vary according to the type of vulnerability.
+
+Details of each vulnerability include:
 
 - Description
 - When it was detected
@@ -24,32 +25,41 @@ alert message is included at the top of the vulnerability's page.
 
 On the vulnerability's page, you can:
 
-- [Change the vulnerability's status](#change-vulnerability-status).
-- [Create an issue](#create-an-issue-for-a-vulnerability).
-- [Link issues to the vulnerability](#linked-issues).
-- [Resolve a vulnerability](#resolve-a-vulnerability) if a solution is
+- [Change the vulnerability's status](#change-status-of-a-vulnerability).
+- [Create an issue](#creating-an-issue-for-a-vulnerability).
+- [Link issues to the vulnerability](#linking-a-vulnerability-to-issues).
+- [Resolve the vulnerability](#resolve-a-vulnerability) if a solution is
   available.
 - [View security training specific to the detected vulnerability](#view-security-training-for-a-vulnerability).
 
 ## Vulnerability status values
 
-A vulnerability's status can be one of the following:
+A vulnerability's status can be:
 
-| Status    | Description |
-|:----------|:------------|
-| Detected  | The default state for a newly discovered vulnerability. Appears as "Needs triage" in the UI. |
-| Confirmed | A user has seen this vulnerability and confirmed it to be accurate. |
-| Dismissed | A user has seen this vulnerability and dismissed it because it is not accurate or otherwise not to be resolved. |
-| Resolved  | The vulnerability has been fixed or is no longer present. |
+- **Detected**: The default state for a newly discovered vulnerability. Appears as "Needs triage" in the UI.
+- **Confirmed**: A user has seen this vulnerability and confirmed it to be accurate.
+- **Dismissed**: A user has seen this vulnerability and dismissed it because it is not accurate or otherwise not to be resolved.
+- **Resolved**: The vulnerability has been fixed or is no longer present.
 
-Dismissed vulnerabilities are ignored if detected in subsequent scans. Resolved vulnerabilities that are reintroduced and detected by subsequent scans have a _new_ vulnerability record created. When an existing vulnerability is no longer detected in a project's `default` branch, you should change its status to Resolved. This ensures that if it is accidentally reintroduced in a future merge, it will be visible again as a new record. You can use the [Activity filter](../vulnerability_report/#activity-filter) to select all vulnerabilities that are no longer detected, and [change their status](../vulnerability_report#change-status-of-vulnerabilities).
+Dismissed vulnerabilities are ignored if detected in subsequent scans. Resolved vulnerabilities that
+are reintroduced and detected by subsequent scans have a _new_ vulnerability record created. When an
+existing vulnerability is no longer detected in a project's `default` branch, you should change its
+status to **Resolved**. This ensures that if it is accidentally reintroduced in a future merge, it
+is reported again as a new record. You can use the Vulnerability Report's
+[Activity filter](../vulnerability_report/#activity-filter) to select all vulnerabilities that are
+no longer detected, and change their status.
 
-## Change vulnerability status
+## Change status of a vulnerability
 
-To change a vulnerability's status, select a new value from the **Status** dropdown then select
-**Change status**. Optionally, add a comment to the log entry at the bottom of the page.
+To change a vulnerability's status from its Vulnerability Page:
 
-## Create an issue for a vulnerability
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
+1. Select the vulnerability's description.
+1. From the **Status** dropdown list select a status, then select **Change status**.
+1. Optionally, at the bottom of the page, add a comment to the log entry.
+
+## Creating an issue for a vulnerability
 
 From a vulnerability's page you can create an issue to track all action taken to resolve or
 mitigate it.
@@ -67,7 +77,9 @@ that when Jira integration is enabled, the GitLab issue feature is not available
 
 To create a GitLab issue for a vulnerability:
 
-1. In GitLab, go to the vulnerability's page.
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
+1. Select the vulnerability's description.
 1. Select **Create issue**.
 
 An issue is created in the project, pre-populated with information from the vulnerability report.
@@ -80,73 +92,85 @@ The issue is then opened so you can take further action.
 
 Prerequisites:
 
-- [Enable Jira integration](../../../integration/jira/index.md).
-  The **Enable Jira issue creation from vulnerabilities** option must be selected as part of the configuration.
-- Each user must have a personal Jira user account with permission to create issues in the target project.
+- [Enable Jira integration](../../../integration/jira/index.md). The **Enable Jira issue creation
+  from vulnerabilities** option must be selected as part of the configuration.
+- Each user must have a personal Jira user account with permission to create issues in the target
+  project.
 
 To create a Jira issue for a vulnerability:
 
-1. Go to the vulnerability's page.
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
+1. Select the vulnerability's description.
 1. Select **Create Jira issue**.
 1. If you're not already logged in to Jira, log in.
 
 The Jira issue is created and opened in a new browser tab. The **Summary** and **Description**
 fields are pre-populated from the vulnerability's details.
 
-Unlike GitLab issues, the status of whether a Jira issue is open or closed does not display in the GitLab user interface.
+Unlike GitLab issues, the status of whether a Jira issue is open or closed does not display in the
+GitLab user interface.
 
-## Linked issues
+## Linking a vulnerability to issues
 
 NOTE:
 If Jira issue support is enabled, GitLab issues are disabled so this feature is not available.
 
-You can link one or more existing GitLab issues to a vulnerability. Adding a link helps track
+You can link a vulnerability to one or more existing GitLab issues. Adding a link helps track
 the issue that resolves or mitigates a vulnerability.
 
 Issues linked to a vulnerability are shown in the Vulnerability Report and the vulnerability's page.
 
 Be aware of the following conditions between a vulnerability and a linked issue:
 
-- The vulnerability page shows related issues, but the issue page doesn't show the vulnerability it's related to.
+- The vulnerability page shows related issues, but the issue page doesn't show the vulnerability
+  it's related to.
 - An issue can only be related to one vulnerability at a time.
 - Issues can be linked across groups and projects.
 
-## Link to existing issues
+## Link a vulnerability to existing issues
 
 To link a vulnerability to existing issues:
 
-1. Go to the vulnerability's page.
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
+1. Select the vulnerability's description.
 1. In the **Linked issues** section, select the plus icon (**{plus}**).
 1. For each issue to be linked, either:
    - Paste a link to the issue.
    - Enter the issue's ID (prefixed with a hash `#`).
 1. Select **Add**.
 
-The selected issues are added to the **Linked issues** section, and the linked issues counter is updated.
+The selected issues are added to the **Linked issues** section, and the linked issues counter is
+updated.
 
 ## Resolve a vulnerability
 
 For some vulnerabilities a solution is already known. In those instances, a vulnerability's page
 includes a **Resolve with merge request** option.
 
-To resolve a vulnerability, you can either:
-
-- [Resolve a vulnerability with a merge request](#resolve-a-vulnerability-with-a-merge-request).
-- [Resolve a vulnerability manually](#resolve-a-vulnerability-manually).
-
-The following scanners are supported:
+The following scanners are supported by this feature:
 
 - [Dependency Scanning](../dependency_scanning/index.md).
   Automatic Patch creation is only available for Node.js projects managed with
   `yarn`.
 - [Container Scanning](../container_scanning/index.md).
 
+To resolve a vulnerability, you can either:
+
+- [Resolve a vulnerability with a merge request](#resolve-a-vulnerability-with-a-merge-request).
+- [Resolve a vulnerability manually](#resolve-a-vulnerability-manually).
+
 ![Create merge request from vulnerability](img/create_mr_from_vulnerability_v13_4.png)
 
 ### Resolve a vulnerability with a merge request
 
-To resolve the vulnerability with a merge request, go to the vulnerability's page and from the
-**Resolve with merge request** dropdown select **Resolve with merge request**.
+To resolve the vulnerability with a merge request:
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
+1. Select the vulnerability's description.
+1. From the **Resolve with merge request** dropdown list, select **Resolve with merge request**.
 
 A merge request is created which applies the patch required to resolve the vulnerability.
 Process the merge request according to your standard workflow.
@@ -155,11 +179,15 @@ Process the merge request according to your standard workflow.
 
 To manually apply the patch that GitLab generated for a vulnerability:
 
-1. Go to the vulnerability's page and from the **Resolve with merge request** dropdown select
-   **Download patch to resolve**.
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
+1. Select the vulnerability's description.
+1. From the **Resolve with merge request** dropdown list, select **Download patch to resolve**.
 1. Ensure your local project has the same commit checked out that was used to generate the patch.
 1. Run `git apply remediation.patch`.
 1. Verify and commit the changes to your branch.
+1. Create a merge request to apply the changes to your main branch.
+1. Process the merge request according to your standard workflow.
 
 ## Enable security training for vulnerabilities
 
diff --git a/doc/user/application_security/vulnerability_report/index.md b/doc/user/application_security/vulnerability_report/index.md
index 7c1ea6a4e3c..54663235d91 100644
--- a/doc/user/application_security/vulnerability_report/index.md
+++ b/doc/user/application_security/vulnerability_report/index.md
@@ -23,7 +23,7 @@ The **Activity** column contains icons to indicate the activity, if any, taken o
 in that row:
 
 - Issues **{issues}**: Links to issues created for the vulnerability. For more details, read
-  [Create an issue for a vulnerability](../vulnerabilities/index.md#create-an-issue-for-a-vulnerability).
+  [Create an issue for a vulnerability](../vulnerabilities/index.md#creating-an-issue-for-a-vulnerability).
 - Wrench **{admin}**: The vulnerability has been remediated.
 - False positive **{false-positive}**: The scanner determined this vulnerability to be a false
   positive.
diff --git a/doc/user/clusters/agent/index.md b/doc/user/clusters/agent/index.md
index d54d432f0f5..54259b9fc26 100644
--- a/doc/user/clusters/agent/index.md
+++ b/doc/user/clusters/agent/index.md
@@ -70,4 +70,5 @@ Read about how to [migrate to the agent for Kubernetes](../../infrastructure/clu
 - [Install the agent](install/index.md)
 - [Work with the agent](repository.md)
 - [Troubleshooting](troubleshooting.md)
+- [Guided explorations for a production ready GitOps setup](https://gitlab.com/groups/guided-explorations/gl-k8s-agent/gitops/-/wikis/home#gitlab-agent-for-kubernetes-gitops-working-examples)
 - [Contribute to the agent's development](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/tree/master/doc)
diff --git a/doc/user/infrastructure/clusters/connect/img/variables_civo.png b/doc/user/infrastructure/clusters/connect/img/variables_civo.png
new file mode 100644
index 00000000000..5a20478b13c
Binary files /dev/null and b/doc/user/infrastructure/clusters/connect/img/variables_civo.png differ
diff --git a/doc/user/infrastructure/clusters/connect/new_civo_cluster.md b/doc/user/infrastructure/clusters/connect/new_civo_cluster.md
new file mode 100644
index 00000000000..67930722d04
--- /dev/null
+++ b/doc/user/infrastructure/clusters/connect/new_civo_cluster.md
@@ -0,0 +1,137 @@
+---
+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/#assignments
+---
+
+# Create a Civo Kubernetes cluster
+
+Every new Civo account receives [$250 in credit](https://civo.com/signup) to get started with the GitLab integration with Civo Kubernetes. You can also use a marketplace app to install GitLab on your Civo Kubernetes cluster.
+
+Learn how to create a new cluster on Civo Kubernetes through
+[Infrastructure as Code (IaC)](../../index.md). This process uses the Civo
+and Kubernetes Terraform providers to create Civo Kubernetes clusters. You connect the clusters to GitLab
+by using the GitLab agent for Kubernetes.
+
+**Prerequisites:**
+
+- A [Civo account](https://civo.com/signup).
+- [A runner](https://docs.gitlab.com/runner/install/) you can use to run the GitLab CI/CD pipeline.
+
+**Steps:**
+
+1. [Import the example project](#import-the-example-project).
+1. [Register the agent for Kubernetes](#register-the-agent).
+1. [Configure your project](#configure-your-project).
+1. [Provision your cluster](#provision-your-cluster).
+
+## Import the example project
+
+To create a cluster from GitLab using Infrastructure as Code, you must
+create a project to manage the cluster from. In this tutorial, you start with
+a sample project and modify it according to your needs.
+
+Start by [importing the example project by URL](../../../project/import/repo_by_url.md).
+
+To import the project:
+
+1. On the top bar, select **Menu > Create new project**.
+1. Select **Import project**.
+1. Select **Repo by URL**.
+1. For the **Git repository URL**, enter `https://gitlab.com/civocloud/gitlab-terraform-civo.git`.
+1. Complete the fields and select **Create project**.
+
+This project provides you with:
+
+- A [cluster on Civo](https://gitlab.com/civocloud/gitlab-terraform-civo/-/blob/master/civo.tf) with defaults for name, region, node count, and Kubernetes version.
+- The [GitLab agent for Kubernetes](https://gitlab.com/civocloud/gitlab-terraform-civo/-/blob/master/agent.tf) installed in the cluster.
+
+## Register the agent
+
+To create a GitLab agent for Kubernetes:
+
+1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
+1. Select **Connect a cluster (agent)**.
+1. From the **Select an agent** dropdown list, select `civo-agent` and select **Register an agent**.
+1. GitLab generates a registration token for the agent. Securely store this secret token, as you will need it later.
+1. GitLab provides an address for the agent server (KAS), which you will also need later.
+
+## Configure your project
+
+Use CI/CD environment variables to configure your project.
+
+**Required configuration:**
+
+1. On the left sidebar, select **Settings > CI/CD**.
+1. Expand **Variables**.
+1. Set the variable `BASE64_CIVO_CREDENTIALS` to the [token](https://www.civo.com/account/security) from your Civo account. 
+1. Set the variable `TF_VAR_agent_token` to the agent token you received in the previous task.
+1. Set the variable `TF_VAR_kas_address` to the agent server address in the previous task.
+
+![img/variables_civo.png](img/variables_civo.png)
+
+**Optional configuration:**
+
+The file [`variables.tf`](https://gitlab.com/civocloud/gitlab-terraform-civo/-/blob/master/variables.tf)
+contains other variables that you can override according to your needs:
+
+- `TF_VAR_civo_region`: Set your cluster's region.
+- `TF_VAR_cluster_name`: Set your cluster's name.
+- `TF_VAR_cluster_description`: Set a description for the cluster. To create a reference to your GitLab project on your Civo cluster detail page, set this value to `$CI_PROJECT_URL`. This value helps you determine which project was responsible for provisioning the cluster you see on the Civo dashboard.
+- `TF_VAR_machine_type`: Set the machine type for the Kubernetes nodes.
+- `TF_VAR_node_count`: Set the number of Kubernetes nodes.
+- `TF_VAR_agent_version`: Set the version of the GitLab agent.
+- `TF_VAR_agent_namespace`: Set the Kubernetes namespace for the GitLab agent.
+
+Refer to the [Civo Terraform provider](https://registry.terraform.io/providers/civo/civo/latest/docs/resources/kubernetes_cluster) and the [Kubernetes Terraform provider](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs) documentation for further resource options.
+
+## Provision your cluster
+
+After configuring your project, manually trigger the provisioning of your cluster. In GitLab:
+
+1. On the left sidebar, go to **CI/CD > Pipelines**.
+1. Next to **Play** (**{play}**), select the dropdown icon (**{angle-down}**).
+1. Select **Deploy** to manually trigger the deployment job.
+
+When the pipeline finishes successfully, you can see your new cluster:
+
+- In Civo dashboard: on your [Kubernetes tab](https://www.civo.com/account/kubernetes).
+- In GitLab: from your project's sidebar, select **Infrastructure > Kubernetes clusters**.
+
+## Use your cluster
+
+After you provision the cluster, it is connected to GitLab and is ready for deployments. To check the connection:
+
+1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
+1. In the list, view the **Connection status** column.
+
+For more information about the capabilities of the connection, see [the GitLab agent for Kubernetes documentation](../index.md).
+
+## Remove the cluster
+
+A cleanup job is not included in your pipeline by default. To remove all created resources, you
+must modify your GitLab CI/CD template before running the cleanup job.
+
+To remove all resources:
+
+1. Add the following to your `.gitlab-ci.yml` file:
+
+    ```yaml
+    stages:
+      - init
+      - validate
+      - build
+      - deploy
+      - cleanup
+
+    destroy:
+      extends: .destroy
+      needs: []
+    ```
+
+1. On the left sidebar, select **CI/CD > Pipelines** and select the most recent pipeline.
+1. For the `destroy` job, select **Play** (**{play}**).
+
+## Civo support
+
+This Civo integration is supported by Civo. Send your support requests to [Civo support](https://www.civo.com/contact).
diff --git a/doc/user/project/merge_requests/approvals/rules.md b/doc/user/project/merge_requests/approvals/rules.md
index 17a42e1b540..21cf5cca4d1 100644
--- a/doc/user/project/merge_requests/approvals/rules.md
+++ b/doc/user/project/merge_requests/approvals/rules.md
@@ -250,6 +250,10 @@ For more information about this validation error, read
 You can use [scan result policies](../../../application_security/policies/scan-result-policies.md#scan-result-policy-editor) to define security approvals based on the status of vulnerabilities in the merge request and the default branch.
 Details for each security policy is shown in the Security Approvals section of your Merge Request configuration.
 
+The security approval rules are applied to all merge requests until the pipeline is complete. The application of the
+security approval rules prevents users from merging in code before the security scans run. Once the pipeline is
+complete, the security approval rules are checked to determine if the security approvals are still required.
+
 ![Security Approvals](img/security_approvals_v15_0.png)
 
 These policies are both created and edited in the [security policy editor](../../../application_security/policies/index.md#policy-editor).
diff --git a/doc/user/project/merge_requests/test_coverage_visualization.md b/doc/user/project/merge_requests/test_coverage_visualization.md
index 50ef9e86a02..87c08ce5d62 100644
--- a/doc/user/project/merge_requests/test_coverage_visualization.md
+++ b/doc/user/project/merge_requests/test_coverage_visualization.md
@@ -68,6 +68,11 @@ A single Cobertura XML file can be no more than 10MiB. For large projects, split
 smaller files. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/328772) for more details.
 When submitting many files, it can take a few minutes for coverage to show on a merge request.
 
+The visualization only displays after the pipeline is complete. If the pipeline has
+a [blocking manual job](../../../ci/jobs/job_control.md#types-of-manual-jobs), the
+pipeline waits for the manual job before continuing and is not considered complete.
+The visualization cannot be displayed if the blocking manual job did not run.
+
 ### Artifact expiration
 
 By default, the [pipeline artifact](../../../ci/pipelines/pipeline_artifacts.md#storage) used
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index 58ca895693f..e4391c37da7 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -33822,9 +33822,6 @@ msgstr ""
 msgid "SecurityOrchestration|Policy definition"
 msgstr ""
 
-msgid "SecurityOrchestration|Policy description"
-msgstr ""
-
 msgid "SecurityOrchestration|Policy editor"
 msgstr ""
 
diff --git a/spec/initializers/omniauth_spec.rb b/spec/initializers/omniauth_spec.rb
index 928eac8c533..f0a73162dd2 100644
--- a/spec/initializers/omniauth_spec.rb
+++ b/spec/initializers/omniauth_spec.rb
@@ -3,7 +3,7 @@
 require 'spec_helper'
 
 RSpec.describe 'OmniAuth initializer for GitLab' do
-  let(:load_omniauth_initializer) do
+  def load_omniauth_initializer
     load Rails.root.join('config/initializers/omniauth.rb')
   end
 
@@ -15,32 +15,15 @@ RSpec.describe 'OmniAuth initializer for GitLab' do
     before do
       allow(Settings).to receive(:gitlab).and_return({ 'base_url' => base_url })
       allow(Gitlab::OmniauthInitializer).to receive(:full_host).and_return('proc')
+
+      load_omniauth_initializer
     end
 
-    context 'with feature flags not available' do
-      before do
-        expect(Feature).to receive(:feature_flags_available?).and_return(false)
-        load_omniauth_initializer
-      end
-
-      it { is_expected.to eq(base_url) }
+    # to clear existing mocks and prevent order-dependent failures
+    after(:all) do
+      load_omniauth_initializer
     end
 
-    context 'with the omniauth_initializer_fullhost_proc FF disabled' do
-      before do
-        stub_feature_flags(omniauth_initializer_fullhost_proc: false)
-        load_omniauth_initializer
-      end
-
-      it { is_expected.to eq(base_url) }
-    end
-
-    context 'with the omniauth_initializer_fullhost_proc FF disabled' do
-      before do
-        load_omniauth_initializer
-      end
-
-      it { is_expected.to eq('proc') }
-    end
+    it { is_expected.to eq('proc') }
   end
 end