diff --git a/source/administration/operational-segregation.txt b/source/administration/operational-segregation.txt
index a565d25f290..a086cfd586b 100644
--- a/source/administration/operational-segregation.txt
+++ b/source/administration/operational-segregation.txt
@@ -45,9 +45,9 @@ Specifically, with MongoDB, you can:
 
 - combine the above features in a single distributed deployment, on a
   per-operation (for read and write operations) and collection (for
-  chunk distribution in sharded clusters distribution.) basis.
+  chunk distribution in sharded clusters distribution) basis.
 
-For full documentation of these features see the following
+For full documentation of these features, see the following
 documentation in the MongoDB Manual:
 
 - :ref:`Read Preferences <read-preference>`, which controls how drivers
@@ -59,11 +59,11 @@ documentation in the MongoDB Manual:
 
 - :ref:`Replica Set Tags <replica-set-configuration-tag-sets>`, which
   control how applications create and interact with custom groupings
-  of replica set members to create custom application specific read
+  of replica set members to create custom application-specific read
   preferences and write concerns.
 
 - :ref:`Tag Aware Sharding <tag-aware-sharding>`, which allows MongoDB
-  administrators to define an application specific balancing policy,
+  administrators to define an application-specific balancing policy,
   to control how documents belonging to specific ranges of a shard key
   distribute to shards in the :term:`sharded cluster`.
 
diff --git a/source/administration/tag-aware-sharding.txt b/source/administration/tag-aware-sharding.txt
index c8269a9ef8f..12a44cc7eb3 100644
--- a/source/administration/tag-aware-sharding.txt
+++ b/source/administration/tag-aware-sharding.txt
@@ -24,14 +24,14 @@ sharding in MongoDB deployments.
 
 .. note::
 
-   Shard key rage tags are entirely distinct from :ref:`replica set member
+   Shard key range tags are entirely distinct from :ref:`replica set member
    tags <replica-set-read-preference-tag-sets>`.
 
 Behavior and Operations
 -----------------------
 
 Tags in a sharded cluster are pieces of metadata that dictate the
-policy and behavior of the cluster balancer :term:`balancer`. Using
+policy and behavior of the cluster :term:`balancer`. Using
 tags, you may associate individual shards in a cluster with one or
 more tags. Then, you can assign this tag string to a range
 of :term:`shard key` values for a sharded collection. When migrating a
@@ -53,10 +53,10 @@ tags, if tagged shards are not balanced. [#specific-tagged-migrations]_
    that:
 
    - :term:`Shard key` values between ``100`` and ``200`` have tags to
-     direct corresponding chunks on shards tagged ``NYC``.
+     direct corresponding chunks to shards tagged ``NYC``.
 
    - Shard Key values between ``200`` and ``300`` have tags to direct
-     corresponding chunks on shards tagged ``SFO``.
+     corresponding chunks to shards tagged ``SFO``.
 
    In this cluster, the balancer will migrate a chunk with shard key
    values ranging between ``150`` and ``220`` to a shard tagged
@@ -162,7 +162,7 @@ View Existing Shard Tags
 The output from :method:`sh.status()` lists tags associated with a
 shard, if any, for each shard. A shard's tags exist in the shard's
 document in the :data:`~config.shards` collection of the ``config``
-database. To return all shards with a specific tag use a sequence of
+database. To return all shards with a specific tag, use a sequence of
 operations that resemble the following, which will return only those
 shards tagged with ``NYC``:
 
@@ -174,10 +174,10 @@ shards tagged with ``NYC``:
 You can find tag ranges for all :term:`namespaces <namespace>` in the
 :data:`~config.tags` collection of the ``config`` database. The output
 of :method:`sh.status()` displays all tag ranges. To return all shard
-key ranges tagged with ``NYC`` issue the following sequence of
+key ranges tagged with ``NYC``, issue the following sequence of
 commands:
 
 .. code-block:: javascript
 
    use config
-   db.shards.find({ tags: "NYC" })
+   db.tags.find({ tags: "NYC" })
diff --git a/source/data-center-awareness.txt b/source/data-center-awareness.txt
index 73702a1720d..0c2532c10d1 100644
--- a/source/data-center-awareness.txt
+++ b/source/data-center-awareness.txt
@@ -10,7 +10,7 @@ MongoDB provides a number of features that allow application
 developers and database administrators to customize the behavior of a
 :term:`sharded cluster` or :term:`replica set` deployment so that
 MongoDB may be *more* "data center aware," or allow operational
-separation and segregation based on location.
+separation and location-based separation.
 
 MongoDB also supports segregation based
 on functional parameters, to ensure that certain :program:`mongod`