Dataiku Developer Certification common mistakes
Dataiku Developer Certification · Understand the traps and how to avoid them.
Calling a schema-changing write safe because it returned successfully.
A narrow operation or measure does not establish the complete evidence, authority, validity or business outcome.
What to do instead
Check output definitions, intended data and downstream consumers under authorization.
Treating a code environment as complete isolation from untrusted code.
A narrow operation or measure does not establish the complete evidence, authority, validity or business outcome.
What to do instead
Review actual execution privileges, data access and supported infrastructure boundaries.
Expecting a row-count trigger to detect every edit to existing rows.
A narrow operation or measure does not establish the complete evidence, authority, validity or business outcome.
What to do instead
Match the observed value to the actual change-detection need and test representative changes.
Equating a published bundle with a verified activated production result.
A narrow operation or measure does not establish the complete evidence, authority, validity or business outcome.
What to do instead
Check deployed version, settings, dependencies and actual run/service outcomes.
Aggregating a join result without checking key multiplicity.
A narrow operation or measure does not establish the complete evidence, authority, validity or business outcome.
What to do instead
Verify intended grain, uniqueness and expected rows/totals with a tiny example.
Filtering grouped results in a WHERE clause (for example WHERE COUNT(*) > 5), comparing a column to NULL with = instead of IS NULL, or assuming UNION and JOIN do the same thing when combining two tables.
WHERE is encountered first in every tutorial and gets generalized to all filtering, and NULL is treated as an ordinary value rather than as unknown, which produces wrong intuitions about three-valued logic.
What to do instead
Classify every filter before writing it: row-level predicates go in WHERE, group-level predicates go in HAVING, and any NULL test uses IS NULL or IS NOT NULL. Sketch the result table for JOIN (horizontal, matched columns) versus UNION (vertical, matching schemas) to fix the distinction.
Declaring a table well designed because it 'looks organized', while leaving a transitive dependency such as storing instructor name and office in a course-enrollment table, or designating a foreign key as the primary key without checking uniqueness.
Spreadsheet intuition treats any tidy grid as normalized, and the candidate checks only that a key exists rather than testing candidate keys against every functional dependency the scenario implies.
What to do instead
List the functional dependencies in plain sentences ('each course has one instructor, and each instructor has one office') before any table is drawn. Place every determinant on the left, split off any non-key dependency into its own relation, and verify that each relation's chosen key uniquely determines all its other attributes.
Confusing authentication with authorisation and assigning the wrong control to a scenario, for example answering 'multi-factor authentication' when the question is about limiting what a logged-in user can reach.
Both live in the same identity domain and both are described with similar vocabulary (access, permissions, credentials), so candidates pattern-match on 'access' and pick the wrong half of the pair.
What to do instead
Distinguish identity verification from the authorization decision for the actual request. Some resources allow unauthenticated public access, and authorization can be checked repeatedly during a session. Roles and permissions concern allowed actions rather than merely proving who supplied a credential.
Treating symmetric and asymmetric keys as interchangeable and choosing the wrong key for a task, such as using a public key to decrypt a password vault or a private key to encrypt bulk data.
The key pair vocabulary is learned as a pair of words rather than as a workflow, so candidates cannot reconstruct who holds which key and what each operation achieves.
What to do instead
Draw the two-party diagram once from memory: sender encrypts with the recipient's public key, recipient decrypts with their own private key; sender signs with their own private key, verifier checks with the sender's public key. Rehearse it until you can derive any key question from the diagram rather than recall.
Answering control-design questions with control-testing or monitoring activities, and vice versa.
Control design, operating effectiveness, and continuous monitoring appear together in real programmes, so candidates conflate them. Exam stems often hinge on whether a control exists on paper versus whether it actually worked in practice.
What to do instead
Label the question first: 'does the control exist and is it designed suitably?' (design), 'did it operate as intended over the period?' (effectiveness), or 'is it still working now?' (monitoring). Then eliminate options that answer a different one of those three questions.
Assuming an emerging-technology risk should be avoided or blocked until it is fully understood, rather than managed through incremental assessment and monitoring.
Uncertainty feels like a reason to stop, and regulatory or security caution reinforces that instinct. CRISC expects emerging risk to be assessed, piloted, and monitored with defined triggers, not reflexively prohibited.
What to do instead
When a stem describes new or evolving technology with limited information, prefer the option that combines a bounded assessment with defined monitoring triggers and review points. Treat 'prohibit until proven safe' and 'proceed without assessment' as the two distractors.
Answering incident response questions with the containment step when the stem describes detection, triage, or evidence preservation, and skipping the ordering of the response phases.
Containment feels like the most decisive action, and candidates have not internalised that the phases are sequential and that premature containment can destroy forensic evidence.
What to do instead
Identify the action and the framework specified in the scenario. Detection, analysis, containment, evidence collection and recovery can overlap under urgency; preserve safety and authority while following the applicable playbook. Do not infer one universally correct action solely from the presence of a word such as logs.