Resource Policy Drift Monitoring (nonCompliantResources)
Parent: Atlas Cost Commitments, Cross-Org Billing and FinOps Tooling · Published reference · snapshot 2026-10-19 · skill mongodb-operations-expert/references/atlas-cost-commitments-cross-org-billing-and-finops-tooling.md · viability 3.25 / 5 (research)
↓ Facts as markdownall context files
Atlas Resource Policies block new non-conforming changes but do not fix or block resources that already exist; the Admin API endpoint GET /api/atlas/v2/orgs/{orgId}/nonCompliantResources (also atlas api resourcePolicies getNonCompliantResources, API version 2024-08-05) lists the projects, clusters or networks that violate current policies, and MongoDB docs strongly recommend polling it. The pack draws on 4 source URLs (Atlas resource policies docs, the Atlas CLI reference, a foojay tutorial and the Atlas blog) and covers definitions, monitoring guidance, autoscaling and shard-count false-positive pitfalls, policy rules and Terraform management.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- The endpoint is GET /api/atlas/v2/orgs/{orgId}/nonCompliantResources with Accept header application/vnd.atlas.2024-08-05+json. It returns the projects, clusters or networks in an organization that violate current resource policies. The Atlas CLI exposes it 1:1 as `atlas api resourcePolicies getNonCompliantResources --orgId <id> --version 2024-08-05`. [source]
- Return all non-compliant resources for an organization. [source] — CLI description
- This endpoint returns a list of projects, clusters, or networks that violate current policies. [source]
How it works
- A new policy applies to new clusters immediately. A non-compliant existing cluster can only be changed in ways that bring it into compliance (for example, if AWS is blocked, an AWS cluster can only move to Azure or Google Cloud). [source]
- This Atlas Resource Policy applies to all new clusters. For existing clusters that do not comply with the Atlas Resource Policy, Atlas only allows users to make changes to the cluster which brings the cluster into compliance. For example, if cluster0 runs on AWS and you apply an Atlas Resource Policy that blocks clusters on AWS, the only change users could make to cluster0 while it is non-compliant is switching the cloud provider to Azure or Google Cloud. [source]
Parameters and configuration
- Policies are allow-by-default and organization-wide, with per-project exclusions possible. Each policy needs a unique name (duplicate returns 400). Create, update and delete generate activity-feed events. Docs recommend several small policies over one large one, which keeps non-compliance reports attributable to a specific policy. [source]
- By default, Atlas Resource Policies are organization-wide. These policies automatically enforce standards across all projects and clusters within the organization. [source]
- However, Atlas provides flexibility. You can exclude specific projects from an Atlas Resource Policy. This functionality allows most projects to inherit consistent organization-wide standards while enabling exceptions for cases with unique requirements. [source]
- Atlas Resource Policies are allow-by-default. If no Atlas Resource Policies exist, users can perform all actions on Atlas clusters that their Atlas user role allows. [source]
- API version to use when calling the Atlas API endpoints [options: "2024-08-05"]. If not set by the user, defaults to the latest version or the profile's api_version config value if set. This value defaults to "2024-08-05". [source] — Atlas CLI
How-to and procedures
- MongoDB docs strongly recommend proactively monitoring the list of non-compliant resources via the nonCompliantResources endpoint. Policies enforce end-state goals, not intermediate states, so a failing downstream component can temporarily leave a policy non-compliant. [source]
- We strongly recommend that you proactively monitor your list of non-compliant resources using the /orgs/{ORG-ID}/nonCompliantResources endpoint. Atlas Resource Policies ensure compliance with defined goals but do not enforce intermediate or transitional states. For example, if a downstream component fails, the policy may temporarily enter a non-compliant intermediate state. [source]
- To return a list of existing clusters that do not conform to your Atlas Resource Policy, use the GET /orgs/{ORG-ID}/nonCompliantResources resource. [source]
- MongoDB Atlas treats replica sets as having a shard count of one internally. The policy above avoids marking replica sets as noncompliant by only evaluating when isConvertingToSharded is specified. [source] — Atlas blog
- If you enforce a minimum shard count greater than one, you must explicitly allow the transition state for cluster conversions in your policy (for example, && !context.cluster.isConvertingToSharded). Without this exception, Atlas blocks users from converting a replica set to a sharded cluster because the conversion process requires an intermediate state where the cluster has only one shard. [source]
- Only use minShardCount to enforce minimums and maxShardCount to enforce maximums. Doing otherwise can cause policy evaluation errors. [source]
Examples and snippets
- In the example below, a public IP was already configured in the project. After applying the policy that blocks 0.0.0.0/0, the resource was not removed, but it was flagged as non-compliant: [source] — foojay tutorial
- atlas api resourcePolicies getNonCompliantResources --version 2024-08-05 --orgId <object-id> [source] — Atlas CLI
- curl --request GET \ --user "<PUBLIC-KEY>:<PRIVATE-KEY>" \ --digest \ --header "Accept: application/vnd.atlas.2024-08-05+json" \ "https://cloud.mongodb.com/api/atlas/v2/orgs/<ORG_ID>/nonCompliantResources?pretty=true" [source] — foojay tutorial
Problems, failure modes and limitations
- Atlas does not auto-remediate or block existing out-of-compliance resources. A resource that predates a policy stays unchanged and is only reported. Example: a pre-existing 0.0.0.0/0 access-list entry was not removed after a blocking policy was applied, but appeared as non-compliant. [source]
- Shard-count false positives: Atlas treats a replica set as having one shard. A minShardCount policy above 1 without a cluster-type check flags every replica set in scope as non-compliant, flooding the endpoint. Use minShardCount only for minimums and maxShardCount only for maximums, and add the !context.cluster.isConvertingToSharded exception for replica-set-to-sharded conversions. [source]
- If the auto-scaling limits on your existing cluster don't match the new Atlas Resource Policy, the cluster might exceed the policy's defined boundaries. To address this issue, use the /orgs/{ORG-ID}/nonCompliantResources endpoint to identify and monitor non-compliant resources so you can update them to meet policy requirements. [source]
- If existing auto-scaling limits exceed a new Atlas Resource Policy, the cluster can continue to scale automatically beyond policy boundaries. However, you cannot manually scale the cluster beyond the policy limits. Use the /orgs/{ORG-ID}/nonCompliantResources endpoint to identify and monitor non-compliant resources. [source]
- Autoscaling drift: if a cluster's existing autoscaling limits exceed a new policy's bounds, the cluster keeps scaling automatically beyond them, but manual scaling past the policy limits is refused. Docs say to use nonCompliantResources to find and fix such clusters, which matters for cost because compute autoscaling ceilings can stay above the cap. [source]
- Atlas treats a replica set as having a shard count of one. If you enforce a minimum shard count greater than one without checking whether clusters are sharded clusters, all replica sets in the project are marked as non-compliant. [source]
- ⚠️ Important: MongoDB Atlas does not automatically fix or block existing resources. If a resource is out of compliance, it will remain unchanged — the system only reports the violation, enabling visibility without disruption. [source] — foojay tutorial
- These scenarios aren’t isolated incidents. Without enforceable standards, MongoDB Atlas cluster configurations can drift away from architectural best practices and organizational policies. MongoDB Atlas Resource Policies solve this by making architectural standards technically enforceable, preventing configuration mistakes before clusters are deployed. [source] — Atlas blog
Facts and statements
- Policies can be managed with the Atlas Terraform provider (resource mongodbatlas_resource_policy; provider 1.33.0 or later needed for minimum-TLS and cipher-suite rules). The MongoDB docs describe no Terraform data source for nonCompliantResources, so drift monitoring is done by polling the API or CLI, for example from a scheduled job. [source] — no Terraform data source documented
- These policies create multiple independent barriers to configuration problems. The disk size limit controls storage costs. The sharded cluster requirement ensures production deployments can scale horizontally. The minimum shard count prevents under-sharded deployments. The cluster tier restriction ensures production clusters use appropriately sized instances: not too small (below M30) to handle production workloads, and not unnecessarily large (above M60) without architectural review. The region restrictions meet data residency requirements. The wildcard blocking prevents network security viol [source] — cost relevance: disk size limit
- Support for Resource Policies is available in the MongoDB Atlas Terraform Provider. This allows teams to declare policies as code, apply them through CI/CD pipelines, and enforce configuration compliance continuously and audibly. [source] — foojay tutorial
Related concepts
- Atlas Resource Policies — is a whole of Resource Policy Drift Monitoring (nonCompliantResources)
- non-compliant — is a synonym of Resource Policy Drift Monitoring (nonCompliantResources)
- resource policy drift — is a synonym of Resource Policy Drift Monitoring (nonCompliantResources)
- nonCompliantResources API — is a instance of Resource Policy Drift Monitoring (nonCompliantResources)
- monitor non-compliant resources — is a dependent of Resource Policy Drift Monitoring (nonCompliantResources)
- shard-count false positives — is a problem of Resource Policy Drift Monitoring (nonCompliantResources)
- no auto-remediation — is a problem of Resource Policy Drift Monitoring (nonCompliantResources)
- policy management rules — is a part of Resource Policy Drift Monitoring (nonCompliantResources)
- autoscaling drift — is a problem of Resource Policy Drift Monitoring (nonCompliantResources)
- existing clusters changes bring compliance — is a part of Resource Policy Drift Monitoring (nonCompliantResources)
- public access example — is a instance of Resource Policy Drift Monitoring (nonCompliantResources)
- mongodbatlas_resource_policy — is a instance of Resource Policy Drift Monitoring (nonCompliantResources)
- cost governance — is a related of Resource Policy Drift Monitoring (nonCompliantResources)
- Cedar — is a prerequisite of Resource Policy Drift Monitoring (nonCompliantResources)
Children
- Cedar policy authoring for cluster size and autoscaling caps (frontier, viability 3.05 / 5, below research gate)
- Scheduled compliance polling and alerting (frontier, viability 2.45 / 5, below research gate)
Frontier under this node: Cedar policy authoring for cluster size and autoscaling caps (3.05), Scheduled compliance polling and alerting (2.45)