Clarified inheritance of runner permissions

Added missing word

Apply suggestion to doc/user/group/subgroups/index.md

Clarified subgroup project import behavior

Apply suggestion to doc/user/group/subgroups/index.md

doc/user/group/subgroups/index.md

@@ -4,8 +4,7 @@ type: reference, howto, concepts
 
 # Subgroups
 
-NOTE: **Note:**
-[Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/2772) in GitLab 9.0.
+>[Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/2772) in GitLab 9.0.
 
 Subgroups, also known as nested groups or hierarchical groups, allow you to have up to 20
 levels of groups.
@@ -68,9 +67,9 @@ Another example of GitLab as a company would be the following:
 The maximum subgroups a group can have, including the first one in the
 hierarchy, is 21.
 
-Actions such as transferring or importing a project inside subgroups, work like
-when performing these actions the traditional way with the `group/project`
-structure.
+When performing actions such as transferring or importing a project between
+subgroups, the behavior is the same as when performing these actions at the
+`group/project` level.
 
 ## Creating a subgroup
 
@@ -117,6 +116,10 @@ When you add a member to a subgroup, they inherit the membership and permission
 level from the parent group. This model allows access to nested groups if you
 have membership in one of its parents.
 
+Jobs for pipelines in subgroups can use [Runners](../../../ci/runners/README.md) registered to the parent group. This means secrets configured for the parent group are available to subgroup jobs.
+
+In addition, maintainers of projects that belong to subgroups can see the details of Runners registered to parent groups.
+
 The group permissions for a member can be changed only by Owners, and only on
 the **Members** page of the group the member was added.