PCAP Modules and Packages Practice Question
You are a DevOps engineer managing a Python application that consists of multiple microservices. One microservice, 'data_processor', imports a shared library 'common_lib' which is also used by other microservices. The shared library is developed in a separate repository and is installed via pip in each microservice's virtual environment as an editable package (pip install -e). Recently, you updated 'common_lib' with new functions, but when you redeploy 'data_processor' (by restarting the container), the new functions are not available; the old version is still used. The container uses a Docker image built from a requirements file that specifies 'common_lib' from a Git repository. You verify that the Git commit hash in the requirements file points to the latest version. What is the most likely cause and what is the correct course of action?
⚠ Common exam trap
Python Institute often tests the misconception that restarting a container or redeploying without rebuilding the image will pick up changes from a Git-based pip dependency, when in fact the package is frozen in the image layer until the image is rebuilt with a fresh pip install.
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
✓
Update the commit hash or use a version tag that points to the latest, and rebuild the Docker image without using cache (--no-cache).
When a Docker image is built, pip installs the package from the Git repository at the commit hash specified in the requirements file. Even if the requirements file points to the latest commit, Docker's layer caching may reuse a previously built layer that contains the old version of the package. Rebuilding the image with --no-cache forces Docker to re-execute the pip install step, fetching the latest code from Git and installing the updated common_lib. Simply restarting the container does not rebuild the image, so the old installed package persists.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add the common_lib source directory to sys.path in the microservice code.
Why it's wrong here
Adding common_lib's source directory to sys.path in the microservice code would only shadow the installed package if that directory exists inside the container, which is not guaranteed in a deployed image. Even if it worked, it is a brittle runtime hack that bypasses pip's dependency management and does not update the actual installed distribution, leaving the root cause of the stale version unaddressed.
- ✗
Rename the package in the requirements file to force a fresh install.
Why it's wrong here
Renaming the package in requirements.txt would make pip treat it as a brand-new distribution, so it would install a separate package under the new name while leaving the original common_lib untouched. This does not force an upgrade of the existing package; it creates a confusing fork, risks breaking import statements that still reference the original name, and obscures the real issue of an outdated pinned version or cached build.
- ✓
Update the commit hash or use a version tag that points to the latest, and rebuild the Docker image without using cache (--no-cache).
Why this is correct
Updating the commit hash or version tag in the dependency specification to point to the latest release, then rebuilding the Docker image with --no-cache, directly forces pip to fetch the newer revision instead of reusing cached layers. The --no-cache flag prevents Docker from reusing the old RUN pip install layer, ensuring the build environment is fresh and that the upgraded common_lib is actually installed into the image.
- ✗
Change the Python interpreter to a different version.
Why it's wrong here
Switching the Python interpreter version is irrelevant because the microservice's problem is that common_lib is an outdated installed version, not that the runtime is incompatible. A different interpreter would have its own site-packages but would still resolve the same stale version from the Docker build cache or pinned requirements, and it could introduce unrelated compatibility regressions in the microservice's dependencies.
Go deeper
Related to this question
About these practice questions
This PCAP question is part of Courseiva's 169-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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCAP practice question is part of Courseiva's free Python Institute 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 PCAP exam.