|
| 1 | +### YamlMime:ModuleUnit |
| 2 | +uid: learn.wwl.run-governed-ai-workloads-microsoft-foundry.knowledge-check |
| 3 | +title: "Module assessment" |
| 4 | +metadata: |
| 5 | + title: "Knowledge check" |
| 6 | + description: "Knowledge check" |
| 7 | + ms.date: 02/02/2026 |
| 8 | + author: wwlpublish |
| 9 | + ms.author: bradj |
| 10 | + ms.topic: unit |
| 11 | + module_assessment: true |
| 12 | +durationInMinutes: 3 |
| 13 | +content: "Choose the best response for each of the following questions." |
| 14 | +quiz: |
| 15 | + questions: |
| 16 | + - content: "Your organization operates in both the United States and European Union, each with distinct data residency requirements. The US division requires all AI workloads to deploy in US regions, while the EU division requires deployment in EU regions only. Both divisions share the same base security policy requiring managed identities and encryption. How should you structure Microsoft Foundry policies to enforce these requirements?" |
| 17 | + choices: |
| 18 | + - content: "Create separate base security policies for US and EU divisions, each including both security controls and region restrictions specific to their geography." |
| 19 | + isCorrect: false |
| 20 | + explanation: "Business unit policies that add region restrictions to inherited base security controls provide the correct hierarchical approach. This structure ensures universal security requirements apply everywhere while allowing geographic-specific policies at lower levels. Creating separate base policies (option 1) duplicates security rules and creates maintenance overhead when updating encryption standards. Relying on catalog templates (option 3) doesn't enforce governance—developers could modify templates or create resources outside the catalog. The correct pattern uses policy inheritance: base security policy → business unit geography policy → environment-specific policies." |
| 21 | + - content: "Define one organization-wide base security policy with managed identity and encryption requirements, then create business unit policies for US and EU divisions that add region restrictions specific to each geography." |
| 22 | + isCorrect: true |
| 23 | + explanation: "Business unit policies that add region restrictions to inherited base security controls provide the correct hierarchical approach. This structure ensures universal security requirements apply everywhere while allowing geographic-specific policies at lower levels. Creating separate base policies (option 1) duplicates security rules and creates maintenance overhead when updating encryption standards. Relying on catalog templates (option 3) doesn't enforce governance—developers could modify templates or create resources outside the catalog. The correct pattern uses policy inheritance: base security policy → business unit geography policy → environment-specific policies." |
| 24 | + - content: "Configure region restrictions in the resource catalog templates rather than policies, allowing developers to select geography-appropriate templates when provisioning." |
| 25 | + isCorrect: false |
| 26 | + explanation: "Business unit policies that add region restrictions to inherited base security controls provide the correct hierarchical approach. This structure ensures universal security requirements apply everywhere while allowing geographic-specific policies at lower levels. Creating separate base policies (option 1) duplicates security rules and creates maintenance overhead when updating encryption standards. Relying on catalog templates (option 3) doesn't enforce governance—developers could modify templates or create resources outside the catalog. The correct pattern uses policy inheritance: base security policy → business unit geography policy → environment-specific policies." |
| 27 | + - content: "Your compliance scanner reports that 15 Azure OpenAI endpoints in the production environment have diagnostic logging disabled, violating the base security policy that requires logging to a centralized workspace. The resources were provisioned through Microsoft Foundry three weeks ago with logging enabled. What is the most likely cause of this policy drift, and how should you address it?" |
| 28 | + choices: |
| 29 | + - content: "Developers manually disabled logging after provisioning to reduce costs; implement autoremediation in the compliance scanner to re-enable logging when drift is detected." |
| 30 | + isCorrect: true |
| 31 | + explanation: "Manual post-deployment changes causing drift is the most common cause, and autoremediation directly addresses it by automatically restoring compliant configurations. Changing policy enforcement mode to 'Deny' (option 2) prevents future violations but doesn't remediate existing drift—the 15 endpoints would remain noncompliant. Creating manual incident tickets (option 3) is reactive and doesn't prevent recurrence. The compliance scanner's autoremediation feature detects drift and automatically reapplies policy requirements, eliminating administrative overhead and closing the compliance gap within minutes rather than waiting for manual intervention." |
| 32 | + - content: "The base security policy wasn't properly configured with enforcement mode; update the policy to 'Deny' rather than 'Audit' to prevent future logging changes." |
| 33 | + isCorrect: false |
| 34 | + explanation: "Manual post-deployment changes causing drift is the most common cause, and autoremediation directly addresses it by automatically restoring compliant configurations. Changing policy enforcement mode to 'Deny' (option 2) prevents future violations but doesn't remediate existing drift—the 15 endpoints would remain noncompliant. Creating manual incident tickets (option 3) is reactive and doesn't prevent recurrence. The compliance scanner's autoremediation feature detects drift and automatically reapplies policy requirements, eliminating administrative overhead and closing the compliance gap within minutes rather than waiting for manual intervention." |
| 35 | + - content: "Azure service updates changed default logging behavior; create an incident ticket for developers to manually restore logging on affected endpoints." |
| 36 | + isCorrect: false |
| 37 | + explanation: "Manual post-deployment changes causing drift is the most common cause, and autoremediation directly addresses it by automatically restoring compliant configurations. Changing policy enforcement mode to 'Deny' (option 2) prevents future violations but doesn't remediate existing drift—the 15 endpoints would remain noncompliant. Creating manual incident tickets (option 3) is reactive and doesn't prevent recurrence. The compliance scanner's autoremediation feature detects drift and automatically reapplies policy requirements, eliminating administrative overhead and closing the compliance gap within minutes rather than waiting for manual intervention." |
| 38 | + - content: "Your development teams complain that approval workflows for experimental AI deployments take 2-3 days, slowing innovation velocity. Current policies routes all Azure OpenAI requests greater than $500 monthly cost to VP approval. Development deployments rarely exceed $1,000 monthly and have separate budget allocation from production. How should you optimize governance policies to enable faster development cycles without compromising production controls?" |
| 39 | + choices: |
| 40 | + - content: "Increase the autoapproval threshold to $5,000 for all environments so both development and production teams can provision faster." |
| 41 | + isCorrect: false |
| 42 | + explanation: "Environment-specific approval thresholds balance innovation velocity with production risk management. Development environments need experimentation freedom with appropriate budget guardrails, while production requires stricter governance due to customer impact and compliance requirements. Raising thresholds universally (option 1) weakens production controls where VP oversight is necessary for risk management. Removing workflows entirely (option 2) eliminates governance visibility and creates audit gaps even with budget enforcement. The correct approach uses environment tags to apply different approval rules: development gets auto-approval under $2,000 (covering most experiments), production maintains VP approval, and budget enforcement prevents runaway costs in both environments." |
| 43 | + - content: "Remove approval workflows entirely for development environments and rely on budget enforcement policies to prevent overspending." |
| 44 | + isCorrect: false |
| 45 | + explanation: "Environment-specific approval thresholds balance innovation velocity with production risk management. Development environments need experimentation freedom with appropriate budget guardrails, while production requires stricter governance due to customer impact and compliance requirements. Raising thresholds universally (option 1) weakens production controls where VP oversight is necessary for risk management. Removing workflows entirely (option 2) eliminates governance visibility and creates audit gaps even with budget enforcement. The correct approach uses environment tags to apply different approval rules: development gets auto-approval under $2,000 (covering most experiments), production maintains VP approval, and budget enforcement prevents runaway costs in both environments." |
| 46 | + - content: "Create environment-specific policies where development environments autoapprove requests under $2,000 monthly cost while production maintains VP approval for all deployments." |
| 47 | + isCorrect: true |
| 48 | + explanation: "Environment-specific approval thresholds balance innovation velocity with production risk management. Development environments need experimentation freedom with appropriate budget guardrails, while production requires stricter governance due to customer impact and compliance requirements. Raising thresholds universally (option 1) weakens production controls where VP oversight is necessary for risk management. Removing workflows entirely (option 2) eliminates governance visibility and creates audit gaps even with budget enforcement. The correct approach uses environment tags to apply different approval rules: development gets auto-approval under $2,000 (covering most experiments), production maintains VP approval, and budget enforcement prevents runaway costs in both environments." |
0 commit comments