A company keeps its web frontend, API and background worker in one repository. A change to the frontend should not trigger expensive builds of the worker. Which setup addresses this?
Show answer and explanation
Answer: C
A monorepo keeps related code together, and folder boundaries make ownership clear. Path filters in Azure Pipelines let a pipeline start only when files under a chosen folder change, so a frontend edit does not rebuild the worker. Combined, these give shared visibility while keeping CI efficient. An unstructured root is hard to maintain, submodules add version-pinning overhead for code that already lives together, and splitting into separate projects loses the shared-code benefit of a monorepo.
Why the other options are wrong
- A. Dumping everything into one flat folder makes it impossible to see which files belong to which component, so path-based triggers have nothing meaningful to match.
- B. Submodules keep separate pinned histories that must be updated manually in each consumer, which adds friction without solving the wasteful rebuild problem.
- D. Separate projects with no shared code avoid the monorepo entirely and cannot share libraries, so they fail the stated goal of keeping related components together.