CCAO-F Safety and Responsible Use Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The application should rely on Claude's built-in safety behavior to refuse, and the team should not add any additional controls since that would duplicate the model's protection.

  Why it's wrong here

  Relying solely on the model's baseline behavior ignores the value of defense in depth. Even a well-trained model can be influenced by creative role-play framing, and different use contexts carry different risk tolerances. A tutoring application aimed at minors warrants additional layers such as input filtering, scope constraints, and monitoring. Treating the model as the only control leaves the deployment without detection or response capability when something slips through.

• ✗

  The team should disable logging entirely to protect student privacy, and rely on periodic manual spot checks of random sessions instead.

  Why it's wrong here

  Disabling logging removes the ability to detect and investigate misuse patterns such as repeated hazardous-intent attempts. Privacy concerns are legitimate and should be addressed through data minimization, retention limits, and access controls, not by eliminating visibility altogether. Periodic spot checks cannot reliably surface rare but serious attempts. The responsible balance is privacy-preserving logging that still supports safety review.

• ✓

  The team should add application-level controls such as input screening for hazardous-intent patterns, system-prompt scope limits for the tutoring context, and logging so that attempts are visible and reviewable.

  Why this is correct

  Layered application controls complement the model's safety training and are appropriate for a deployment serving minors. Input screening can flag hazardous-intent prompts, a scoped system prompt keeps the assistant within tutoring boundaries, and logging provides visibility for incident review. Together these create detection and accountability that a bare model call does not provide, which is the responsible posture for this risk profile.

• ✗

  The team should raise the model's temperature and encourage more creative role-play responses so students remain engaged with the tutoring experience.

  Why it's wrong here

  Increasing creativity and encouraging open role-play works directly against the goal of containing hazardous requests. Higher temperature makes outputs less predictable and can weaken adherence to safety constraints, while unbounded role-play is a common jailbreak vector. This measure would expand, not reduce, the attack surface of the tutoring application and is inappropriate given the scenario's risk.