Study guide
12.3 Version Control for Prompts with Git
Microsoft AI-300: Operationalizing Machine Learning and Generative AI Solutions Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Skills Measured, Format, and How This Guide Is Organized 1.3 Candidate Profile, Azure ML v2, Foundry, and DevOps Tooling
2 Chapter 2: Azure Machine Learning Workspaces, Datastores, Compute, and IAM
2.1 Create and Manage Azure Machine Learning Workspaces 2.2 Create and Manage Datastores 2.3 Create and Manage Compute Targets 2.4 Configure Identity and Access Management for Workspaces
3 Chapter 3: Azure Machine Learning Data Assets, Environments, Components, and Registries
3.1 Create and Manage Data Assets 3.2 Create and Manage Environments 3.3 Create and Manage Components 3.4 Share Assets Across Workspaces with Registries
4 Chapter 4: Infrastructure as Code, GitHub, and Network Isolation for Azure ML
4.1 GitHub Integration and Git Source Control for Machine Learning Projects 4.2 Deploy Workspaces and Resources with Bicep and Azure CLI 4.3 Automate Resource Provisioning with GitHub Actions 4.4 Restrict Network Access to Machine Learning Workspaces
5 Chapter 5: MLflow Tracking, AutoML, Training Jobs, and Hyperparameter Sweeps
5.1 Configure Experiment Tracking with MLflow 5.2 Use Automated Machine Learning to Explore Optimal Models 5.3 Notebooks, Command Jobs, and Training Scripts 5.4 Automate Hyperparameter Tuning
6 Chapter 6: Distributed Training, Training Pipelines, and Job Comparison
6.1 Manage Distributed Training for Large and Deep Learning Models 6.2 Implement Training Pipelines 6.3 Compare Model Performance Across Jobs
7 Chapter 7: Model Registration, Responsible AI, and Lifecycle Management
7.1 Register MLflow Models and Package Feature Retrieval Specs 7.2 Evaluate Models with Responsible AI Principles 7.3 Manage Model Lifecycle and Archiving
8 Chapter 8: Online Endpoints, Batch Endpoints, Rollout, and Rollback
8.1 Deploy Models to Managed Online Endpoints 8.2 Deploy Models to Batch Endpoints 8.3 Test, Troubleshoot, Progressive Rollout, and Safe Rollback
9 Chapter 9: Data Drift, Production Metrics, Retraining, and Alerts
9.1 Detect and Analyze Data Drift 9.2 Monitor Production Metrics and Trigger Retraining or Alerts
10 Chapter 10: Microsoft Foundry Resources, IAM, Networking, and IaC
10.1 Create and Configure Foundry Resources and Project Environments 10.2 Managed Identities and RBAC for Foundry 10.3 Foundry Network Security and Private Networking 10.4 Deploy Foundry Infrastructure with Bicep and Azure CLI
11 Chapter 11: Deploying and Managing Foundation Models
11.1 Serverless API Endpoints and Managed Compute for Foundation Models 11.2 Select Foundation Models for Specific Use Cases 11.3 Model Versioning and Production Deployment Strategies 11.4 Provisioned Throughput Units for High-Volume Workloads
12 Chapter 12: Prompt Design, Variants, and Git Version Control
12.1 Design and Develop Prompts 12.2 Create Prompt Variants and Compare Performance 12.3 Version Control for Prompts with Git
13 Chapter 13: Evaluation Datasets, Quality Metrics, Safety, and Automated Workflows
13.1 Test Datasets and Data Mapping for Evaluation 13.2 Groundedness, Relevance, Coherence, and Fluency 13.3 Risk and Safety Evaluations 13.4 Built-in and Custom Automated Evaluation Workflows
14 Chapter 14: Continuous Monitoring, Performance, Cost, Tracing, and Logging
14.1 Continuous Monitoring in Microsoft Foundry 14.2 Latency, Throughput, Token Use, and Cost Metrics 14.3 Logging, Distributed Tracing, and Production Debugging
15 Chapter 15: Retrieval Tuning, Embeddings, Hybrid Search, and RAG Evaluation
15.1 Tune Similarity Thresholds, Chunk Sizes, and Retrieval Strategies 15.2 Select and Fine-Tune Embedding Models 15.3 Hybrid Search: Semantic and Keyword Retrieval 15.4 RAG Relevance Metrics and A/B Testing
16 Chapter 16: Fine-Tuning Methods, Synthetic Data, and Promotion to Production
16.1 Advanced Fine-Tuning Methods (LoRA, QLoRA, Full) 16.2 Create and Manage Synthetic Data for Fine-Tuning 16.3 Monitor, Optimize, and Promote Fine-Tuned Models
12.3 Version Control for Prompts with Git
Key Takeaways Explain This Topic AI
Treat prompts as code. Store Foundry instruction files, prompt-flow flow.dag.yaml, Jinja2 templates, eval datasets, and deployment scripts in GitHub (or Azure Repos) beside the application. Foundry assigns incremental agent versions; align them with Git tags such as v1, v2.
Microsoft’s GenAIOps-with-GitHub template uses a pull request from a feature branch to development that runs build validation and experimentation/evaluation flows before merge. After merge, CI registers the flow and CD can deploy an endpoint. Do the same for agent create_version.
Never commit API keys, connection secrets, or .env files. Use GitHub Actions secrets, a service principal or federated identity to Azure, and workspace connections (for example aoai) that live outside the repo. .gitignore the secret files.
Code review is required for prompt changes: wording, safety, schema, and eval deltas belong on the pull request. Portal-only edits with no commit cause environment drift and make rollback a reconstruction exercise.
Connect GitHub to Azure Machine Learning / Microsoft Foundry so clones, Actions, and SDK submits share one history. Tag releases, keep main (or a protected release branch) as production, and run evaluators on changed prompts in CI before anyone clicks Deploy in the portal.
Last updated: October 2026
Version Control for Prompts with Git
Quick Answer: Prompts and flow.dag.yaml live in the same GitHub repository as the app. Pull requests run evaluators . Tags mark the commit that matches a Foundry agent version . Never commit API keys. The exam trap is editing instructions only in the portal with no commit.
The third Domain 3 bullet is implement version control for prompts by using Git repositories . Microsoft Learn’s module Manage prompts for agents in Microsoft Foundry with GitHub is the skill in course form: prompts are production configuration; they take effect immediately; they need the same DevOps treatment as application code.
Why Git, not the portal, is the source of truth
Microsoft’s version-control unit lists what fails without Git: silent degradation (a “harmless” wording change drops accuracy and nobody can diff it), environment drift (dev works, production has a different playground paste), crisis recovery (you cannot restore what was never committed), and lost knowledge (someone deletes a “redundant” safety sentence that was load-bearing). The fix is the same table you already use for Azure Machine Learning jobs in Chapter 4: source control, reviews, environment separation, rollback.
Prompt flow (retiring April 20, 2027) is already files. Each existing flow folder contains:
- flow.dag.yaml — inputs, outputs, nodes, tools, variants
- .jinja2 / .py — prompt templates and Python tools
- data files for local test
Azure Machine Learning stores a copy under Users/<username>/promptflow on the workspace file share. That share is not Git. Download the folder (or clone a repo onto the compute instance) and check it in . The VS Code Prompt flow extension and pf / pfazure CLI let you author locally, then pfazure run create submits cloud runs from the clone. Foundry agents follow the same idea with a shallower tree: a deployment script plus prompts/vN_instructions.txt .
Microsoft’s recommended layout (adapted for a claims agent) looks like this:
- src/agents/claims_triage/claims_triage.py — reads the instruction file, calls create_version()
- src/agents/claims_triage/prompts/v1_instructions.txt (and v2_ , v3_ )
- tests/test_claims_triage.py plus an eval dataset
- infra/main.bicep — Foundry/AML resources from Chapter 10
- .github/workflows/eval-prompts.yml — CI
- .env and connection secrets — not committed ; listed in .gitignore
Path What Git tracks What Git must not track
src/agents/<name>/prompts/*.txt System/developer instructions and versioned copies Secrets, member data, API keys
- flow.dag.yaml + .jinja2 Graph, variants, template text Connection keys; use workspace aoai
- .github/workflows/*.yml Eval-on-PR and deploy pipelines Client secrets; use Actions secrets or OIDC
- infra/main.bicep Foundry / Azure Machine Learning resources Subscription-wide admin credentials
File format: .txt or .md for agent instructions (SDK examples read text files), YAML/JSON for metadata, Jinja2 for prompt-flow templates. Name prompt files with incremental versions ( v1_instructions.txt ) so they line up with Foundry’s agent:1 style versions. Use Git tags ( v1 , v2 ) on the commit that deployed that agent version.
Connect GitHub and run CI evaluation on the pull request
Connect GitHub the same way you did for Azure Machine Learning projects: clone with SSH, a scoped PAT, or a GitHub App ; store credentials in Key Vault or Actions secrets; do not paste tokens into YAML. Microsoft’s GenAIOps-with-prompt-flow-and-GitHub guide adds the automation contract:
Create a service principal (or federated OpenID Connect identity) so GitHub Actions can sign in to Azure.
Store the credential as a GitHub secret. Workflows read the secret; the repo does not.
Use two branches such as development and main (the template uses main and development ) with branch policies .
Open a pull request from a feature branch. The PR pipeline runs build validation and experimentation / evaluation flows ( pfazure run create plus an evaluation run, or Foundry evaluation APIs).
Merge only if evaluators meet the gate (for example groundedness mean ≥ 4.0 and safety pass rate at your threshold).
After merge, CI may register the flow in the Azure Machine Learning registry; CD may deploy an online endpoint and run a smoke test. For agents, CI calls create_version() into a dev project; a release workflow promotes the tagged version to production.
Hosted Foundry agents can also use azd pipeline config to generate .github/workflows/azure-dev.yml , a service principal, and repository variables. The exam skill is the pattern: PR → eval → approve → tag → deploy , not a particular YAML filename.
Branch names Microsoft’s prompt-workflow unit suggests: feature/improve-customer-greeting , hotfix/fix-greeting-error , experiment/tone-variations . Lifecycle stages: development → validation → review → production → monitoring . Do not skip validation to “save time.”
Never store API keys in flow.dag.yaml , Jinja2, instruction files, or committed run.yml . Prompt-flow connections (the sample name aoai ) live in the workspace. Local .env is for laptops and is gitignored. GitHub Actions uses AZURE_OPENAI_API_KEY or, better, Microsoft Entra ID with DefaultAzureCredential so there is no long-lived key at all.
Code review for a prompt PR is not optional rubber-stamping. Reviewers check: one-factor change, eval report attached, safety sentences still present, no secrets, temperature documented in config not only in chat. Microsoft calls out that prompt changes need team approval because a one-word edit is live behavior.
Exam scenario
A support lead edits the production Foundry agent in the portal to “sound more casual.” Call-center groundedness falls the next morning and nobody can diff the instruction text. You revert by deploying the last Git tag v3 with create_version() from v3_instructions.txt , then you lock portal edits: production instructions deploy only from main after CI evaluation. You add a workflow that, on PRs touching src/agents/**/prompts/** , runs the quality evaluators from Chapter 13 on the changed files. That is version control for prompts.
Common trap
The trap the exam wants: editing prompts only in the portal (or Studio Files) with no commit . You cannot code-review a playground paste, you cannot tag it, and you cannot prove which wording served traffic. A sibling trap is committing aoai API keys in .env . A third is merging prompt PRs without an evaluation job because “it’s just copy.” A fourth is tagging v4 in Git while production still runs an untagged portal version 7 — tags must match the agent version you actually created from that commit.
Prompts are code. Git, PRs, CI evaluators, and tags are how Domain 3 expects you to manage them. Domain 4 then deepens the evaluators your CI already calls.