Secure workspaces and automate with CI/CD

Production ML needs locked-down networks, no shared secrets and repeatable deployments. These topics appear as short scenarios with one clearly best answer.

Network isolation

To keep a workspace off the public internet, create a private endpoint and disable public network access. Compare the options.

Option	What it does
Private endpoint	Private IP for the workspace in your VNet; blocks the public path
Service endpoint	Optimizes the route to a service, but the service keeps a public address
NSG	Filters traffic by IP and port; does not make a PaaS service private
Managed virtual network	Azure Machine Learning creates and manages the network for compute and outbound rules

For Microsoft Foundry the same pattern applies: use a managed virtual network or private endpoints, and disable public network access on the resource, while keeping the platform working. Blocking all inbound access breaks it.

Identity over keys

Prefer managed identities and Microsoft Entra ID over keys and tokens.

• The workspace has a system-assigned identity; compute clusters can use identities to read storage.
• Grant least-privilege Azure RBAC roles, for example AzureML Data Scientist for users.
• Store any unavoidable secret in Azure Key Vault, linked to the workspace.
• For Git, configure repository access through a managed identity rather than shared deploy keys or personal access tokens.

Source control

Notebooks and jobs should live in Git. Compute instances can clone repositories, and repos keep code, YAML job definitions and environment files together. Branch policies and pull requests make changes reviewable.

Infrastructure as code

Declare workspaces, storage, Key Vault, registries and networking in Bicep or Terraform. The same template deploys dev, test and production, so environments stay identical.

# GitHub Actions step: submit a job with the CLI v2
- name: Submit training job
  run: az ml job create --file jobs/train.yml --workspace-name ${{ vars.WS }} --resource-group ${{ vars.RG }}

CI/CD with GitHub Actions

A typical flow:

1. A pull request triggers validation: lint, unit tests, and a small training or evaluation run.
2. Merge to main deploys infrastructure and registers the model.
3. A protected environment requires approval before production.
4. The workflow signs in with a federated credential (OIDC) rather than a stored secret.

Azure Machine Learning pipelines orchestrate ML steps (data prep, training); GitHub Actions orchestrates delivery around them. They complement each other.

Exam traps

• NSGs and service endpoints do not make a workspace private; private endpoints do.
• Azure Machine Learning pipelines are not the approval and pull request tool; GitHub Actions is.
• Azure Monitor observes; it does not deploy.
• Personal access tokens in pipelines are secrets you must rotate; a managed identity is preferred.
• Turning off all inbound access to Foundry breaks functionality; restrict, do not remove.

Practice questions

Choose an answer, then review the explanation to check your understanding.

1. An Azure Machine Learning workspace holds sensitive data and must not be reachable from the public internet. What do you configure?

1. A.Private endpoints
2. B.A network security group only
3. C.Service endpoints
4. D.An Azure Firewall rule allowing all IPs

Show answer

Answer: A.Private endpoints give the workspace a private IP in your virtual network, and you then disable public network access.

2. Developers use a shared Git repository from the workspace, and you want to avoid spreading credentials. What is the best approach?

1. A.Share one deploy key with everyone
2. B.Store a personal access token in each pipeline
3. C.Use a managed identity for repository access
4. D.Make developers sign in before every commit

Show answer

Answer: C.A managed identity centralizes access and removes secrets that people copy around.

3. Deployments to the test workspace must start from pull requests, be auditable and need approval. Which tool fits?

1. A.Azure Monitor
2. B.MLflow
3. C.GitHub Actions with environment protection rules
4. D.A compute instance schedule

Show answer

Answer: C.GitHub Actions workflows run on pull requests, keep a history, and can require reviewers through environments.

4. Infrastructure for workspaces must be declared in code and deployed through pipelines. What do you author?

1. A.Bicep or Terraform templates
2. B.Notebook cells
3. C.Portal screenshots
4. D.Environment tags

Show answer

Answer: A.Bicep (or Terraform) templates define resources declaratively and can be reviewed and deployed repeatedly.