diff --git a/doc/administration/nfs.md b/doc/administration/nfs.md
index a7009b702ed..59b18f7a74a 100644
--- a/doc/administration/nfs.md
+++ b/doc/administration/nfs.md
@@ -365,21 +365,26 @@ You may be able to avoid timeouts and data loss using `actimeo=0` and `lookupcac
 we expect the performance reduction will still be significant. As noted above, we strongly recommend upgrading to
 [Gitaly Cluster](gitaly/praefect.md) as soon as possible.
 
-### Avoid using AWS's Elastic File System (EFS)
+### Avoid using cloud-based file systems
 
-GitLab strongly recommends against using AWS Elastic File System (EFS).
-Our support team will not be able to assist on performance issues related to
-file system access.
+GitLab strongly recommends against using cloud-based file systems such as:
 
-Customers and users have reported that AWS EFS does not perform well for the GitLab
-use-case. Workloads where many small files are written in a serialized manner, like `git`,
-are not well-suited for EFS. EBS with an NFS server on top will perform much better.
+- AWS Elastic File System (EFS).
+- Google Cloud Filestore.
+- Azure Files.
 
-If you do choose to use EFS, avoid storing GitLab log files (e.g. those in `/var/log/gitlab`)
+Our support team cannot assist with performance issues related to cloud-based file system access.
+
+Customers and users have reported that these file systems don't perform well for
+the file system access GitLab requires. Workloads where many small files are written in
+a serialized manner, like `git`, are not well suited to cloud-based file systems.
+
+If you do choose to use these, avoid storing GitLab log files (for example, those in `/var/log/gitlab`)
 there because this will also affect performance. We recommend that the log files be
 stored on a local volume.
 
-For more details on another person's experience with EFS, see this [Commit Brooklyn 2019 video](https://youtu.be/K6OS8WodRBQ?t=313).
+For more details on the experience of using a cloud-based file systems with GitLab,
+see this [Commit Brooklyn 2019 video](https://youtu.be/K6OS8WodRBQ?t=313).
 
 ### Avoid using CephFS and GlusterFS
 
diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md
index edae25f66fc..44d1eacb295 100644
--- a/doc/install/aws/index.md
+++ b/doc/install/aws/index.md
@@ -584,7 +584,7 @@ Let's create an EC2 instance where we'll install Gitaly:
 1. Finally, acknowledge that you have access to the selected private key file or create a new one. Click **Launch Instances**.
 
 NOTE:
-Instead of storing configuration _and_ repository data on the root volume, you can also choose to add an additional EBS volume for repository storage. Follow the same guidance as above. See the [Amazon EBS pricing](https://aws.amazon.com/ebs/pricing/). We do not recommend using EFS as it may negatively impact the performance of GitLab. You can review the [relevant documentation](../../administration/nfs.md#avoid-using-awss-elastic-file-system-efs) for more details.
+Instead of storing configuration _and_ repository data on the root volume, you can also choose to add an additional EBS volume for repository storage. Follow the same guidance as above. See the [Amazon EBS pricing](https://aws.amazon.com/ebs/pricing/). We do not recommend using EFS as it may negatively impact the performance of GitLab. You can review the [relevant documentation](../../administration/nfs.md#avoid-using-cloud-based-file-systems) for more details.
 
 Now that we have our EC2 instance ready, follow the [documentation to install GitLab and set up Gitaly on its own server](../../administration/gitaly/index.md#run-gitaly-on-its-own-server). Perform the client setup steps from that document on the [GitLab instance we created](#install-gitlab) above.
 
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index ccd7c324e9a..f306e8be13c 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -110,7 +110,8 @@ Apart from a local hard drive you can also mount a volume that supports the netw
 If you have enough RAM and a recent CPU the speed of GitLab is mainly limited by hard drive seek times. Having a fast drive (7200 RPM and up) or a solid state drive (SSD) will improve the responsiveness of GitLab.
 
 NOTE:
-Since file system performance may affect the overall performance of GitLab, [we don't recommend using AWS EFS for storage](../administration/nfs.md#avoid-using-awss-elastic-file-system-efs).
+Since file system performance may affect the overall performance of GitLab,
+[we don't recommend using cloud-based file systems for storage](../administration/nfs.md#avoid-using-cloud-based-file-systems).
 
 ### CPU
 
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 00cf23d8ffd..97aa70d1fc6 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -629,7 +629,7 @@ directory that you want to copy the tarballs to is the root of your mounted
 directory, use `.` instead.
 
 Because file system performance may affect overall GitLab performance,
-[GitLab doesn't recommend using EFS for storage](../administration/nfs.md#avoid-using-awss-elastic-file-system-efs).
+[GitLab doesn't recommend using cloud-based file systems for storage](../administration/nfs.md#avoid-using-cloud-based-file-systems).
 
 For Omnibus GitLab packages:
 
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index 68ee85cd502..d632fc47249 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -430,30 +430,26 @@ To restore a group that is marked for deletion:
 Prevent projects in a group from [sharing
 a project with another group](../project/members/share_project_with_groups.md) to enable tighter control over project access.
 
-For example, let's say you have two distinct teams (Group A and Group B) working together in a project, and to inherit the group membership, you share the project between the
-two groups A and B. **Share with group lock** prevents any project in
-the group from being shared with another group,
-guaranteeing that only the right group members have access to those projects.
-
-To prevent a project from being shared with groups:
+To prevent a project from being shared with other groups:
 
 1. Go to the group's **Settings > General** page.
-1. Select **Share with group lock**.
-1. Select **Save the group**.
+1. Expand the **Permissions, LFS, 2FA** section.
+1. Select **Prevent sharing a project within <group_name> with other groups**.
+1. Select **Save changes**.
 
 ## Prevent members from being added to a group **(PREMIUM)**
 
-Member lock lets a group owner prevent any new project membership to all of the
+As a group owner, you can prevent any new project membership for all
 projects in a group, allowing tighter control over project membership.
 
 For example, if you want to lock the group for an [Audit Event](../../administration/audit_events.md),
-enable member lock to guarantee that project membership cannot be modified during the audit.
+you can guarantee that project membership cannot be modified during the audit.
 
 To prevent members from being added to a group:
 
 1. Go to the group's **Settings > General** page.
 1. Expand the **Permissions, LFS, 2FA** section.
-1. Select **Member lock**.
+1. Under **Member lock**, select **Prevent adding new members to project membership within this group**.
 1. Select **Save changes**.
 
 All users who previously had permissions can no longer add members to a group.
@@ -470,29 +466,24 @@ users cannot perform Git operations through SSH, or access projects in the UI.
 For more information, [see this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/271673).
 
 To ensure only people from your organization can access particular
-resources, you can restrict access to groups and their
-underlying subgroups, projects, issues, and so on, by IP address. This can help ensure that
-particular content doesn't leave the premises, while not blocking off access to
-the entire instance. IP access restrictions can only be configured at the group level.
+resources, you can restrict access to groups by IP address. This setting applies to all subgroups,
+projects, issues, and so on. 
 
-Add one or more allowed IP subnets using CIDR notation to the group settings and anyone
-coming from a different IP address won't be able to access the restricted
-content.
+IP access restrictions can be configured at the group level only.
 
-Restriction currently applies to:
+This restriction applies to:
 
-- UI.
-- [From GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/-/issues/12874), API access.
-- [From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/32113), Git actions via SSH.
+- The GitLab UI.
+- [In GitLab 12.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/12874), the API.
+- [In GitLab 12.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/32113), Git actions via SSH.
 
-To avoid accidental lock-out, admins and group owners are able to access
-the group regardless of the IP restriction.
+Administrators and group owners are able to access the group regardless of the IP restriction.
 
 To restrict group access by IP address:
 
 1. Go to the group’s **Settings > General** page.
 1. Expand the **Permissions, LFS, 2FA** section.
-1. In the **Allow access to the following IP addresses** field, enter IP address ranges.
+1. In the **Allow access to the following IP addresses** field, enter IP address ranges in CIDR notation.
 1. Select **Save changes**.
 
 ![Domain restriction by IP address](img/restrict-by-ip.gif)
@@ -540,20 +531,20 @@ You can configure this feature for both subgroups and immediate parent groups. A
 in a subgroup has access to the templates for that subgroup, as well as
 any immediate parent groups.
 
-To enable group file templates:
-
-1. Go to the group settings page.
-1. Expand the **Templates** section.
-1. Choose a project to act as the template repository.
-1. Select **Save group**.
-
 To learn how to create templates for issues and merge requests, see
 [Description templates](../project/description_templates.md).
 
-### Group-level project templates **(PREMIUM)**
-
 Define project templates at a group level by setting a group as the template source.
-[Learn more about group-level project templates](custom_project_templates.md).
+[Learn more about group-level project templates](custom_project_templates.md). **(PREMIUM)**
+
+### Enable group file template **(PREMIUM)**
+
+To enable group file templates:
+
+1. Go to the group's **Settings > General** page.
+1. Expand the **Templates** section.
+1. Choose a project to act as the template repository.
+1. Select **Save changes**.
 
 ## Disable email notifications
 
@@ -616,7 +607,8 @@ Optionally, on [Premium](https://about.gitlab.com/pricing/) or higher tiers,
 you can prevent the projects in a group from being forked outside of the current top-level group.
 
 Previously this setting was available only for groups enforcing group managed account. This setting will be
-removed from SAML setting page and migrated to group setting, but in the interim period of changes both of those settings will be taken into consideration, if even one is set to `true` then it will be assumed group does not allow forking projects outside.
+removed from SAML setting page and migrated to group settings. In the interim period, both of these settings are taken into consideration.
+If even one is set to `true` then it will be assumed the group does not allow forking projects outside.
 
 To enable prevent project forking:
 
@@ -647,8 +639,7 @@ The group's new subgroups have push rules set for them based on either:
 ## Related topics
 
 - [Maximum artifacts size](../admin_area/settings/continuous_integration.md#maximum-artifacts-size). **(FREE SELF)**
-- [Repositories analytics](repositories_analytics/index.md): View overall activity of all projects with code coverage.
-  [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/263478) in GitLab 13.6. **(PREMIUM)**
+- [Repositories analytics](repositories_analytics/index.md): View overall activity of all projects with code coverage. **(PREMIUM)**
 - [Contribution analytics](contribution_analytics/index.md): View the contributions (pushes, merge requests,
   and issues) of group members. **(PREMIUM)**
 - [Issue analytics](issues_analytics/index.md): View a bar chart of your group's number of issues per month. **(PREMIUM)**
diff --git a/spec/support/shared_examples/models/slack_mattermost_notifications_shared_examples.rb b/spec/support/shared_examples/models/slack_mattermost_notifications_shared_examples.rb
index ddf68a798fb..71a76121d38 100644
--- a/spec/support/shared_examples/models/slack_mattermost_notifications_shared_examples.rb
+++ b/spec/support/shared_examples/models/slack_mattermost_notifications_shared_examples.rb
@@ -79,6 +79,18 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
 
     subject(:execute_service) { chat_service.execute(data) }
 
+    shared_examples 'calls the service API with the event message' do |event_message|
+      specify do
+        expect_next_instance_of(Slack::Messenger) do |messenger|
+          expect(messenger).to receive(:ping).with(event_message, anything).and_call_original
+        end
+
+        execute_service
+
+        expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
+      end
+    end
+
     context 'with username for slack configured' do
       let(:chat_service_params) { { username: 'slack_username' } }
 
@@ -92,11 +104,7 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
     context 'push events' do
       let(:data) { Gitlab::DataBuilder::Push.build_sample(project, user) }
 
-      it "calls #{service_name} API for push events" do
-        execute_service
-
-        expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
-      end
+      it_behaves_like 'calls the service API with the event message', /pushed to branch/
 
       context 'with event channel' do
         let(:chat_service_params) { { push_channel: 'random' } }
@@ -109,15 +117,20 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
       end
     end
 
+    context 'tag_push events' do
+      let(:oldrev) { Gitlab::Git::BLANK_SHA }
+      let(:newrev) { '8a2a6eb295bb170b34c24c76c49ed0e9b2eaf34b' } # gitlab-test: git rev-parse refs/tags/v1.1.0
+      let(:ref) { 'refs/tags/v1.1.0' }
+      let(:data) { Git::TagHooksService.new(project, user, change: { oldrev: oldrev, newrev: newrev, ref: ref }).send(:push_data) }
+
+      it_behaves_like 'calls the service API with the event message', /pushed new tag/
+    end
+
     context 'issue events' do
       let_it_be(:issue) { create(:issue) }
       let(:data) { issue.to_hook_data(user) }
 
-      it "calls #{service_name} API for issue events" do
-        execute_service
-
-        expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
-      end
+      it_behaves_like 'calls the service API with the event message', /Issue (.*?) opened by/
 
       context 'whith event channel' do
         let(:chat_service_params) { { issue_channel: 'random' } }
@@ -156,11 +169,7 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
       let_it_be(:merge_request) { create(:merge_request) }
       let(:data) { merge_request.to_hook_data(user) }
 
-      it "calls #{service_name} API for merge requests events" do
-        execute_service
-
-        expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
-      end
+      it_behaves_like 'calls the service API with the event message', /opened merge request/
 
       context 'with event channel' do
         let(:chat_service_params) { { merge_request_channel: 'random' } }
@@ -177,11 +186,7 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
       let_it_be(:wiki_page) { create(:wiki_page, wiki: project.wiki, message: 'user created page: Awesome wiki_page') }
       let(:data) { Gitlab::DataBuilder::WikiPage.build(wiki_page, user, 'create') }
 
-      it "calls #{service_name} API for wiki page events" do
-        execute_service
-
-        expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
-      end
+      it_behaves_like 'calls the service API with the event message', / created (.*?)wikis\/(.*?)|wiki page> in/
 
       context 'with event channel' do
         let(:chat_service_params) { { wiki_page_channel: 'random' } }
@@ -198,22 +203,14 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
       let_it_be(:deployment) { create(:deployment) }
       let(:data) { Gitlab::DataBuilder::Deployment.build(deployment) }
 
-      it "calls #{service_name} API for deployment events" do
-        execute_service
-
-        expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
-      end
+      it_behaves_like 'calls the service API with the event message', /Deploy to (.*?) created/
     end
 
     context 'note event' do
       let_it_be(:issue_note) { create(:note_on_issue, project: project, note: "issue note") }
       let(:data) { Gitlab::DataBuilder::Note.build(issue_note, user) }
 
-      it "calls #{service_name} API for note events" do
-        execute_service
-
-        expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
-      end
+      it_behaves_like 'calls the service API with the event message', /commented on issue/
 
       context 'with event channel' do
         let(:chat_service_params) { { note_channel: 'random' } }