Task 1.4: Implement responsible AI across generative AI and agentic systems

• ALow, so that low-severity content is caught

  Incorrect

  Despite its name, Low is the least restrictive level: it blocks only high-severity content.

• BHigh, the most restrictive blocking level

  Correct

  Blocking level High blocks low-, medium- and high-severity content, which is what the owner wants.

• CMedium, the level most deployments start from

  Incorrect

  Medium blocks medium and high severity, so low-severity content would still get through.

• DOff, with annotations returned to the app

  Incorrect

  Off blocks nothing; annotations only report what was detected.

Blocking levels name how strict the control is, not the severity they start at: Low blocks high only, Medium blocks medium and high, High blocks everything from low severity up.

• APrompt Shields detection of user prompt attacks on the staff's input

  Incorrect

  User prompt attack detection is already on by default and looks at the user's own prompt, not the email being summarized.

• BThe protected material control for text in outputs

  Incorrect

  Protected material detection looks for known copyrighted text, not injected instructions.

• CA stricter blocking level for the violence and hate controls

  Incorrect

  Harm category levels filter harmful content; the email's instruction isn't violent or hateful.

• DPrompt Shields detection of document attacks on the email content

  Correct

  Document attacks are instructions hidden in content such as emails. Their detection is off by default and must be enabled in the guardrail.

Prompt Shields cover two attack types. User prompt attacks come from the person typing and are detected by default; document attacks ride in on retrieved or supplied content and need document attack detection switched on.

• ATwo MCP entries: read tools with require_approval never, deletes with always

  Correct

  Each entry's allowed_tools limits the tools it exposes. With approval set to never on the read entry and always on the delete entry, only deletes wait for an approval response from the app.

• BOne MCP tool entry whose allowed_tools list names only the read tools

  Incorrect

  That blocks deletes entirely; the agent loses an ability it is meant to keep.

• COne MCP tool entry with require_approval set to never and an instruction to ask first

  Incorrect

  An instruction is advice to the model, not an enforced control; with approval off, the call still runs.

• DA guardrail on the agent's output that blocks any message about deletion

  Incorrect

  Output guardrails filter the text returned to the user. They don't hold back a tool call.

Gate risky tool calls with the tool's approval setting rather than with prompts. A filtered tool list decides what the agent can call at all; require_approval decides which calls wait for a human answer to an mcp_approval_request.

• AAssign Privileged Monitoring Data Reader to the two auditors only

  Correct

  Once the table is protected, this role is what lets named identities read the sensitive trace content.

• BSet the protection level of the AppGenAIContent table to Protected

  Correct

  Sensitive generative AI attributes are stored in AppGenAIContent; a protected table denies standard read roles by default.

• CExport the traces to a storage account and share it with a SAS token

  Incorrect

  A shared SAS link is a weaker, unaudited copy of the data and doesn't hide content from anyone who holds the link.

• DTurn off tracing for the agents and log only their final answers

  Incorrect

  The auditors would lose the prompts and tool arguments they need, and engineers would lose the timings.

• EGive every engineer Log Analytics Reader on the linked workspace

  Incorrect

  Engineers keep standard read access anyway. On its own it shows them the content unless the table is protected, and it gives the auditors nothing extra.

Route sensitive generative AI attributes to AppGenAIContent, protect that table, and grant Privileged Monitoring Data Reader to the few people who need the content. Everyone else keeps standard read access to the rest of the trace.

• ACopy a competitor's system prompt from the web

  Incorrect

  Borrowed prompts don't fit your scenario and may carry problems.

• BSkip safety instructions because guardrails handle everything

  Incorrect

  Safety system messages complement guardrails; they're different layers.

• CWrite every rule in capital letters at the end of the prompt

  Incorrect

  Formatting isn't the issue; clear, tested components are.

• DStart from the safety system message templates and adapt them

  Correct

  The templates are generic starting points; replace placeholders, add one component at a time and test.

Safety system messages are one mitigation layer alongside guardrails and application controls. Adapt the templates, avoid conflicting instructions and define what to do when the model can't comply.

• AEdits to the agent's instructions after each review

  Incorrect

  Changing instructions alters the agent instead of recording a review.

• BA spreadsheet of conversation IDs kept outside Foundry

  Incorrect

  A separate file loses the link to each trace's details.

• CBuilder annotations on the traces in the portal

  Correct

  Builders and domain experts annotate traces in the portal; annotations appear inline and are tagged as builder annotations.

• DA guardrail that blocks answers the experts dislike

  Incorrect

  Guardrails filter harmful content, not expert quality ratings.

Human review belongs next to the evidence: trace annotations keep expert judgments with the run, and they never overwrite other annotations on the same trace.

• AGrant the agent identity only the role it needs on that container

  Correct

  Agent identities are Entra objects; apply least-privilege Azure RBAC on the downstream resources the agent's tools use.

• BGrant Contributor on the whole subscription as proposed

  Incorrect

  Broad roles widen the damage an agent mistake or attack could cause.

• CShare a developer's personal account credentials with the agent

  Incorrect

  Personal credentials aren't the agent's identity and break auditability.

• DRemove all access and let the agent ask users for keys

  Incorrect

  Keys in conversations are a security risk, and the tool can't work.

Foundry provisions agent identities in Microsoft Entra ID. Treat them as first-class principals: scoped role assignments, auditable access and no shared human credentials.

• AThe token usage metrics of the model deployment for that run

  Incorrect

  Token counts don't explain quality judgments.

• BThe reason the LLM-judge evaluator returns with each score

  Correct

  LLM-judge evaluators return a reason with the score explaining the judgment.

• CThe deployment's version upgrade policy

  Incorrect

  Upgrade policies concern model versions, not evaluation results.

• DThe guardrail annotations on each failing response

  Incorrect

  Guardrail results describe safety, not coherence.

Evaluation results are explainable: read each evaluator's reason, look for patterns across failures, then change the prompt and re-evaluate.

• AThe default guardrail with every control switched off

  Incorrect

  Turning controls off removes protection instead of tailoring it.

• BThe model leaderboard filtered by safety score

  Incorrect

  Leaderboards compare models; they don't configure an agent's guardrails.

• CA blocklist of every word the team considers risky

  Incorrect

  Blocklists match exact terms; they don't select controls.

• DThe guided guardrail setup on the agent's detail page

  Correct

  Guided setup maps answers about users, data and tools to risk categories and applies targeted controls; it is in preview.

Guardrails should fit each agent's scenario. Guided setup builds a tailored set of controls from a short questionnaire, which you can then refine.