What CDCR is NOT: the boundaries

Outcome

By the end of this lesson, you will be able to list the four things CDCR explicitly does NOT try to do and explain why those boundaries matter.

1. Concept

An idea this broad tends to grow. “Continuous Detect, Continuous Remediation” sounds like it might mean “automate everything”, and it does not.

Four boundaries mark out what CDCR is deliberately not trying to do. Knowing them is what lets you describe it to a sceptical audience without being caught out.

Boundary 1: CDCR is NOT autopilot for everything

The temptation: since one click can delete an orphaned disk, surely one click can fix everything.

Why this is wrong: L3’s layers exist for a reason. Some actions are cheap and undoable, such as terminating an idle machine after taking a copy of its disk. Some can be undone but will interrupt people, such as resizing a production load balancer. Some cannot be undone at all: database changes, anything holding state, anything near customer data.

The defaults are cautious because the two kinds of mistake are not the same size. Getting a saving wrong costs you $300 you did not save. Getting a database change wrong costs six figures of downtime and a good deal of trust.

The accurate version: the system can act, and a person decides when. Nothing runs until somebody clicks Remediate, a fix started by a non-admin waits for an admin, riskier fixes need a typed confirmation, and advisory findings have no Remediate button: a person fixes them by following the How to Fix steps.

Boundary 2: CDCR is NOT a way to bypass change management

The temptation: since CDCR closes the loop in minutes instead of weeks, surely it removes the need for change management.

Why this is wrong: change management exists for reasons that have nothing to do with how fast FinOps moves. It produces the audit trail compliance asks for. It keeps other teams informed, so nobody has to say “I had no idea that was happening while support was on fire”. It holds the instructions for undoing things, and it decides who gets woken up when something goes badly. CDCR replaces none of that; it plugs into it.

Where a company already runs change management well:

• The admins who approve fixes are the people your change process already names
• Audit logs feed the compliance evidence trail
• Notifications go to the same channels as other operational changes
• The Operate cadence (see M0.2 L4) includes a change-window awareness

The accurate version: CDCR makes change management faster where cost is concerned, it does not remove it. A fix started by a non-admin waits for an admin, so your change process can sit on that approval step. Changes made by hand from the How to Fix steps go through the usual route.

Boundary 3: CDCR is NOT a substitute for cost ownership

The temptation: the FinOps practice can outsource cost ownership to CDCR. The system finds and fixes problems. Teams don’t have to think about cost.

Why this is wrong: the third FinOps principle, everyone takes ownership for their own usage, falls apart if teams stop paying attention on the grounds that a tool has it covered. That is worse than having no tool, because the waste then piles up in exactly the places the tool cannot reach: how the system was designed in the first place, which is lever 4 from M0.2 L3.

CDCR covers levers 1 and 2, removing waste and resizing what is too big. It cannot touch lever 4. The decisions that move cost the most, where a workload runs, how it is built, whether you build it or buy it, stay with the engineers who own it.

The accurate version: CDCR keeps the day-to-day floor clean. The ceiling is set by design decisions, and those stay with engineering. A healthy organisation has both: the loop running underneath, and teams making the design calls that set what the estate costs at all.

Boundary 4: CDCR is NOT a single-vendor lock

The temptation: since CDCR works well as an integrated suite, the customer should consolidate every cost surface to one vendor.

Why this is wrong: the FinOps Foundation’s framework covers 22 capabilities across four domains, which is more ground than any one vendor genuinely covers. ZopNight works on automating usage optimisation, on splitting cost across teams, and on making infrastructure cost visible. Several neighbouring jobs belong elsewhere: managing commitments (commitment automation services such as ProsperOps or Spot Eco, both now Flexera companies), tracking what you spend on software subscriptions (platforms with broad SaaS integrations, such as Vantage), and reporting cost per unit for things outside infrastructure, which usually means your own reporting tools.

A mature practice normally runs two or three tools, each doing a different job. CDCR is one strong piece of that, not the whole of it.

The accurate version: CDCR is one solid tool among several. This University teaches the framework so you can assemble the right set for your own situation, rather than defaulting to putting everything with one vendor.

The five things CDCR IS, restated

To balance the four “is nots,” here are the five “is” claims:

1. CDCR is a way of working, the loop, not a product
2. CDCR is measured on how long a fix takes, hours instead of weeks for one-click fixes
3. CDCR is cautious by design, with layered permissions, conservative defaults, and no fix that stops, deletes or resizes a database
4. CDCR is yours to control, since no fix runs until a person clicks Remediate
5. CDCR holds up in a security review, because it reads by default and every change it makes is recorded

Why the boundaries matter for the conversation

When somebody takes this to a leadership meeting, the boundaries are what keep the conversation honest.

• Promise too much (“we will automate all of FinOps”) and the first exception costs you your credibility
• Promise too little (“it is another dashboard”) and you have described the thing it is not
• Skip the boundaries (“we do not need change management any more”) and you will fall out with another team inside a month

What works is being precise about scope. CDCR closes the gap between finding and fixing for a defined set of actions, with a safety design that has been through security review. Everything outside that set follows the normal process.

2. Demo

A real internal conversation pattern, condensed:

SPONSOR: "CDCR can automate everything in our FinOps practice, right?"

FINOPS:  "Many fixes run end to end once somebody clicks Remediate:
         deleting orphan storage, resizing an oversized server."

SPONSOR: "What about the rest?"

FINOPS:  "A fix started by a non-admin waits for an admin. Risky fixes
         need a typed confirmation. Resizing a database has no Remediate
         button: we follow the How to Fix steps ourselves.
         Architectural decisions stay with engineering."

SPONSOR: "So we still need a FinOps team?"

FINOPS:  "Yes. A smaller one, spending its time on the judgement calls and the
         design work instead of clearing tickets. Each person gets further."

SPONSOR: "And we can disable change management?"

FINOPS:  "No. CDCR integrates with change management on the approval step and
         provides better audit trails than today. The change process doesn't go
         away. It gets faster on the cost surface."

SPONSOR: "OK: let me re-pitch this to the exec team correctly."

The conversation lands when the boundaries are explicit. Without them, the executive pitch oversells, the Security team pushes back, and the rollout stalls.

3. Hands-on (5 min)

Draft your own one-page CDCR scope statement:

WHAT CDCR DOES IN THIS ORGANIZATION:
  - __________________________________________
  - __________________________________________
  - __________________________________________

WHAT CDCR DOES NOT DO IN THIS ORGANIZATION:
  - __________________________________________
  - __________________________________________
  - __________________________________________

WHO OWNS WHAT CDCR DOES NOT DO:
  - Architectural cost decisions:  ____________
  - Database optimization:          ____________
  - Cost forecasting:               ____________
  - Commitment design:              ____________
  - Cross-team cost arbitration:   ____________

WHAT TRIGGERS A REVIEW OF THESE BOUNDARIES:
  - __________________________________________

Hand this document to leadership before the CDCR pitch. It prevents the “expected everything, got something specific” reaction.

4. Knowledge check

Q1

A leadership member says: “Now that we have CDCR, we can disband the FinOps team.” Most accurate response:

A. Yes, since the tool handles all of that for you
B. No: CDCR handles operational findings (levers 1 and 2)
C. Yes, except for finance
D. Yes, after one year

Q2

A team expects a one-click fix for every rule, including idle databases. The database recommendations have no Remediate button. The team escalates: “ZopNight is broken.” Most accurate response:

A. Escalate to support
B. Ask support to switch on database fixes for the org
C. Intentional: fixes never stop, delete or resize databases
D. Switch over to a different tool entirely instead

Q3

The four boundaries of CDCR are:

A. Not autopilot for everything · Not bypass for change management · Not a substitute for cost ownership · Not a single-vendor lock
B. Cost, performance, reliability, security
C. AWS, GCP, Azure, other
D. Discovery, then recommendation, then remediation, and finally the audit trail that records all of it afterwards too

5. Apply

The boundaries are reflected in ZopNight’s product:

• A Remediate button on each fixable recommendation: a person decides when to act
• No fix stops, deletes or resizes a database: enforced in code, not in a setting, so it cannot be turned off
• Admin approval for fixes started by non-admins fits into change management
• Advice-only recommendations for anything the system should not do itself: ownership stays with the team
• MCP write access off by default: an agent reads the estate and changes nothing until an admin raises the write tier

The boundaries are also reflected in ZopNight’s positioning: it does not claim to be a single-vendor solution; it claims to be a strong execution layer that integrates with broader FinOps practice.

Module quiz

You have now completed all four lessons of M0.6 and all 28 lessons of Track 0. Take the module quiz: 10 questions, 80% to pass.

Track complete: what’s next

You have completed Track 0: Cloud Cost Foundations.

Associate certification. Take the Associate certification exam (free, 22 questions, 70 min, open-book). Pass to earn the ZopDev Operator digital badge, shareable to LinkedIn.

Or go deeper. Continue to Track 1: Operator to learn the product, or use the path picker to find the sequence for your role.

Related lessons

• L1: What CDCR means
• L2: The cost of detect-only
• L3: Read-only safety
• T6.M6.5: What’s NOT writable via MCP

Glossary terms touched

CDCR