Governance and responsible use: 15% of CCAO-F, and the domain engineers lose

Governance, Risk and Responsible Use is 15% of CCAO-F — roughly 9 of 60 items, the third-largest domain on the paper and larger than either product selection or configuration. It has four objectives: judging whether a use case is appropriate, applying data, privacy and regulatory considerations, following your organisation’s own AI policy, and understanding the ethical implications of what you build. None of the four has an engineering answer, and that is exactly why they are worth preparing for.

How much it is worth

On a 60-item paper, only Output Evaluation and Validation at 21% and Workflow Integration at 16% are larger. Governance outranks Product and Model Selection, Configuration and Knowledge Management, and Troubleshooting. Candidates who plan by interest rather than by weight tend to invert that order exactly — the published weights for all four tracks are the quickest correction.

The four objectives

Note what is absent. No objective names a statute, a jurisdiction or a framework, and nothing asks you to recall regulatory text — the architect professional exam is the only one in the programme that names any. The examinable skill is applying a stated constraint to a described situation — which means the scenario always contains the information you need, and the difficulty is entirely in noticing it.

Why engineers lose marks here

The recurring shape is a scenario with real pressure in it — a deadline, an unavailable approver, a restriction that makes the obvious approach impossible — and four options, three of which solve the problem. The correct one usually does not solve it. It narrows the request, seeks approval, redesigns the task, or stops.

That reads as defeatist to anyone whose job is making things work, which is precisely why it is examined. A governance restriction is not an obstacle between you and the goal; on this domain it is the goal. Options that meet the deadline by working around the restriction are the standard distractor, and they are written to be attractive.

Access is not permission

One idea earns its own section because it appears in more than one form. Reaching data and having permission to use it for a particular purpose are two separate facts. A connector that is configured, a folder that is shared, a file somebody sent you — each grants access, and none of them grants authorisation for whatever you were about to do next.

The same distinction shows up on the technical tracks in a different vocabulary, where it is about what an agent holds rather than what a person can reach. That version is covered in prompt injection and guardrails, and it is the same judgment wearing different clothes.

What a qualified reviewer is

Determining when human review is required is formally a Domain 2 objective, and it lands here often enough to be worth studying together. The exam’s position is narrow: a reviewer needs the authority to approve the thing and the competence to judge it. Being a person is not a qualification.

So an option that routes a clinical judgment to whoever is on shift, or a contract question to the nearest available colleague, has not answered the question. Neither has an option that reports the output was checked without saying by whom or against what — see evaluating Claude output for how the checking side of that is examined, and human in the loop for when a person has to be involved in the first place.

When the evidence is not there

The last recurring rule is the one that feels least like an answer: when the evidence to support a claim does not exist, saying so is better than producing something plausible. State the gap, name what would resolve it, and ask.

It is worth practising because it contradicts the instinct an exam builds in you — that every question has an answer among the options and that picking one is always better than declining. On this domain, an option that declines is a live candidate, and treating it as a throwaway is how people lose two or three marks without noticing. That is also the reason the common mistakes post puts it near the top.

Key takeaways

• Fifteen percent, nine items. Third-largest domain on CCAO-F, ahead of product selection, configuration and troubleshooting.
• Nothing to memorise. No objective names a statute or jurisdiction; every scenario supplies the constraint you need.
• The right answer often does not solve the problem. Narrowing, seeking approval or stopping beats a clever route around a restriction.
• Access is not permission. Reaching the data says nothing about being allowed to use it for this purpose.
• A reviewer needs authority and competence. Availability is not a qualification, and options that offer it are wrong.
• Declining is a real option. Where evidence is absent, stating the gap beats producing something plausible.