Module 10 of 11
Design ALM process for AI-powered business solutions
Move agents, connectors, data, and models through environments safely, repeatably, and auditably.
Exam questions Q91–Q100 9 units on Learn
Open module 10 on Microsoft Learn ↗ Watch the episode (42 min)
Why this module matters
Classic Power Platform ALM applies to agents, with additions. Alongside solutions and environment variables you must now version prompts, instructions, knowledge configuration, and evaluation datasets — because those determine behaviour as much as any code.
Expect questions on managed versus unmanaged solutions, environment strategy, secret handling, and safe rollout.
The one big ideaIf a change can alter agent behaviour, it belongs in source control and must travel through the same governed pipeline as code. That includes prompts and knowledge configuration.
What Microsoft Learn covers
Units in this module, as published on Microsoft Learn:
- Introduction
- Design an ALM process for data used in AI models and agents
- Design an ALM process for Copilot Studio agents, connectors, and actions
- Design ALM processes for Microsoft Foundry agents
- Design an ALM process for custom AI models
- Design an ALM process for AI in Dynamics 365 Finance and Supply Chain
- Design ALM processes for AI in Dynamics 365 apps
- Module assessment
- Summary
Watch this module
Microsoft Learn publishes a free video course for AB-100 on YouTube. This module is covered by one 42 min episode. An instructor walking through the module is often faster than reading it twice.
Key concepts and definitions
| Environment strategy | Separate development, test, and production environments with controlled promotion between them. |
| Managed solution | The production deployment format. Prevents uncontrolled in-place editing and supports clean upgrade and uninstall semantics. |
| Unmanaged solution | The development format, where components are authored and edited. |
| Environment variable | Parameterises environment-specific values — URLs, IDs, settings — so one solution artifact deploys everywhere unchanged. |
| Azure Key Vault | Where secrets and API keys belong, referenced securely by connections and environment variables. Never stored in the solution or in instructions. |
| Source control scope | Solution and agent definitions, prompts and instructions, configuration, evaluation datasets, and pipeline definitions. |
| Deployment pipeline | Automated, auditable promotion with consistent configuration and approval steps. |
| Progressive rollout | Ring-based or canary release with monitoring and predefined rollback criteria, to limit blast radius. |
| Rollback plan | Versioned releases plus the documented ability to restore the previously published version. |
| Maker governance | Governed maker environments, published standards, and a promotion path with review gates — enabling citizen developers without giving them production. |
| Data ALM | Lifecycle management of the datasets, knowledge sources, and prompts that ground models and agents. |
Design guidance
Promotion mechanics
- Package the agent in a solution and deploy it through the pipeline. Never rebuild it by hand in each environment.
- Deploy managed solutions to production so nobody can edit components in place.
- Parameterise every environment-specific value with environment variables so the artifact is identical across environments.
- Keep secrets in Key Vault; a secret in a solution or a prompt is a finding, not a shortcut.
Release safety
- Use progressive rollout — rings or canary — with monitoring and predefined rollback criteria for significant changes.
- Maintain versioned releases so the previous published version can be restored, with rollback steps documented and rehearsed.
- Never edit production directly, even to fix something quickly. That is how drift and untraceable behaviour begin.
Including makers
- Give makers governed environments and clear standards, plus a promotion path with review gates.
- Do not grant production access to makers, and do not block makers entirely — both extremes are wrong answers.
- Apply the same discipline to data and prompts as to components: versioned, owned, reviewed.
Good practice vs. anti-pattern
Do
- Separate dev, test, and production environments.
- Ship managed solutions to production.
- Store secrets in Key Vault only.
- Roll out progressively with defined rollback criteria.
Avoid
- Recreate agents manually per environment.
- Hardcode URLs and IDs into the solution.
- Edit production components in place.
- Big-bang release a major change to everyone.
Exam traps to watch for
TrapProduction takes managed solutions. The reason is preventing uncontrolled in-place edits and enabling clean upgrade/uninstall — not import speed or cost.
TrapEnvironment variables parameterise configuration. They are not for secrets, not for naming agents, and not for storing conversation history.
TrapSource control covers prompts, instructions, knowledge configuration, and evaluation datasets — not just code.
TrapThe correct maker posture is governed enablement: neither production access for all, nor an outright block.
Readiness checklist
You are ready to move on when you can do all of these without notes.
- Describe the standard environment topology and promotion path.
- Explain why production uses managed solutions.
- List everything that belongs in source control for an agent solution.
- Say where secrets live and how they are referenced.
- Outline a progressive rollout with rollback criteria.