Browse Oracle Certification Guides

MySQL 1Z0-908 Cheat Sheet

December 13, 2025

MySQL 1Z0-908 cheat sheet for key facts, traps, service mappings, and final review.

On this page

Use this for last-mile review. 1Z0-908 rewards operational realism: the safest workable backup, recovery, replication, and security path usually beats the fanciest feature.

1Z0-908 answer sequence

Use this when the stem mixes recovery, replication, security, performance, or configuration.

    flowchart TD
	  S["Scenario"] --> R["Classify recovery or replication need"]
	  R --> S1["Check security or access hardening"]
	  S1 --> P["Check performance or configuration evidence"]
	  P --> V["Verify with logs, status, or tested restore"]

Read every DBA stem in this order

  1. Decide whether the problem is backup/recovery, replication/HA, security, performance, configuration, or maintenance.
  2. Match the scenario to RPO, RTO, data size, outage tolerance, and operational complexity.
  3. Prefer tested recovery and least privilege before feature richness.
  4. Use concrete evidence such as status output, logs, EXPLAIN, or replication state before changing configuration.
  5. Keep rollback and restore paths explicit.

Fast lane picker

If the question is mainly about… Start with… Usual winning move
how to recover data backup type plus binary log story recovery path first
reducing outage or lag replication and HA role do not confuse replica presence with failover readiness
hardening access users, roles, TLS, and least privilege security before convenience
performance pain InnoDB, logs, and EXPLAIN evidence inspect before tuning
safe admin workflow tested restore, rollback, and staging operations discipline matters
startup or config issue option file, variable scope, and log evidence prove config effect before retuning
upgrade or patching compatibility, backup, staging, rollback safe maintenance first

Recovery and replication map

    flowchart TD
	  Full["Full Backup"] --> Restore["Restore Base State"]
	  Binlog["Binary Logs"] --> Restore
	  Restore --> Point["Point-in-Time Recovery"]
	  Source["Primary / Source"] --> Repl["Replication"]
	  Repl --> Replica["Replica"]
	  Replica --> Failover["Failover Readiness"]

Fast rule: backups protect against corruption or operator mistakes; replication supports availability and scale. They are related but not interchangeable.

Operational decision map

Boundary Ask this first
recovery what data-loss and downtime target must be met?
replication is the goal read scale, availability, delayed protection, or migration?
security who should connect, from where, with which privileges and encryption?
configuration is the variable dynamic, persistent, global, session, or startup-only?
performance is the bottleneck query shape, index fit, locking, IO, memory, or concurrency?
maintenance can the change be tested, rolled back, and verified safely?

Backup chooser

Requirement Strongest first fit Why
smaller database and simple restore logical backup like mysqldump easier restore workflow
larger database and faster restore path physical backup approach lower restore time
point-in-time recovery full backup plus binary logs replay change history
lowest operational risk tested restores and validation backup without restore proof is weak
smallest logical export of selected objects logical dump of targeted schemas/tables object-level portability
lowest restore time for large server physical backup plus validated restore procedure faster base restore path

Fast reminders

1mysqldump --single-transaction --routines --triggers --events \
2  --databases appdb > appdb.sql

1SHOW VARIABLES LIKE 'log_bin';
2SHOW BINARY LOGS;

Backup traps

Trap Better reading
“we have backups” without restore testing restore proof matters more than backup existence
assuming replication removes the need for backups replication can copy mistakes too
ignoring binary logs when PITR is required PITR needs change history, not just a base backup
taking large logical dumps without thinking about restore time backup format must match recovery target
forgetting routines, triggers, or events object completeness matters in logical backup strategy

Restore and recovery chooser

Scenario Better first move
dropped data or bad transaction restore base backup and replay binary logs as needed
corruption discovered later restore to clean base and recover carefully to target point
test of readiness perform actual restore drill with verification
migration or export need logical backup path may fit better than physical image
uncertain recovery point identify binlog position/time before improvising

Recovery traps

Trap Better reading
restore equals recovery complete validate data, applications, privileges, and replication state afterward
replaying all logs blindly choose the correct stop point for PITR
backup file exists so restore will work media integrity and process discipline still matter
recovery ignores application sequence app-side consistency and cutover matter too

Replication and HA chooser

Concern Strongest first lane
read scale and delayed apply questions replica behavior and lag
recovery after source failure failover readiness, not just replication existence
correctness after replication issue thread status, schema drift, and data conflict review
modern coordinated topology GTID-aware or managed HA reasoning
migration with low cutover risk replication-assisted migration pattern
protection from operator mistake delayed replica can be a deliberate safety control

Fast status checks

1SHOW MASTER STATUS;
2SHOW REPLICA STATUS\G

Replication traps

Trap Better reading
assuming a replica is automatically failover-ready lag, consistency, and promotion readiness still matter
debugging replication without checking thread errors first start with replica status and concrete failure signals
treating replication lag as purely a network issue schema conflicts, workload pressure, and SQL thread errors can matter too
source/replica terminology ignored know which side generates and which side applies changes
GTID treated as a buzzword only it changes replication administration and failover reasoning

Replication troubleshooting order

Symptom Check first
replica stopped IO/SQL thread status and error text
large lag write volume, SQL apply pressure, lock waits, schema/index issues
inconsistent data replication errors, skipped events, drift, and unsafe fixes
failover candidate uncertain lag, read-only state, promotion runbook, application cutover path
topology confusion source role, replica role, GTID/binlog state, and version compatibility

HA and failover reminders

Concern Better rule
replica for reads does not by itself prove promotion readiness
automatic failover still needs monitoring, fencing, and clear promotion logic
split-brain risk avoid ambiguous writers and unclear promotion authority
delayed replica useful protection, but not for zero-data-loss failover
replica promotion verify app routing, privileges, consistency, and backups after cutover

Security and accounts

Concern Better rule
user scope grant only needed privileges
roles prefer reusable role patterns where appropriate
auth plugins know how to inspect the active plugin
network encryption prefer TLS for non-local traffic
admin account exposure reduce host scope and rotate credentials deliberately
secret management do not leave passwords in scripts or command history when avoidable

Fast reminders

1SHOW GRANTS FOR 'app'@'10.%';
2SELECT user, host, plugin FROM mysql.user;

Security traps

Trap Better reading
% host wildcard used casually narrow host scope when practical
privileges granted for convenience least privilege is usually the stronger answer
no TLS because network is “internal” exam-safe defaults still favor encrypted transport
using one account for app, admin, and automation separate duties where possible
ignoring auditability security questions often imply logging and accountability too

Installation and configuration reminders

Topic Fast rule
startup option may require restart or option-file change
dynamic variable can often be changed at runtime
persistent config know whether change survives restart
error log first place to check startup and runtime failures
option-file precedence configuration source and override order matter
version compatibility upgrade planning starts with supported path and feature differences

InnoDB and performance cues

Signal Strongest first interpretation
poor cache behavior buffer pool sizing and working set
slow statements slow query log and EXPLAIN
lock or concurrency pain InnoDB status, transaction scope, and contention
missing or weak index use SHOW INDEX plus predicate shape
heavy write pressure redo/binlog cost, flush behavior, and index overhead
checkpoint or IO pressure storage, dirty-page behavior, and workload burst pattern

Fast reminders

1SHOW ENGINE INNODB STATUS;
2EXPLAIN SELECT * FROM orders WHERE customer_id = 123;
3SHOW INDEX FROM orders;

Performance traps

Trap Better reading
tuning buffer sizes before identifying workload workload classification comes first
adding indexes without checking write cost more indexes can hurt write-heavy paths
blaming storage for all latency locks, query plans, or bad SQL may be the issue
treating EXPLAIN as optional execution evidence beats intuition
ignoring connection count and transaction length concurrency pressure often comes from app behavior

Performance troubleshooting order

Symptom Check first
one query is slow EXPLAIN, predicate shape, index fit
many queries are slow buffer pool, IO, concurrency, and workload spike
locking pain open transactions, lock waits, and statement order
server restart issue error log, config change, disk/memory pressure
sudden regressions recent change, stats drift, schema/index change, or version difference

Operations and upgrade cues

Need Better answer
safe upgrade stage, backup, test, and rollback plan
log review error log first, slow query log by intent
operational confidence health checks plus tested recovery workflow
routine maintenance clear procedure, timing, communication, and validation
config change narrow scope plus revert plan

Upgrade and maintenance traps

Trap Better reading
upgrading in place without backup or rehearsal test and rollback are part of the upgrade plan
skipping post-upgrade validation service start is not full success
changing many variables at once narrow blast radius improves debugging
maintenance window without communication operations includes predictability and coordination

Decision order that usually wins

  1. Choose the lane: recovery, replication, security, performance, configuration, or maintenance.
  2. Match the answer to RPO, RTO, data size, and operational risk.
  3. Use logs, status output, and EXPLAIN before speculative tuning.
  4. Prefer tested restore and failover procedures over theoretical feature coverage.
  5. Keep least privilege, rollback, and validation in scope.

Last 15-minute review

If you only keep one thing from each lane… Remember this
backup pick the backup strategy by restore need, not by habit
PITR full backup plus binary logs
replication replica presence is not the same as failover readiness
security least privilege and TLS still matter on DBA questions
performance inspect before tuning; evidence beats guessing
config know which changes need restart and where the evidence lives
upgrades backup, test, validate, and keep rollback explicit

What strong 1Z0-908 answers usually do

  • start with recovery and operational safety before chasing performance tweaks
  • match backup and replication choices to the actual failure scenario
  • prefer least-privilege and simpler rollback paths when answers are close
  • treat RPO, RTO, and operational complexity as primary decision inputs
  • separate replication benefits from real failover readiness
  • use error logs, status commands, and restore drills as the proof layer
Revised on Monday, June 15, 2026
Study Plan
Sample Questions