PCAP Modules and Packages Practice Question
A company has a large Python application that uses multiple packages from different directories. The application's main entry point is at /opt/app/main.py. There is a package 'common' located at /opt/app/common/ and another package 'services' at /opt/app/services/. Both packages have __init__.py files. Additionally, there is a third-party package 'utils' installed in the system site-packages. Recently, a developer added a new module 'helpers.py' to the 'common' package. When trying to import 'common.helpers' from a script inside 'services', an ImportError is raised: 'No module named common.helpers'. However, importing 'common' itself works. The sys.path includes /opt/app/ and the site-packages. What is the most likely cause of the import failure?
⚠ Common exam trap
Python Institute often tests the subtlety that a package can be shadowed by another package with the same name earlier in sys.path, leading to successful import of the parent but failure for submodules that exist only in the intended package.
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
✓
There is another 'common' package elsewhere in sys.path that shadows the intended one, and the shadowed package does not have a 'helpers' submodule.
The most likely cause is that a different 'common' package (without a 'helpers' submodule) appears earlier in sys.path and shadows the intended /opt/app/common/ package. Since sys.path includes /opt/app/ and site-packages, if a 'common' package exists in site-packages or another directory listed before /opt/app/, Python will import that shadowed package instead, and it lacks the newly added 'helpers' module. This explains why importing 'common' succeeds (the shadowed package exists) but 'common.helpers' fails.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The 'helpers.py' file was added after the Python interpreter started, and sys.modules caching prevents new imports.
Why it's wrong here
This is incorrect. sys.modules is a dictionary that caches only modules that have already been imported and loaded into memory during the current interpreter session. It does not act as a barrier to discovering newly added files; when an import statement executes, Python's import system first checks sys.modules only for the exact module name being requested, and if it is absent, it proceeds to search sys.path. Since 'common.helpers' was never imported before, the file added later will be found and loaded normally, so the error cannot stem from caching.
- ✓
There is another 'common' package elsewhere in sys.path that shadows the intended one, and the shadowed package does not have a 'helpers' submodule.
Why this is correct
This is the correct explanation. Python searches the directories and zip files listed in sys.path in order, and for a dotted import like 'common.helpers', it looks for a package (a directory with __init__.py) named 'common' in each path entry. If an earlier sys.path entry contains a different 'common' package that lacks a 'helpers' submodule, Python imports that shadowing package and then attempts to find 'helpers' within it, raising ModuleNotFoundError before ever reaching the intended /opt/app/common/ package. This is a classic path-shadowing bug that causes the real file to be completely ignored.
- ✗
The PYTHONPATH environment variable is not set, so the /opt/app/ directory is not searched.
Why it's wrong here
This is incorrect. PYTHONPATH is merely one of several mechanisms that populate sys.path; the interpreter also includes the script's directory, the standard library, and any site-packages directories, and it can be modified at runtime. The scenario explicitly states that sys.path includes /opt/app/, so that directory is definitely searched regardless of whether PYTHONPATH is set. The absence of PYTHONPATH only means no extra directories were added through that environment variable, but it does not exclude /opt/app/ from the module search path.
- ✗
The 'common' package itself is already imported and cached, so adding a new module does not become visible.
Why it's wrong here
This is incorrect. When a package is imported, its module object in sys.modules carries a __path__ attribute, which is a list of directories where the package's submodules are searched. Adding a new file to one of those directories makes it visible to subsequent imports because Python re-examines the package's __path__ each time a submodule import is attempted; the cached package object does not freeze the set of available submodules. The only way a cached package would hide a new module is if the specific submodule itself was already imported, but here 'common.helpers' was never imported, so it can be newly loaded.
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.