Currently, when you use OPS Manager to shard a collection, it automatically creates a foreground index that exactly matches the sharding key, when such index doesn't exist. When the sharding key column(s) is(are)already prefixing an existing index, it's not sufficent. This is dangerous in Live environments because the whole database is blocked for a long time (sharded collections are usually big collections). So, several features could exist : - before continuing with sharding, OPS Manager warns that it needs to create this foreground index first. You can stop if you don't agree (and create this index by yourself first). - OPS Manager creates instead a background index or creates this index with the rolling manner. - OPS Manager is able to use one exiting indexes that contains the sharding key as a prefix of this index, no need to create a new one.