Using Docker Compose to Provide a Database for Maven Integration Tests
Your team is designing a build pipeline for a Java application that uses Maven. The pipeline must run unit tests and integration tests separately, and fail the build if integration tests fail. However, integration tests require a running database container. Which approach should you use to ensure the database is available for the integration tests?
Quick Answer
A Docker Compose task that spins up the database container before the integration test step runs is the clean way to satisfy this dependency — it declaratively starts an isolated, disposable database instance the tests can connect to, and the pipeline can still fail the build normally if the integration tests themselves fail.
⚠ Common exam trap
A common mix-up: candidates confuse the Docker Compose task with other Azure DevOps tasks like Service Fabric or generic scripting, failing to recognize that Docker Compose is the standard, built-in method for managing container dependencies in a pipeline.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use a Docker Compose task in the pipeline to start the database container before running integration tests.
Docker Compose allows you to define and start a database container as a dependency before running integration tests in a build pipeline. By using a Docker Compose task, you can ensure the database container is running in a clean, isolated environment, and the pipeline can fail the build if the integration tests fail. This approach is ideal for CI/CD pipelines where ephemeral, disposable infrastructure is needed for testing.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use a Docker Compose task in the pipeline to start the database container before running integration tests.
Why this is correct
Docker Compose provides a declarative way to run dependent services as containers.
- ✗
Configure the pipeline to use a self-hosted agent that has the database already installed and running.
Why it's wrong here
Self-hosted agents require maintenance and reduce scalability.
- ✗
Install the database as a service in the pipeline using the Service Fabric task.
Why it's wrong here
Service Fabric is a microservices platform, not for database provisioning in builds.
- ✗
Use a PowerShell script in the pipeline to install and start the database on the build agent.
Why it's wrong here
Manual installation is unreliable and not portable.
Go deeper
Related to this question
Learn chapter
Designing a Build Pipeline
Key term
Build pipeline
A build pipeline is an automated sequence of steps that compiles source code into a deployable artifact, running tests and checks along the way.
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are responsible for managing build pipelines in Azure DevOps for a large .NET solution that consists of multiple projects. The build takes approximately 45 minutes, which is too long. The solution has unit tests and integration tests. The integration tests require a database that is provisioned during the build. You need to reduce the build time while maintaining code quality. What should you do?
medium- ✓ A.Enable incremental build by using the 'Build' task's 'Clean' option set to false, and separate unit and integration tests into different stages.
- B.Remove integration tests from the build pipeline and run them only in the release pipeline.
- C.Increase the number of parallel jobs and use a multi-agent job to build projects in parallel.
- D.Disable the 'Test' step in the build pipeline and rely on a separate test pipeline.
Why A: A is correct: Setting Clean to false enables incremental builds by preserving previous outputs and only rebuilding changed projects, which reduces build time. Separating unit and integration tests into different stages allows unit tests to run first, providing faster feedback and allowing integration tests to be skipped if unit tests fail, thus saving time while still maintaining overall code quality. B is not the best choice because moving integration tests to the release pipeline delays detection of integration issues, but it does not reduce code quality; however, it is less effective for early feedback. C can help if projects are independent, but it does not address the likely compile-time overhead of unchanged projects and may not solve the database-dependent test bottleneck. D is not ideal because moving tests out of the build pipeline means the build no longer validates test results, creating a gap in quality gating (even if another pipeline exists).
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.