Printers, external directories, database links, credentials, scheduled jobs and email configuration. EVERY ITEM ON THAT LIST HAS SENT A TEST EMAIL TO A REAL CUSTOMER SOMEWHERE.
A clone copies the database faithfully, and the database is full of pointers to the outside world. The clone utility reconfigures the system's identity; it has no idea what those pointers mean.
EMAIL IS THE ONE THAT REACHES A CUSTOMER AND IT IS THE FIRST THING TO DISABLE. A clone with working mail configuration will send — statements, invoices, notifications, approval requests — to the real addresses in the copied data. Somebody runs a test batch on a training system and a thousand customers receive an invoice, and there is no recall.
DATABASE LINKS POINT AT REAL SYSTEMS AND ARE THE QUIETEST HAZARD. A link that resolved to a production database still resolves to it from the clone. So a test on the clone reads from — and can WRITE to — production, which is Lesson 10's second failure and can corrupt the system the clone was supposed to protect.
PRINTERS PRINT. A clone with production printer definitions sends output to real devices in real offices, where somebody picks it up and acts on it.
EXTERNAL DIRECTORIES ARE SHARED WITH PARTNERS AND ARE WRITTEN TO. An interface that drops a file for a bank drops it from the clone too — and a test payment file that reached a real destination is not a training incident.
SCHEDULED JOBS RUN ON THE CLONE, ON THE SAME SCHEDULE, DOING EVERYTHING ABOVE. That is the multiplier: the other five hazards do not need anybody to log in.
AND CREDENTIALS ARE COPIED TOO, WHICH IS THE ONE PEOPLE FORGET IS A HAZARD AT ALL. Every password, key and connection detail production held is now on a system with relaxed access — the confidentiality version of the same problem.