After Lab 3.1 — Recap
After Lab 3.1 — Recap
You explored Azure DevOps pipeline structure and understood the flow from commit to deployment.
What You Should Understand
Service Connection vs. Managed Identity
| Identity Type | Used For | Scope | Example |
|---|---|---|---|
| Service Connection | Deploying infrastructure, publishing artifacts, running scans | Build/deployment time only | Service connection with Contributor role on resource group |
| Managed Identity | Backend accessing Key Vault, querying database, calling Azure APIs | Runtime (production workload) | Managed identity with Key Vault Secret User role |
Critical distinction: The identity that deploys your app (pipeline) should not be the same as the identity your app uses at runtime. Separate concerns, minimize blast radius.
Build-Once-Promote-Many
Building once ensures dev, test, and prod deploy identical code. Rebuilding per environment risks dependency drift and makes traceability impossible.
Reflection Questions
What happens if the pipeline service connection has Owner role on the entire subscription?
Risk: Pipeline can modify any resource in the subscription (delete production databases, change networking, access secrets). If the pipeline is compromised (malicious PR, credential leak), the attacker has subscription-wide access.
Better approach: Scope service connection to specific resource groups (dev, test, prod) with least-privilege roles (Contributor for deployment, no Owner/User Access Administrator).
Why does the pipeline have 3 stages (Validate, Build, DeployDev) instead of combining them?
Separation of concerns:
- Validate: Fast quality/security checks (minutes) — fail early before wasting time on build
- Build: Compile/package once, publish artifact
- DeployDev: Automated deployment for rapid feedback
Combining stages means a type error (caught in seconds) delays deployment feedback by the full build+deploy time.
What traceability information is embedded in the published artifact?
The artifact includes metadata files:
BUILD_VERSION: Pipeline build IDBUILD_COMMIT: Git commit SHABUILD_NUMBER: Semantic version or build number
This proves which commit, build, and tests produced the deployed artifact. Critical for rollback, compliance audits, and incident investigation.
Common Issues
| Issue | Symptom | Cause | Fix |
|---|---|---|---|
| Service connection auth fails | Error: AADSTS700016 | Service principal expired or deleted | Renew service connection in Azure DevOps project settings |
| Artifact not found in deployment | DownloadPipelineArtifact failed | Build stage did not publish, or wrong artifact name | Verify PublishPipelineArtifact ran in Build stage, check artifact name matches |
| Pipeline triggers on every commit | Too many builds for feature branches | No branch filter in trigger: | Add branches: include: [main, develop] to limit triggers |