After a Bicep deploy, a city SRE wants CI to confirm the Azure Machine Learning workspace managed identity can reach the registered datastore before training jobs are allowed. What should CI include?
Select an answer to reveal the explanation.
Short Explanation
Deploy isn't done until you jiggle the door handle. An Azure CLI check that the workspace's own managed identity can reach the datastore catches wiring mistakes before overnight jobs fail. Checking that the entry exists, or checking a different identity, isn't the same as proving access works.
Full Explanation
Adding an Azure CLI verification step that confirms the workspace managed identity has datastore access after deploy turns CI into a completion gate, not just a resource factory. After Bicep creates the city Azure Machine Learning workspace and bindings, the pipeline should prove the managed identity can list or read the registered datastore target before training jobs are allowed. Fail-fast permission checks prevent overnight training queues from discovering broken RBAC at 2 a.m.
Adding an Azure CLI step that shows the datastore registration properties to confirm the datastore entry exists in the workspace fails by concept: confirming the entry exists in metadata is not the same as confirming the workspace managed identity can actually read it — existence and access are different checks. Granting the workspace managed identity the AzureML Data Scientist role on the workspace to enable training fails because granting a role is a permission change, not a verification step; the stem asks CI to prove access already works, not to hand out a new workspace-level role as a workaround. Adding an Azure CLI step that validates the pipeline runner service principal can access the datastore storage fails because it checks the wrong identity — the stem specifically needs the workspace managed identity's access confirmed, not the CI runner's service principal.
Exam caveat: Post-deploy validation of managed identity to datastore is a practical IaC skill; over-privileging runners, assuming portal status is enough, checking the wrong identity, or substituting a permission grant for an access check are common wrong answers.
Operational check: after deploy, run az role assignment list / az storage checks (or equivalent) as the workspace identity context, attempt a controlled read of the datastore container, and fail the pipeline if access is denied—then fix RBAC in Bicep rather than widening runner permissions.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.