What the actual 1z0-908 sitting feels like

This exam is mostly straightforward multiple-choice and multiple-select, but Oracle likes to hide the real test inside wording that sounds operationally familiar. Expect scenario questions rather than pure definition recall: a replica stopped, a server won’t start after a config change, a backup is usable but recovery is incomplete, a user can connect but not perform a task, or Group Replication is online but not healthy. The pressure is not from weird simulations; it’s from Oracle giving you 3 plausible administrative actions and one answer that matches exact MySQL 8.0 behavior.

Time-wise, don’t treat every item equally. On this exam, short factual questions about account management, logs, or SQL modes can be answered quickly if you know the feature boundaries. Save your thinking time for replication, backup/recovery, and InnoDB behavior questions because those are where Oracle tends to stack multiple conditions into one prompt. If you get a multi-select item involving binary logs, GTIDs, or Group Replication, assume it is testing whether you know the prerequisites and side effects, not just the command syntax.

A practical pacing rule that worked well here: move fast through questions that mention one isolated feature, and budget extra time for anything that combines startup options, persisted variables, replication metadata, or recovery steps. In Oracle exams you can usually review flagged questions before final submission, so use that for the questions with two near-correct answers. The ones worth revisiting on 1z0-908 are usually the ones that ask for the “best” administrative action after an error condition.

Quick pattern recognition for this exam:

If the stem mentions MySQL 8.0 specifically, expect a trap based on behavior changed from 5.7.
If the question includes SET PERSIST, roles, caching_sha2_password, data dictionary, or clone plugin, it is almost certainly checking whether you know the 8.0-native way, not the older workaround.
If the prompt mixes backup and binary logs, think in terms of point-in-time recovery order, not backup creation commands.
If a replication question mentions GTID consistency, auto-positioning, or errant transactions, be suspicious of answers that would work only in file/position replication.

The domains I would overweight for a pass

If your study time is limited, push hard on the operational DBA domains rather than broad SQL knowledge. This exam rewards people who know how MySQL 8.0 behaves in production. The biggest payoff areas are server configuration and startup, InnoDB/storage behavior, backup and recovery, security/account administration, and replication/high availability.

The most exam-productive priorities are:

Backup, restore, and recovery: full vs incremental concepts, binary log usage for PITR, what metadata you need to perform recovery correctly, and what changes when GTIDs are involved.
Replication and HA: asynchronous replication basics, GTID-based replication, replication lag symptoms, relay log/binary log implications, and Group Replication/InnoDB Cluster prerequisites.
Security administration: users, roles, dynamic privileges, authentication plugins, password management, SSL/TLS basics, and privilege scope.
Server configuration and runtime management: option files, startup failures, dynamic vs static variables, persisted system variables, logs, and performance-impacting settings.
InnoDB and storage internals at admin level: redo/undo, tablespaces, buffer pool behavior, locking/isolation symptoms, and crash recovery basics.

What I would not overinvest in compared with those: generic SQL syntax, broad developer features, or optimizer trivia unless it is tied to administration. Oracle’s DBA exam does ask about performance and indexing, but usually from the angle of diagnosing operational impact, not writing clever queries.

A lot of candidates underprepare security because it looks easy. Don’t. Oracle loves questions where the wrong answer is an old privilege model assumption. In 8.0, roles and dynamic privileges matter, and some administrative capabilities are no longer represented by the old all-purpose SUPER logic people remember from earlier versions.

8.0-only features Oracle expects you to know cold

The easiest points to lose are on features that feel familiar but changed in MySQL 8.0. Oracle knows many candidates have older MySQL habits, so it writes questions to exploit that.

The 8.0-specific areas I saw reflected again and again:

Transactional data dictionary replacing file-based metadata assumptions. If an answer depends on old metadata file behavior, be careful.
SET PERSIST and SET PERSIST_ONLY. Know what survives restart, what writes to the persisted config file, and when a restart is still required because the variable itself is not dynamic.
Roles and default roles. Oracle likes to ask what a user can actually do after role assignment versus after activation/default-role configuration.
Dynamic privileges such as administrative capabilities that are more granular than old static global privileges.
Default authentication plugin behavior and compatibility implications. Questions may imply a client issue or authentication mismatch rather than a privilege issue.
Clone plugin use cases versus logical dump tools or physical backup approaches.

A common trap: Oracle will offer one answer that is technically valid in “some MySQL version” and another that is correct for MySQL 8.0 administration. Pick the one aligned with 8.0 defaults and supported mechanisms. For example, if a question hints at changing configuration permanently during runtime, think immediately of persisted system variables, not just editing my.cnf and restarting.

Another repeat offender is the distinction between these administrative actions:

changing a variable for the current session
changing it globally until restart
changing it persistently across restart
attempting to change a read-only/non-dynamic variable without restart

If you can’t classify variables that way, you’ll drop easy marks.

Backup and recovery: where Oracle hides the ugly questions

This is one of the highest-value sections to master because the questions are rarely shallow. Oracle likes to describe a backup/recovery chain and ask what is missing, what order to apply steps in, or why the result is inconsistent.

What to internalize:

Logical vs physical backup implications. Logical backups are flexible but slower and can be sensitive to consistency approach; physical methods are faster for large instances but have different restore characteristics.
Point-in-time recovery always depends on more than “having a backup.” You need the correct binary logs and the right stopping point or transaction position/GTID boundary.
Binary log format and retention matter operationally. If the logs needed for recovery are purged, the backup alone may not get you to the desired point.
Consistent backup concepts for InnoDB versus mixed-engine environments. Oracle may test whether your chosen backup method preserves transactional consistency.

Typical Oracle-style trap patterns:

A question says a full backup succeeded, but recovery cannot reach the moment before a bad statement. The hidden issue is usually missing binary logs, wrong log order, or replaying too far.
The prompt mentions replication plus recovery. The trap is mixing up replica relay logs with source binary logs or assuming they are interchangeable for recovery.
The stem says “recover a dropped table” and gives options involving redo/undo assumptions that are too simplistic. Be careful: administrative recovery options depend heavily on whether you have a valid backup and binary logs, not wishful engine internals.

Specific study targets for 1z0-908:

Practice reading recovery scenarios and stating the exact sequence: restore backup, start in the required state, apply binary logs to the target point, validate, then resume normal operations.
Know what metadata from a backup is useful for matching binary logs or identifying the correct recovery position.
Be comfortable with the difference between restoring to latest available state and recovering to a precise point before an error.

If you see a multiple-select asking which artifacts are required for PITR, don’t just click “backup” and “binlogs” reflexively. Check whether the scenario also requires knowledge of the exact time/position/GTID endpoint.

Replication and Group Replication: the exam’s most expensive mistakes

Replication is where Oracle packs the most nuance into one question. If you only know the happy-path setup steps, this exam will punish that. You need to know why replication breaks, how GTID changes the mechanics, and what Group Replication requires before it even starts.

For classic asynchronous replication, make sure you can reason about:

binary log on the source, relay log on the replica, and what each is used for
file/position versus GTID auto-positioning
what happens when replication is stopped by an error and which administrative action is safe
the practical meaning of replication lag and how to identify whether the bottleneck is I/O or SQL apply side

Oracle frequently tests prerequisites and compatibility rather than syntax. A question may ask why GTID-based replication cannot be enabled cleanly, and the real answer is a consistency prerequisite was ignored, not that the CHANGE REPLICATION SOURCE TO syntax was wrong.

For Group Replication and related HA concepts, know these cold:

required settings and plugins before joining a group
why row-based logging is tied to Group Replication expectations
the role of GTIDs in Group Replication environments
single-primary versus multi-primary implications at a high level
what recovery/join failure symptoms usually point to: misconfiguration, networking, distributed recovery prerequisites, or incompatible settings

The trap Oracle likes here is offering one answer that fixes ordinary asynchronous replication but not Group Replication. If the question mentions a member joining a group, certification, quorum, distributed recovery, or InnoDB Cluster, stop thinking like a basic source/replica admin.

Another gotcha: candidates often memorize commands but not the implications of replication filters, log settings, and transaction consistency. Oracle questions often ask what will replicate or what will break after a failover-style event. If you don’t understand the data flow, the answer choices all look reasonable.

Security and account management: old habits fail here

This section looks easy until Oracle starts mixing users, roles, authentication plugins, and administrative privileges in one scenario. The exam expects you to know what grants actually become effective and how authentication and authorization are separate problems.

High-yield distinctions:

Authentication plugin issue versus missing privilege. If a user cannot connect at all, don’t jump straight to GRANT statements.
Role granted versus role active by default. Oracle likes questions where a role exists but the user session does not get the expected privileges automatically.
Dynamic privileges versus legacy broad privilege assumptions. Don’t default to “grant SUPER.” Think more granularly in 8.0 terms.
Account resource and password controls. These can block or alter behavior even when object privileges are correct.

Watch for wording like “an application suddenly fails after client library changes” or “older connector cannot authenticate.” That often points to authentication plugin compatibility, not schema permission changes.

The exam also likes SSL/TLS questions framed operationally: not deep crypto, but enough to know when secure transport requirements or certificate configuration affect client connections or replication channels.

A fast way to study this domain effectively is to build mini-scenarios:

User can connect but cannot administer backup-related tasks.
User was granted a role but still lacks expected rights in a new session.
Replication user exists but channel authentication fails.
Password policy or account locking prevents expected access.

If you can explain the exact fix for each without hand-waving, you’re in good shape.

InnoDB, locking, and configuration questions that look simple but aren’t

Oracle does not need you to be an engine developer, but it absolutely expects a DBA to understand InnoDB behavior well enough to diagnose symptoms. These questions often look like generic performance items, but they are really about transaction behavior and server administration.

The recurring pain points:

Isolation and locking side effects. Candidates know the names of isolation levels but can’t predict blocking, consistent reads, or why a transaction sees what it sees.
Redo/undo and crash recovery basics. Oracle may ask what enables recovery after a crash or what component is involved in rolling back incomplete transactions.
Buffer pool and I/O tuning concepts. You don’t need every tuning formula, but you do need to know what major settings influence memory use and read/write behavior.
Tablespaces and file-per-table behavior at an admin level. Enough to understand storage layout and maintenance implications.

Oracle’s trap style here is subtle: it gives two answers that are both “performance related,” but only one actually addresses the symptom described. Example pattern: a workload is slow after restart and one answer suggests query cache style thinking from ancient MySQL habits, while the correct answer is tied to buffer pool warm-up behavior or disk I/O realities in InnoDB.

On configuration, be precise about startup and logging:

know the difference between error log, general query log, slow query log, and binary log
know which logs are for troubleshooting startup, workload analysis, or replication/recovery
know that some configuration mistakes prevent startup entirely, while others are accepted only after restart

If a question says MySQL failed to start after a config change, your first mental branch should be: was the variable name/value invalid, was the option placed incorrectly, is the variable dynamic or startup-only, and what log would confirm it?

How to use the 218 practice questions without wasting them

For this exam, brute-force repetition is less useful than tagging the questions by operational failure mode. I would divide the 218 practice questions into clusters that mirror the exam’s hardest pivots:

startup/configuration and persisted variables
user/role/authentication problems
backup/PITR sequences
async replication and GTID issues
Group Replication prerequisites and failure states
InnoDB locking/recovery/storage behavior

When you miss a question, don’t just note the right answer. Write down the hidden discriminator Oracle used. For 1z0-908 those discriminators are usually things like:

“this required a default role, not just a granted role”
“this needed binary logs from the source, not relay logs from the replica”
“this setting can be persisted, but the variable still needs restart to take effect”
“this answer applied to older MySQL behavior, not 8.0”
“this HA scenario was Group Replication, so async replication logic was insufficient”

That method matters because Oracle reuses the same conceptual traps in different wording. Once you recognize the trap category, the exam gets easier fast.

I’d also recommend doing timed sets specifically for replication and recovery. Those are the questions most likely to eat your clock because they contain sequences and dependencies. If you can answer those under mild time pressure, the rest of the exam feels much more manageable.

The final-week cram list I’d use again

If I had seven days left for 1z0-908, I would not reread broad documentation randomly. I’d run a narrow checklist focused on Oracle’s favorite weak spots.

Day 1-2: configuration and security refresh

Review dynamic vs static variables.
Rehearse SET GLOBAL, SET PERSIST, and when restart is still required.
Review roles, default roles, dynamic privileges, password/account controls, and authentication plugin implications.
Confirm log purposes: error, slow, general, binary, relay.

Day 3-4: backup, restore, PITR

Walk through at least 5 recovery scenarios on paper.
For each, state exactly what files/logs are needed and in what order.
Review consistency concerns for backup methods and the role of binary logs in PITR.

Day 5: replication and GTID

Rehearse source/replica terminology, replication metadata, lag diagnosis, and GTID auto-positioning concepts.
Review why replication stops and what kinds of fixes are safe versus dangerous.

Day 6: Group Replication and InnoDB

Memorize Group Replication prerequisites and the settings that commonly appear in exam stems.
Review InnoDB locking/isolation, crash recovery basics, and tablespace/storage administration.

Day 7: mixed timed review

Do a timed set of only your weakest domains.
Revisit every missed question by trap type, not topic title.

The night-before list should be tiny and specific:

8.0-only admin features
persisted variables behavior
roles/default roles/dynamic privileges
PITR sequence
GTID and Group Replication prerequisites
error log versus binary/relay/general/slow logs

That list is small enough to retain and broad enough to catch a surprising number of Oracle’s trick questions.