A company's CI pipeline builds a Java application and produces a JAR file. The deployment pipeline needs to reliably retrieve the exact same JAR file that was built and tested in CI, even if a new build is triggered later. What is the best practice for managing this artifact?

Copy the JAR file to a shared network drive

Rebuild the JAR file from source code in the deployment pipeline

Attach the JAR file to the commit in the version control system

Store the JAR file in a dedicated artifact repository with a unique version identifier

How does a CI/CD pipeline typically detect that new code has been pushed to a version control repository?

By polling the repository at regular intervals for changes

By receiving a webhook notification from the version control system

By scanning the filesystem of the CI server for new files

By manually triggering the pipeline after each commit

A team is currently developing a feature in a long-lived feature branch. They integrate their changes into the main branch only once every few weeks. This has led to frequent merge conflicts and delayed detection of integration issues. Which practice would best address these problems?

Keep the feature branch isolated and merge it only when the feature is completely finished

Integrate code changes into the main branch multiple times a day

Have a single developer integrate all changes at the end of the project

Use a code review tool to manually check for conflicts before merging

A team is adding automated tests to their CI pipeline. They want to run fast unit tests on every commit to provide quick feedback to developers. They also want to run slower integration and end-to-end tests, but only after the unit tests pass and the application is packaged. How should the pipeline be structured?

Run integration and end-to-end tests first, and run unit tests only if the integration tests pass

Run unit tests only in the CI pipeline and run integration and end-to-end tests manually after deployment

Run unit tests in an early stage, and run integration and end-to-end tests in a later stage after the build and packaging

Run all tests (unit, integration, and end-to-end) in a single stage at the beginning of the pipeline

A team is using a CI tool that is not integrated with their version control system. Currently, developers must manually trigger a build after pushing their code. They want to automate this process so that builds are triggered automatically when code is pushed. What is the first step they should take?

Manually copy the code to the CI server after each push

Create a new branch in the version control system for each build

Configure a webhook in the version control system to notify the CI tool of push events

Ask developers to run the build locally before pushing

LPI DevOps Tools Engineer

Domain 1Objective 4

701.4 Continuous Integration and Continuous Delivery (weight: 3) DEVOPS-TOOLS-ENGINEER Practice Questions (Page 2)

Part of the 701 Software Engineering domain, which makes up ~34% of our current practice bank. Linux Professional Institute does not publish an official question count, but from its 90-minute exam (~35–60 total, ~12–20 in this domain), expect 2–4 from this objective — we provide 28 practice questions to prepare you well beyond it. (estimate)

28questions here

6free pages

12concepts

Questions 6–10

6application · medium
A company's CI pipeline builds a Java application and produces a JAR file. The deployment pipeline needs to reliably retrieve the exact same JAR file that was built and tested in CI, even if a new build is triggered later. What is the best practice for managing this artifact?
Select an answer first
7foundation · easy
How does a CI/CD pipeline typically detect that new code has been pushed to a version control repository?
Select an answer first
8application · medium
A team is currently developing a feature in a long-lived feature branch. They integrate their changes into the main branch only once every few weeks. This has led to frequent merge conflicts and delayed detection of integration issues. Which practice would best address these problems?
Select an answer first
9application · medium
A team is adding automated tests to their CI pipeline. They want to run fast unit tests on every commit to provide quick feedback to developers. They also want to run slower integration and end-to-end tests, but only after the unit tests pass and the application is packaged. How should the pipeline be structured?
Select an answer first
10application · medium
A team is using a CI tool that is not integrated with their version control system. Currently, developers must manually trigger a build after pushing their code. They want to automate this process so that builds are triggered automatically when code is pushed. What is the first step they should take?
Select an answer first

Finished these 5 questions?

Review the revealed explanations, or continue through the curriculum.

Next 5 questions →Back to DEVOPS-TOOLS-ENGINEER

Free Basic Practice is a study aid with revealable answers — not a scored exam. Examers.io is independent and not affiliated with or endorsed by Linux Professional Institute. “DEVOPS-TOOLS-ENGINEER” is a trademark of its owner, used for identification only.

701.4 Continuous Integration and Continuous Delivery (weight: 3) DEVOPS-TOOLS-ENGINEER Practice Questions (Page 2)

Questions 6–10

A company's CI pipeline builds a Java application and produces a JAR file. The deployment pipeline needs to reliably retrieve the exact same JAR file that was built and tested in CI, even if a new build is triggered later. What is the best practice for managing this artifact?

How does a CI/CD pipeline typically detect that new code has been pushed to a version control repository?

A team is currently developing a feature in a long-lived feature branch. They integrate their changes into the main branch only once every few weeks. This has led to frequent merge conflicts and delayed detection of integration issues. Which practice would best address these problems?

Keep studying — 701 Software Engineering