General Exam Tips
- 1.Read the question stem BEFORE reading the full scenario — identify what role, framework, and lifecycle stage are in play before absorbing scenario details designed to distract.
- 2.Apply the Role-Framework-Lifecycle triad: identify (1) who is acting (provider, deployer, importer), (2) which framework governs (EU AI Act, NIST AI RMF, ISO 42001), and (3) what lifecycle stage is in scope. The answer only makes sense at their intersection.
- 3.Multi-select questions require ALL correct answers — no partial credit. When you see 'select all that apply,' eliminate wrong answers first rather than hunting for right ones.
- 4.Eliminate by exception: on scenario questions with four plausible answers, find the option that contradicts a governance principle (deploying without documentation, skipping assessment, proceeding without oversight) — that is always wrong.
- 5.The 15-minute optional break is after question 50. Questions answered before the break CANNOT be revisited. Plan your first-pass strategy before you start.
- 6.Target ~90 seconds per question on first pass. Flag anything requiring more thought. Case study sets share a scenario — read the scenario once, answer all related questions, then flag the hardest for review.
- 7.Never leave a question unanswered — no penalty for guessing. If stuck, eliminate two options and guess between the remaining two.
- 8.The 15 unscored pilot questions are invisible — treat every question as scored. Do not try to identify which questions are pilots.
- 9.Domain IV (Governing Deployment and Use) is the most under-prepared domain — it carries 27% of the exam. If you studied lightly on monitoring, drift detection, and incident response, that is your biggest risk.
- 10.When the exam asks about 'best' or 'most appropriate' action, think governance-first: the answer that prioritizes documentation, assessment, stakeholder notification, or halting for review almost always beats answers that proceed without oversight.
Quick Navigation
Understanding the Foundations of AI Governance
Must-Know Facts
- All seven NIST Trustworthy AI characteristics: Valid and Reliable, Safe, Secure and Resilient, Accountable and Transparent, Explainable and Interpretable, Privacy-Enhanced, Fair with Harmful Bias Managed.
- Governance scope in v2.1 is 'AI systems,' not 'AI models' — this change is testable. Supply chain, data pipelines, downstream uses, and infrastructure are all in scope.
- Three tiers of AI governance concepts with distinct meanings: Ethical AI (moral principles), Responsible AI (operational framework with accountability and governance processes), Trustworthy AI (systems meeting technical and governance standards). Each is a different level of abstraction.
- Third-party risk management is a Domain I topic, not just Domain IV. Vendor assessment, contract clauses, and supply chain governance belong to foundational governance.
- The exam tests value creation AND risk — governance is not just about preventing harm, it is also about enabling the organization to realize AI value safely.
- AI governance roles: AI Governance Officer = develops policy; Responsible AI Program Manager = operationalizes policy; AI Risk Analyst = identifies and assesses risks. These roles are complementary, not interchangeable.
- IP and data governance policy updates are foundational governance obligations (Domain I, competency I.C.2). Organizations must evaluate and update these policies for AI.
- AI lifecycle stages: problem definition, data collection/preparation, model development/training, testing/validation, release readiness/go-no-go, deployment, post-deployment monitoring, and decommissioning.
Common Traps
Confusing Pairs
Scenario Tips
When the question describes a vendor updating their AI model without notifying the deploying organization, causing unexpected output changes...
The answer addresses third-party AI risk management and supply chain governance — contractual controls, change notification requirements, and audit rights are the governance gap.
Answers about differential privacy or conformity assessment sound technical and plausible but address the wrong gap. The problem is governance of the vendor relationship, not a privacy or compliance technique.
When the question asks which governance concept the organization should implement to enable AI value while managing risk...
Responsible AI — it explicitly encompasses both value creation and risk management as an operational framework, unlike Ethical AI (only principles) or Trustworthy AI (outcome standard).
Ethical AI is tempting but addresses only the principles side; it does not include the operational framework for balancing value and risk.
When the question asks what expanded AI governance should cover beyond models...
Entire AI systems including data pipelines, infrastructure, third-party components, supply chain dependencies, and downstream uses — reflecting the v2.1 shift from 'AI models' to 'AI systems.'
Options limiting scope to training data, evaluation metrics, or deployment environments each capture only a subset. The v2.1 answer is comprehensive system-level governance.
Last-Minute Facts
Understanding How Laws, Standards, and Frameworks Apply to AI
Must-Know Facts
- EU AI Act risk tiers with examples: Unacceptable/Prohibited (social scoring, subliminal manipulation, emotion recognition in workplaces/schools, untargeted facial scraping) — banned since Feb 2, 2025. High-risk (Annex III: hiring, credit scoring, critical infrastructure, biometrics, education access, law enforcement, migration). Limited (chatbots, deepfakes — transparency only). Minimal (no requirements).
- Provider obligations (EU AI Act): design, technical documentation, conformity assessment, CE marking, registration in EU AI database, post-market monitoring, incident reporting.
- Deployer obligations (EU AI Act): operate as intended, ensure human oversight per Article 14, monitor performance, conduct FRIAs where required, notify users of high-risk AI use.
- Deployer can become a provider by: (1) putting their name/trademark on a high-risk system, (2) making substantial modifications, or (3) changing intended purpose. They then assume full provider obligations.
- FRIA (Article 27): Mandatory for deployers of high-risk AI in employment, education, essential services. Completed BEFORE deployment. Must notify market surveillance authority.
- GDPR Article 22: right not to be subject to SOLELY automated decisions with legal or similarly significant effects. Three legal bases: explicit consent, contractual necessity, legal authorization. Must provide meaningful information about logic and a pathway for human intervention.
- GDPR Article 35 DPIA: required BEFORE high-risk processing. AI-specific factors include model error rates across demographics, disparate impact evidence, and training data quality.
- NIST AI RMF four functions: GOVERN (cross-cutting policies and accountability), MAP (context and stakeholder identification), MEASURE (risk analysis and benchmarking), MANAGE (risk treatment and incident response). GOVERN infuses through all others.
- ISO/IEC 42001: certifiable AI management system standard. 10 clauses, Annex A with 38 controls across 9 domains, requires Statement of Applicability.
- ISO/IEC 23894: non-certifiable AI risk management guidance (companion to ISO 31000). ISO/IEC 42005: non-certifiable AI impact assessment methodology (added in v2.1, replaced NIST ARIA).
- GPAI rules: standard GPAI obligations (transparency, documentation, copyright compliance). Systemic risk GPAI (>10^25 FLOPs training compute or AI Office designated): additional risk tracking, mitigation, incident reporting, cybersecurity cooperation.
- South Korea AI Basic Law (effective Jan 2026): transparency/disclosure, human-in-the-loop for high-impact AI, fundamental rights impact assessments, extraterritorial application to foreign companies.
- EU AI Act enforcement timeline: Prohibited — Feb 2, 2025; GPAI rules — Aug 2, 2025; High-risk standalone (Annex III) — Aug 2, 2026; High-risk embedded (Annex II) — Aug 2, 2028.
- EU AI Act fines: Prohibited practices = EUR 35M or 7% turnover. High-risk/GPAI violations = EUR 15M or 3%. False info to authorities = EUR 7.5M or 1%.
Common Traps
Confusing Pairs
Scenario Tips
When a European bank deploys a third-party AI system that automatically denies loan applications with no human review or explanation...
Both GDPR Article 22 (solely automated decision with legal effect, no human intervention pathway) AND EU AI Act Article 14 (human oversight requirement for high-risk AI, credit scoring = Annex III) are violated simultaneously.
Answers citing only one regulation miss the dual-framework violation. ISO 42001 violation is wrong because it is a voluntary standard, not a legal obligation.
When a company deploying high-risk AI in hiring wants to become certified against an AI governance standard...
ISO/IEC 42001 — it is the only certifiable AI management system standard. Requires Statement of Applicability documenting which of the 38 Annex A controls apply.
NIST AI RMF is widely adopted but not certifiable. ISO 23894 and ISO 42005 are guidance documents that cannot be certified against.
When an EU company buys a US AI vendor's model and puts their own brand name on it before deploying in the EU market...
The EU company has become a provider by placing its name/trademark on the system — they now bear full provider obligations including conformity assessment, CE marking, technical documentation, and post-market monitoring.
Treating the company as a deployer misses the role transformation triggered by rebranding. This is one of the most-tested EU AI Act traps.
When the question asks which framework is appropriate for voluntary AI risk management without legal compliance requirements...
NIST AI RMF — it is voluntary guidance with no enforcement mechanism. Organizations choose it for its structured methodology, not legal obligation.
EU AI Act is mandatory, not voluntary. ISO 42001 creates a certifiable standard with audit requirements — not purely voluntary risk management.
Last-Minute Facts
Understanding How to Govern AI Development
Must-Know Facts
- Model cards document: model purpose, training data description, evaluation metrics and results, performance across demographic groups, known limitations, intended and out-of-scope uses, ethical considerations. Created during development, updated throughout lifecycle.
- Datasheets for datasets document: dataset motivation, composition, collection process, preprocessing, intended uses, distribution, maintenance plan, known biases, and limitations. Created when dataset is finalized.
- Bias mitigation timing: Pre-processing (modify training data — rebalancing, removing proxy variables). In-processing (modify training algorithm — add fairness constraints). Post-processing (adjust model outputs to satisfy fairness criteria). Each has different accuracy trade-offs.
- Fairness impossibility theorem: You CANNOT simultaneously satisfy demographic parity, equalized odds, and calibration except in trivial cases. The exam tests which criterion to apply given the context, not just definitions.
- Demographic parity = equal positive outcome rates across groups regardless of qualifications. Equalized odds = equal TPR AND FPR across groups. Equal opportunity = equal TPR only. Disparate impact = 80% rule (protected group rate / majority rate must be >= 0.8). Calibration = consistent probability accuracy across groups.
- Red teaming is pre-deployment testing that must occur BEFORE the go/no-go decision. It tests for vulnerabilities, biases, harmful outputs, safety failures, and adversarial robustness.
- Go/no-go decision gates require: completed risk assessment, documentation review (model cards, datasheets, impact assessment), fairness testing results, security/red team results, stakeholder sign-offs, and identified halt conditions.
- Data governance for AI: provenance (where data came from), lineage (how it was transformed), quality standards, demographic representativeness, labeling accuracy.
- Feature engineering governance: using protected attributes or proxies for protected attributes as features introduces discrimination risk even when intent is neutral.
- Shadow deployment vs. A/B testing: Shadow = new model runs in parallel with NO user impact (outputs logged only). A/B = real subset of users see the new model (actual user impact). The governance implications differ significantly.
- Microsoft RAI Template is a key reference for AI Impact Assessments — know what it covers.
Common Traps
Confusing Pairs
Scenario Tips
When the question asks what documentation an AI governance board should require before approving model deployment...
Model cards + datasheets for datasets + AI impact assessment results + fairness testing evidence + red teaming results + stakeholder sign-offs. All are required for a complete go/no-go governance gate.
Accuracy metrics alone, source code alone, or a business case alone each fail to provide the governance documentation required. The exam rewards comprehensive documentation, not technical artifacts in isolation.
When a hiring AI system shows a 60% positive rate for Group A and 85% for Group B, and an analyst recommends enforcing demographic parity...
Raise the concern that fairness metrics are mathematically incompatible — enforcing demographic parity when groups have different qualification base rates may conflict with equalized odds or cause discrimination in the opposite direction. The governance action is to deliberately choose the appropriate fairness criterion for the context.
Answers that say demographic parity is always correct, or that the model must be discarded entirely because of any bias, fail to engage with the incompatibility of fairness definitions.
When red teaming finds the model fails to detect harmful content for a specific minority language group before deployment...
Document the limitation in the model card, halt deployment for that language group, require additional representative training data and re-testing before expanding coverage.
Deploying with the known gap, removing the language entirely, or proceeding because the majority of users are unaffected are all governance failures. The correct answer always addresses the gap rather than ignoring or circumventing it.
When the question asks how to train a model on distributed data across hospitals without centralizing patient records...
Federated learning — training occurs locally at each hospital, only model updates (gradients) are shared, raw data never leaves the local device.
Differential privacy alone does not solve the data centralization problem — it adds noise to prevent inference but does not eliminate the need to share data. FL + DP combined addresses both concerns.
Last-Minute Facts
Understanding How to Govern AI Deployment and Use
Must-Know Facts
- Human oversight models and TIMING: HITL (Human-in-the-Loop) = human approves BEFORE each action — appropriate for high-risk decisions (medical diagnosis, loan denial). HOTL (Human-on-the-Loop) = human monitors during operation and intervenes for exceptions — appropriate for high-volume, medium-risk operations. HIC (Human-in-Command) = human has final strategic authority over the system — applies at all risk levels for strategic decisions.
- Three types of drift: Data drift = feature/label distribution shifts (input statistics change, relationship may be same). Concept drift = input-output relationship changes due to external factors while input distributions may look unchanged (hardest to detect). Model drift = overall performance degradation (umbrella term).
- Concept drift is hardest to detect because input data looks normal but the underlying relationship has shifted. Example: a medical diagnosis model becomes less accurate after clinical guidelines update, even though patient data types look the same.
- Retraining triggers: Threshold-based (performance KPI drops below defined level), Time-based (scheduled periodic retraining), Data volume-based (sufficient new data accumulated). Must be defined BEFORE deployment, not reactively.
- Retraining is a governance event, not just a technical task. It requires re-validation, updated model documentation, impact assessment review, stakeholder communication, and potentially a new go/no-go decision.
- Incident response must include: defined escalation paths, stakeholder notification with specific timeframes, regulatory reporting obligations (EU AI Act serious incident reporting for high-risk AI providers), and root cause analysis.
- RAG architecture governance requirements: retrieval source quality, data freshness, relevance filtering, and preventing indirect prompt injection through retrieved documents.
- Agentic AI governance (v2.1 addition): least privilege principle (minimum permissions), defined boundaries for autonomous action, accountability attribution, preventing excessive agency.
- System decommissioning governance: model archival, data retention per applicable policies, stakeholder communication, transition planning for dependent processes, lessons learned documentation.
- Vendor AI assessment for third-party deployment: data handling practices, model documentation quality, bias testing results, security controls, incident response processes, regulatory compliance.
Common Traps
Confusing Pairs
Scenario Tips
When the question presents a financial institution running fraud detection at thousands of transactions per second and asks for the appropriate human oversight model...
HOTL — the AI operates autonomously while humans monitor dashboards and intervene for flagged exceptions. HITL is impractical at machine speed.
HITL sounds most thorough but requiring human approval before each transaction is operationally impossible at that volume. HIC provides strategic oversight but does not address operational monitoring needs.
When a healthcare AI system's diagnostic accuracy has been declining for three months but patient data types have not changed, and medical guidelines were recently updated...
Concept drift — the relationship between patient inputs and correct diagnoses changed when guidelines updated, even though the input data distribution remained stable.
Data drift is wrong because input distributions have not changed. Model drift is a general umbrella term, not the specific root cause. Concept drift precisely describes external-factor-driven relationship change with stable inputs.
When an organization is retiring a legacy AI system that has been running for years and asks what governance applies to decommissioning...
Archive the model, retain relevant data per retention policies, communicate the transition to dependent stakeholders, ensure dependent processes have alternatives, and document lessons learned.
Simply deleting the model risks violating data retention requirements and losing audit trails. Transferring to open source introduces new risk with a retired system. Continuing in reduced capacity avoids the governance responsibility of proper decommissioning.
When the question asks what must happen when an organization retriggers training on a production model after performance degrades past a threshold...
Retraining is a governance event: re-validate the retrained model, update model cards and documentation, re-review impact assessments for any changed risk profile, obtain stakeholder sign-offs, and communicate to affected parties before redeployment.
Answers treating retraining as purely technical (update weights, push to production) miss the governance dimension. Retraining requires a new governance gate, not just a technical pipeline run.
When the question involves an AI agent that uses API tools and asks what the primary governance concern is...
Apply least privilege — grant the agent only the minimum permissions needed for its function. Define explicit action boundaries and implement controls to prevent excessive agency and privilege escalation.
Answers focused only on transparency or documentation miss the autonomy-specific governance concern of agentic systems.