|
| 1 | +### YamlMime:ModuleUnit |
| 2 | +uid: learn.wwl.implement-identity-based-security-azure-machine-learning.knowledge-check |
| 3 | +title: "Module assessment" |
| 4 | +metadata: |
| 5 | + title: "Knowledge check" |
| 6 | + description: "Knowledge check" |
| 7 | + ms.date: 02/05/2026 |
| 8 | + author: wwlpublish |
| 9 | + ms.author: bradj |
| 10 | + ms.topic: unit |
| 11 | + module_assessment: false |
| 12 | +durationInMinutes: 7 |
| 13 | +content: "Choose the best response for each of the following questions." |
| 14 | +quiz: |
| 15 | + questions: |
| 16 | + - content: "Your data science team includes 15 full-time employees and 8 contractors from a partner firm. The contractors need temporary access to a development Azure Machine Learning workspace for a 3-month project, but they should automatically lose access when the project ends. Security policy prohibits contractors from accessing production workspaces. Which approach best implements these requirements with minimal ongoing administration?" |
| 17 | + choices: |
| 18 | + - content: "Create a security group named Project-Contractors with dynamic membership rules based on employeeType and department attributes, assign it Reader role on the dev workspace only, and set the group's expiration policy to 90 days" |
| 19 | + isCorrect: true |
| 20 | + explanation: "Dynamic group membership with employeeType filtering and automatic expiration provides the required temporary access with zero manual intervention when the project ends. This approach also ensures contractors can't access production by limiting role assignment scope to dev workspace only. The second option requires manual tracking and removal, which introduces operational risk and doesn't prevent production access. The third option uses service principals incorrectly—these are for applications, not human users—and grants excessive permissions (Contributor instead of Reader) while complicating authentication unnecessarily." |
| 21 | + - content: "Add all contractors individually to the existing Data Scientists group with Reader role on both dev and production workspaces, then schedule a calendar reminder to manually remove them after three months" |
| 22 | + isCorrect: false |
| 23 | + explanation: "This option requires manual tracking and removal, which introduces operational risk and doesn't prevent production access." |
| 24 | + - content: "Create service principals for each contractor with certificate-based authentication and Contributor role on all workspaces, storing certificates in Azure Key Vault with 90-day expiration" |
| 25 | + isCorrect: false |
| 26 | + explanation: "This option uses service principals incorrectly—these are for applications, not human users—and grants excessive permissions (Contributor instead of Reader) while complicating authentication unnecessarily." |
| 27 | + - content: "Your security team reports suspicious activity: a data scientist's account authenticated to Azure Machine Learning studio from three different countries/regions within 2 hours, which is physically impossible. The affected user confirms their password hasn't been shared. You need to prevent this type of attack while minimizing impact on legitimate users who travel frequently for conferences. Which Conditional Access policy configuration best addresses this threat?" |
| 28 | + choices: |
| 29 | + - content: "Create a policy requiring compliant device plus MFA for all Azure Machine Learning access from any location, with session sign-in frequency set to 1 hour to force frequent reauthentication" |
| 30 | + isCorrect: false |
| 31 | + explanation: "This option creates excessive friction—hourly reauthentication disrupts long-running training jobs and doesn't specifically address the geographic impossibility threat." |
| 32 | + - content: "Block all Azure Machine Learning access from locations outside your company's home country/region, with no exceptions, and require VPN connectivity for international travelers" |
| 33 | + isCorrect: false |
| 34 | + explanation: "This option completely prevents legitimate international collaboration and conference attendance, contradicting business requirements while creating VPN performance bottlenecks." |
| 35 | + - content: "Implement risk-based sign-in policy that requires MFA for medium and high-risk authentications, combined with Impossible Travel anomaly detection that automatically blocks suspicious sign-ins pending security review" |
| 36 | + isCorrect: true |
| 37 | + explanation: "Risk-based Conditional Access uses Azure's machine learning to detect anomalous sign-in patterns like Impossible Travel (same account from geographically distant locations in short timeframes) and applies controls dynamically. Legitimate users traveling normally complete standard MFA, while suspicious patterns trigger automatic blocks and security team alerts." |
| 38 | + - content: "Your ML engineering team built an automated training pipeline that runs nightly to retrain models with updated data. The pipeline needs to authenticate to Azure Machine Learning, read training data from Azure Data Lake, write models to the model registry, and log metrics to Azure Monitor. The team initially used a service principal with client secret, but your security audit flagged this as noncompliant due to static credential storage in the CI/CD tool. Which authentication approach best meets compliance requirements while maintaining automation reliability?" |
| 39 | + choices: |
| 40 | + - content: "Enable system-assigned managed identity on the Azure Machine Learning compute cluster running the pipeline, then assign it custom RBAC roles with read permissions on Data Lake, write permissions on model registry, and metrics contributor permissions on Monitor workspace" |
| 41 | + isCorrect: true |
| 42 | + explanation: "System-assigned managed identity eliminates credential storage entirely—Azure handles authentication transparently for resources running on that compute cluster. Custom RBAC roles implement least-privilege by granting only the specific permissions each pipeline task requires, reducing attack surface if the identity is compromised." |
| 43 | + - content: "Generate an X.509 certificate for the existing service principal, store it in Azure Key Vault with restrictive access policies, and modify pipeline code to retrieve the certificate at runtime for authentication" |
| 44 | + isCorrect: false |
| 45 | + explanation: "This option improves on client secrets through certificate authentication but still requires credential storage and retrieval code, adding complexity without achieving credential-free authentication available through managed identity." |
| 46 | + - content: "Create user-assigned managed identity with Owner role on the entire Azure subscription to ensure it has permissions for all current and future pipeline requirements" |
| 47 | + isCorrect: false |
| 48 | + explanation: "This option violates least-privilege by granting excessive Owner permissions at subscription scope—the pipeline doesn't need ability to delete resources or modify security settings, and user-assigned identity adds management overhead compared to system-assigned for single-resource scenarios." |
![learn-build-service-prod[bot]](https://avatars.githubusercontent.com/in/237442?v=4&size=40){kind=avatar}
0 commit comments