Outcome
By the end of this lesson, you will be able to defend the database denylist to security audiences, explain the risk-reward math behind it, and distinguish what IS allowed (start/stop) from what isn’t (modify/delete).
| Prerequisites | M2.3.L1 - L4 |
| Time | 9 minutes |
1. Concept
Databases are protected twice over, in two separate places in the code.
The first is the allowlist from L2. Every idle-database rule (RDS, Aurora, Neptune, DocumentDB, Cloud SQL, Azure MySQL and PostgreSQL Flexible) has been taken off it, so those recommendations are advisory. The stop template does list these resource types as ones it could stop, but every entry is marked advisory-only and no allowlisted rule routes to them. Azure SQL Database is left out of that list entirely.
The second is a central safety check that sits in front of everything. It holds a fixed list of stateful resource types. When a recommendation would delete one of them, or resize it in a way that needs a stop, the check drops it to advisory. It fails closed: a rule has to pass it on every resource, so a new rule nobody thought about is blocked rather than allowed.
The result is that with automatic fixing fully switched on, ZopNight still never changes a customer database in one click. Anything touching a database is advisory, or at the very most guided, where a person types a confirmation first. A fix never stops, deletes or resizes a database. Schedules can start and stop them.
THE GUARANTEE: ZopNight will NEVER auto-mutate your customer database Hardcoded; not configurable; not bypassable Applies to: data, schema, instance class, encryption settings, multi-AZ config, scaling decisions Does not apply to: scheduled start/stop (operational pause) Guided only (you type to confirm): RDS storage gp2 → gp3, RDS / Cloud SQL / Azure MySQL Flexible backup retentionThe denylist is the answer to most “is our database safe with ZopNight?” questions.
What’s on the denylist
LAYER 1: THE ALLOWLIST (stop template resource types) Listed as stoppable, but every entry is ADVISORY-ONLY: rds, rds-cluster (Aurora), neptune, documentdb-cluster (AWS) cloudsql (GCP) mysql-flexible, postgresql-flexible (Azure) redshift, sqlvm (schedule lever only) Their idle rules are off the allowlist, so no one-click Stop reaches them Deliberately NOT listed: Azure SQL Database, ElastiCache, Memorystore (no safe power-stop)
LAYER 2: THE SAFETY GATE (stateful resource types;auto delete or resize-with-stop demoted to advisory) rds, rds-cluster, aurora, aurora-mysql, aurora-postgresql, elasticache, redshift, documentdb, neptune, memorydb (AWS) cloudsql, alloydb, memorystore, bigtable, spanner (GCP) sqldatabase, azure-sql, sql-mi-db, mysql-flexible, postgresql-flexible, cosmosdb, redis (Azure) plus anything with an engine field or a data tier
WHAT NEVER AUTO-EXECUTES ON THE ABOVE: stop (layer 1: advisory only) delete, or a resize that needs a stop (layer 2: demoted to advisory)Both lists are hardcoded in the code. Not configurable. Not bypassable.
Why so conservative: the risk-reward math
SCENARIO: Recommendation suggests downsize RDS db.r5.4xlarge → r5.2xlargeProjected savings: $530/month
POSSIBLE OUTCOMES IF AUTO-EXECUTED: SUCCESS: Saved $530/month
FAILURE modes: Cloud-side resize causes 30-second connection drop Impact: revenue loss from SaaS outage during peak hours Cost: potentially $10K-$100K (customer impact)
Performance regression on smaller instance Impact: degraded customer experience for days/weeks Cost: customer churn, support tickets, eng time to investigate
Concurrent migration job hits the smaller instance class Impact: query failures, possible data inconsistency Cost: potentially catastrophic; data recovery effort Could be: $100K+ to remediate
EXPECTED COST CALCULATION: Even at 1% failure rate: Expected loss = 0.01 × $50K (avg cost of incident) = $500 Savings = $530 Net = barely positive; high variance
At 5% failure rate: Expected loss = $2,500 Net = NEGATIVE $1,970
At 10% failure rate: Expected loss = $5,000 Net = NEGATIVE $4,470
ZopNight chooses CATEGORICAL EXCLUSION Don't take the risk Manual DBA execution is the right surface Customer's DBA team has context + judgmentThe cost of a bad database write is asymmetric. The denylist averts the bad outcome categorically.
What the system does instead
For database optimization recommendations, the system:
1. Shows the recommendation card normally2. Surfaces the evidence (metrics, activity)3. Provides the remediation steps + console link4. HIDES the one-click Apply Remediate button (gp2 to gp3 and backup-retention fixes are guided: you type to confirm)5. Provides "Mark Resolved" so team can record manual execution
EXAMPLE: RDS Right-Sizing recommendation card [Apply Remediate is HIDDEN]
REMEDIATION (manual): 1. Review CloudWatch metrics for the instance 2. Plan a maintenance window 3. Modify instance class via AWS Console 4. Monitor application performance for 48 hours
[Mark Resolved] [Dismiss]
The team's DBA executes the change through normal channels.The team’s DBA has the context, the maintenance window, and the runbook.
What the denylist does NOT prevent
Things still allowed on database resources:
ALLOWED for databases: ✓ Discovery (every database inventoried, tagged, costed) ✓ Scheduling (start/stop schedules on databases: operational pause) ✓ Read-only metrics (Connections, CPU, IOPS, etc.) ✓ Showback / cost attribution ✓ Recommendations (display) ✓ Manual remediation marking ✓ Cost reports ✓ Audit logging
NOT ALLOWED for databases: ✗ Auto-execute modify/delete/scale via Apply Remediate ✗ One-click destructive actions ✗ Automated rightsizingThe denylist is specifically about auto-execution of mutating actions. The rest of the surface is intact.
Why hardcoded, not configurable
ALTERNATIVE: configurable denylist Some customer would set it permissively Incident would follow Trust would drop across customer base
ZOPNIGHT'S CHOICE: hardcoded Safety architecture identical across all customers Cannot be defeated by configuration mistakes Auditable: "Will ZopNight modify our DB in one click?" Answer always: no SOC 2 / ISO 27001 reviewers see structural safeguard
TRADE-OFF: Some flexibility for one-size-fits-all safety Worth it for the trust + audit benefitHardcoded = guarantee. Configurable = optimization. ZopNight chooses the guarantee.
Documented at the source
AUTO-REMEDIATION ELIGIBILITY IS AN ALLOWLIST, not a denylist: the auto-remediation allowlist in ZopNight's code (113 rules wired: 26 one-click auto + 87 guided type-to-confirm)
DATABASE PROTECTION IS TWO-LAYER: 1. Every idle managed-DB rule is off the allowlist, and the stop template marks each managed-DB type advisory-only. No one-click Stop reaches a database. 2. A central safety gate fail-closes: it demotes destructive ops on any stateful data resource to advisory.
EVERY RULE'S auto-eligibility: Not on the allowlist -> no one-click Apply (advisory only) On the allowlist as "guided" -> requires a human type-to-confirm DB-touching action -> advisory or guided, never silent auto-executeEligibility is in the code, not configuration. Auditable in the source.
A subtle point: DB scheduling
STOPPING a database via scheduling is NOT a mutating operationin the same sense as modify/delete/scale.
SCHEDULE-STOP: Pauses billing Restores state on next start Snapshots remain intact No schema or data changes Operationally analogous to stopping a VM
THE SYSTEM schedules databases off-hours when configured: Common pattern: stop non-prod databases overnight Saves significant cost Data preserved
DENYLIST'S "delete" AND "modify" actions: Don't include schedule-driven start/stop Start/stop is operational pause; not data mutationCustomers often want to schedule-stop databases for cost savings. This works.
Common security questions + answers
Q: "Will ZopNight auto-modify our customer database?"A: "No. Auto-remediation runs off an allowlist, and every idle managed-DB rule is off it, so no one-click Stop reaches a database. A central safety gate also fail-closes destructive ops on any stateful data resource. Any DB-touching recommendation is advisory or guided (a human types to confirm); nothing runs one-click. Your DBA executes real changes."
Q: "What about scheduling? Can it start/stop a database?"A: "Yes, start/stop is allowed. Schedule-driven start/stop pauses billing without mutating the data. Data, schema, configuration preserved across the cycle."
Q: "Can the customer force a one-click DB write?"A: "No. Idle-DB rules are off the allowlist and the safety gate fail-closes destructive ops on stateful data, regardless of settings."
Q: "What about DBs in a development account?"A: "Same protections apply. Account isn't the factor; resource type is. Even dev databases get the same treatment."
Q: "What if we need to bulk-modify many DBs?"A: "Use your normal DBA tools (Liquibase, Flyway, your custom scripts). ZopNight's role is detection + recommendation, not one-click execution against databases."
Q: "Is this documented for SOC 2 / ISO 27001?"A: "Yes. The allowlist and the fail-closed safety gate are in source; auditors can verify the idle-DB rules are off the allowlist. Clear evidence."The questions are predictable; the answers are consistent.
Comparison to other categories
CATEGORY AUTO-REM ELIGIBILITY─────────────────────────────────────────────────EC2 / VMs YES (allowlisted rules; reversible actions)Storage (EBS, S3) YES (delete on orphans; reversible recovery)Lambda / Functions GUIDED (unused function delete, type-to-confirm)Load Balancers YES (orphan deletes)Databases NO (idle-DB rules off the allowlist; advisory/guided only)Caches (ElastiCache) NO (excluded; data state)Data Warehouses NO (excluded; analytical workloads)Kubernetes GUIDED (single-replica bump 1 to 2)Networking CAUTIOUS (some yes, some no per rule)IAM NO (always manual)This database protection sits within a broader risk-based allowlist. Some categories are auto-remediation eligible; databases and other stateful data are excluded from the auto path.
2. Demo
A security review walked through:
SECURITY ENGINEER: "Can ZopNight modify our customer database?"
PLATFORM ENGINEER: "Not automatically. Auto-remediation runs off an allowlist, and every idle managed-DB rule is off it, so no one-click Stop reaches a database. The stop template marks every managed-DB type advisory-only. On top of that a central safety gate demotes any destructive op on a stateful data resource to advisory, fail-closed. So nothing one-click modifies or deletes your database. A database-touching recommendation is advisory, or at most guided (a human on your side types to confirm)."
SECURITY: "What about scheduling? Can it start/stop a database?"
PE: "Yes, start/stop is allowed because it pauses billing without mutating the data. Schedule-driven start/stop on RDS is common (saves cost on non-prod databases). The data, schema, and configuration are preserved across the schedule's cycle."
SECURITY: "What if our org wants to force a one-click DB write?"
PE: "There is no such path. Idle-DB rules are off the allowlist and the safety gate fail-closes destructive ops on stateful data, regardless of org settings. This is intentional safety architecture."
SECURITY: "Where can I verify in the code?"
PE: "The allowlist and the fail-closed safety gate are both in ZopNight's source. We can walk them in a code review."
SECURITY: "And for SOC 2 evidence?"
PE: "The architecture is documented. We can provide: 1. Source code citation 2. UI screenshot showing hidden Apply button on RDS recommendation 3. Architecture diagram explaining the denylist enforcement"
SECURITY: "Approved. This is exactly the kind of structural safeguard we like to see."The denylist is the answer to most database safety questions. Trust built through consistent, documented architecture.
3. Hands-on (5 min)
Verify the denylist in your environment:
□ STEP 1: Browse Recommendations Filter to database-type recommendations (RDS, Aurora, CloudSQL, ElastiCache, etc.)
□ STEP 2: Open one recommendation Verify: no one-click Apply Remediate button (at most a guided one you confirm by typing) Manual remediation steps shown Mark Resolved button available
□ STEP 3: For comparison Open a non-database recommendation (e.g., idle EC2) Apply Remediate button is VISIBLE (if the rule is allowlisted, enabled, and the per-recommendation safety gate agrees)
□ STEP 4: Document for security Take a screenshot of the database recommendation Note: no Apply button File for next security review
□ STEP 5: Plan databases-via-DBA workflow Who acts on database recommendations? (Your DBA team) Their tooling: __________ Maintenance window cadence: __________A 10-minute verification reassures security teams.
4. Knowledge check
Q1
Customer enables auto-remediation org-wide. The system attempts to modify an RDS instance based on a rightsizing recommendation. What happens:
A. Modification proceeds (org enabled it)
B. Blocked: RDS is on the database denylist
C. Approval requested
D. Modification proceeds with warning
Show answer
Correct: B. Auto-remediation toggle does not override the hardcoded denylist. Manual remediation path is the only option. The denylist is structural, not configurable.
Q2
A team schedule-stops their RDS at night. Is this a mutation?
A. No: schedule-driven start/stop pauses billing without modifying the database
B. Yes, since this is forbidden by the database denylist in every case
C. Only on weekdays
D. Only on prod
Show answer
Correct: A. Data, schema, configuration preserved. The denylist’s “modify/delete” actions don’t include operational start/stop. Common cost-saving pattern for non-prod databases.
Q3
The denylist exists because:
A. Cloud providers require it
B. The cost of a bad database write is asymmetric: even a small failure rate dwarfs the savings from any optimization
C. The database vendors require it as a condition of their own support contracts with their own customers
D. Bureaucracy
Show answer
Correct: B. Safety architecture chooses categorical exclusion over edge-case handling. Trust through structural guarantee. Risk-reward math drives the denylist.
5. Apply
The denylist is enforced in code. To audit: open any database-type recommendation card; confirm there is no one-click Remediate (at most a guided one you confirm by typing). Show this in security reviews.
For your team: easy answer to security questions; clean compliance evidence.
Related lessons
- L1: 3-step workflow
- L2: Allowlisted, guided, advisory
- L3: Approval gate
- L4: Error classes
- L6: Remediation notifications (next)