AZ-400 Question 108
Single answerYou are leading an effort to implement a versioning strategy for a Docker image built in an Azure DevOps pipeline. The pipeline must produce artifacts that clearly identify both the current release (major, minor, patch) and the relevant build or commit information. The artifacts are then deployed to multiple environments (Development, Staging, and Production). Which versioning approach should you implement to ensure consistent and traceable artifact versions throughout your deployment process?
- A
Use a hand-maintained version.txt file that the DevOps team manually increments after every release
- B
Adopt semantic versioning (major.minor.patch) and append a unique identifier such as the build ID or commit hash
- C
Include only the timestamp of the build in the version to ensure chronological ordering of artifacts
- D
Generate random version strings per build to maximize unpredictability and avoid conflicts
Show answer and explanation
Correct answer: B
Explanation
Using semantic versioning with a major.minor.patch format, combined with a build or commit identifier, is considered a proven best practice in artifact versioning. It ensures that each artifact version is both meaningful (showing which changes are included) and traceable (mapping directly back to a specific commit). For more details, refer to Microsoft� documentation on versioning strategies and best practices for DevOps pipelines.
- A. Incorrect.
Option 1: This is incorrect because manually maintaining version information can lead to errors and inconsistencies across different teams and environments. It also makes it harder to automate and scale the versioning strategy.
- B. Correct.
Option 2: This is correct. Semantic versioning (major.minor.patch) provides consistent and clear version increments, while appending a unique build ID or commit hash ensures traceability to the specific source code and build, aligning with recommended DevOps best practices.
- C. Incorrect.
Option 3: This is incorrect because while timestamps can help track the build date, they do not provide clear information about backward compatibility, patch levels, or source code references. Timestamp-only formats often fail to convey enough detail for troubleshooting or rollback scenarios.
- D. Incorrect.
Option 4: This is incorrect because random version strings offer no meaningful indication of release stability, fixes included, or source-code relationships. It also complicates debugging and deployment processes.