How should I use these Scenario practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Scenario questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Scenario domain.

PCAP · topic practice

Scenario practice questions

Practise Certified Associate Python Programmer PCAP Scenario practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

6 questionsDomain: Scenario

Practice 10 questions Browse domain →

What the exam tests

What to know about Scenario

Scenario questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Scenario exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Scenario questions

6 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Read the full Scenario explanation →

A developer creates a package 'mypackage' with the following structure:

mypackage/ __init__.py module1.py module2.py

The __init__.py contains:

from mypackage.module1 import func1
from mypackage.module2 import func2

__all__ = ['func1', 'func2']

In a separate script, the developer writes:

from mypackage import *
print(func1())

This works as expected. However, when the developer runs the same script from a different directory (not the one containing mypackage), the import works but the script prints an error that func1 is not defined. What could be the problem?

Trap 1: The current working directory is not in sys.path, so the package…

If the current working directory were missing from `sys.path`, the initial `import mypackage` would raise `ModuleNotFoundError` before any attribute access could be attempted. The fact that the import succeeds proves the package directory itself is locatable, so the symptom of the missing function must arise from something happening (or not happening) during package initialization. Therefore the working directory cannot be the cause.

Trap 2: The __all__ variable hides func1 because it does not include it,…

`__all__` in `mypackage/__init__.py` governs only the behavior of `from mypackage import *`, not ordinary attribute access via `mypackage.func1`. Even if `func1` were omitted from `__all__`, it would not be hidden — the module-level name simply would not be re-exported by a star import. Moreover, the actual `__all__` shown includes `func1` and `func2`, so this option is factually wrong as well.

Trap 3: The imports in __init__.py are relative imports and fail when run…

The statements in the intended `__init__.py` are absolute imports — they begin with the fully qualified package name (`mypackage.func1`), not with a dot. Absolute imports resolve against `sys.path` and the package's absolute name, so they are unaffected by the current working directory. A relative import like `from .func1 import func1` is required for the failure mode described, but that is not what the code contains.

Study all Scenario common traps →

A
The current working directory is not in sys.path, so the package cannot be found.
Why wrong: If the current working directory were missing from `sys.path`, the initial `import mypackage` would raise `ModuleNotFoundError` before any attribute access could be attempted. The fact that the import succeeds proves the package directory itself is locatable, so the symptom of the missing function must arise from something happening (or not happening) during package initialization. Therefore the working directory cannot be the cause.
B
The __all__ variable hides func1 because it does not include it, but it does.
Why wrong: `__all__` in `mypackage/__init__.py` governs only the behavior of `from mypackage import *`, not ordinary attribute access via `mypackage.func1`. Even if `func1` were omitted from `__all__`, it would not be hidden — the module-level name simply would not be re-exported by a star import. Moreover, the actual `__all__` shown includes `func1` and `func2`, so this option is factually wrong as well.
C
The mypackage directory lacks proper __init__.py (maybe it is not present or invalid), causing it to be treated as a namespace package, and the __init__.py is never executed.
For a directory to be a regular package, Python requires a valid `__init__.py`; when that file is missing, Python 3.3+ treats the directory as a namespace package. A namespace package executes no initialization code, so the `from mypackage.func1 import func1` lines that would normally populate the package namespace never run. The package is still importable, but it appears empty — exactly matching the failure to find `func1` while `import mypackage` succeeds.
D
The imports in __init__.py are relative imports and fail when run from a different directory.
Why wrong: The statements in the intended `__init__.py` are absolute imports — they begin with the fully qualified package name (`mypackage.func1`), not with a dot. Absolute imports resolve against `sys.path` and the package's absolute name, so they are unaffected by the current working directory. A relative import like `from .func1 import func1` is required for the failure mode described, but that is not what the code contains.

Full breakdown with real-world context →

Question 2mediummultiple choice

Study the full Python automation breakdown →

A Python class 'BankAccount' has a method 'withdraw(amount)' that deducts 'amount' from 'self.balance'. A developer writes a subclass 'SavingsAccount' that overrides 'withdraw' to add a penalty if balance drops below minimum. Which design pattern is being used?

Trap 1: Composition

Composition involves 'has-a' relationships, not overriding.

Trap 2: Aggregation

Aggregation is a form of composition.

Trap 3: Inheritance

Inheritance is the mechanism, but the question asks about the pattern.

Study all Scenario common traps →

A
Composition
Why wrong: Composition involves 'has-a' relationships, not overriding.
B
Aggregation
Why wrong: Aggregation is a form of composition.
C
Method overriding
The subclass provides a specific implementation of the inherited method.
D
Inheritance
Why wrong: Inheritance is the mechanism, but the question asks about the pattern.

Full breakdown with real-world context →

Question 3mediummultiple choice

Read the full Scenario explanation →

Consider a class `D` that inherits from multiple base classes `B` and `C`. The developer wants to call a method from a specific parent class while ensuring correct method resolution order (MRO). Which is the safest way?

Trap 1: `self.method()`

`self.method()` performs a normal attribute lookup on the instance, so it dispatches to the most-derived override in the MRO rather than a specific parent's version. In multiple inheritance, this gives you no control over which base implementation runs, and if the current override calls `self.method()` again, it will recurse indefinitely. It is useful for polymorphic calls but cannot be used to select a particular parent.

Trap 2: `ParentClass.method(self)`

`ParentClass.method(self)` explicitly calls a named parent's method while passing the current instance manually, completely bypassing the MRO. This is fragile because it hard-codes the parent's name and expects that parent to exist, and in a diamond hierarchy it can execute the method more than once or overlook an intermediate class that should run first. It is not a cooperative pattern and breaks as soon as the inheritance layout changes.

Trap 3: `BaseClass.method(self)`

`BaseClass.method(self)` targets a specific base implementation directly, skipping all intermediate classes that may need to customize or initialize state. If `BaseClass` is a common ancestor in a diamond, this can run the method multiple times because each derived class calls it explicitly instead of relying on the MRO. This approach ignores the cooperative mechanism and invites duplicated side effects.

Study all Scenario common traps →

A
`self.method()`
Why wrong: `self.method()` performs a normal attribute lookup on the instance, so it dispatches to the most-derived override in the MRO rather than a specific parent's version. In multiple inheritance, this gives you no control over which base implementation runs, and if the current override calls `self.method()` again, it will recurse indefinitely. It is useful for polymorphic calls but cannot be used to select a particular parent.
B
`ParentClass.method(self)`
Why wrong: `ParentClass.method(self)` explicitly calls a named parent's method while passing the current instance manually, completely bypassing the MRO. This is fragile because it hard-codes the parent's name and expects that parent to exist, and in a diamond hierarchy it can execute the method more than once or overlook an intermediate class that should run first. It is not a cooperative pattern and breaks as soon as the inheritance layout changes.
C
`super().method()`
`super().method()` delegates to the next class in the MRO after the current class, not necessarily the immediate parent, which is exactly what cooperative multiple inheritance requires. Python computes the MRO using the C3 linearization algorithm, so every ancestor appears exactly once and after each class's call to `super()`, the chain continues in the correct order. This ensures shared base classes are processed only once and remains correct even when the hierarchy changes.
D
`BaseClass.method(self)`
Why wrong: `BaseClass.method(self)` targets a specific base implementation directly, skipping all intermediate classes that may need to customize or initialize state. If `BaseClass` is a common ancestor in a diamond, this can run the method multiple times because each derived class calls it explicitly instead of relying on the MRO. This approach ignores the cooperative mechanism and invites duplicated side effects.

Full breakdown with real-world context →

Question 4hardmultiple choice

Study the full Python automation breakdown →

A Python class 'Shape' defines an abstract method 'area'. Subclasses 'Circle' and 'Square' implement 'area'. A function 'calculate_area(shape)' expects a 'Shape' instance. Which principle ensures that the function works correctly without knowing the specific subclass?

Trap 1: Interface Segregation Principle

The Interface Segregation Principle (ISP) states that no client should be forced to depend on methods it does not use, advocating for many small, focused interfaces rather than a single general-purpose one. An abstract Shape class with a single area() method does not create a bloated interface that forces subclasses to implement irrelevant functionality. The violation in the scenario concerns subclass substitutability, not the granularity of the interface, so ISP is not the principle at play.

Trap 2: Single Responsibility Principle

The Single Responsibility Principle (SRP) states that a class should have only one reason to change, concerning the cohesion of its own methods and state. An abstract area() method on a Shape class does not introduce multiple responsibilities; it simply defines a contract for subclasses to implement. SRP is about internal class design and does not address the relationship between a base class and its derived types, so it is misapplied here.

Trap 3: Dependency Inversion Principle

The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules, and both should depend on abstractions; it also says abstractions should not depend on details. While an abstract Shape class is indeed an abstraction, DIP primarily concerns the direction of dependencies between modules, not the behavioral substitutability of subclasses. The scenario is about ensuring derived shapes can replace their base class transparently, which is the domain of LSP, not DIP.

Study all Scenario common traps →

A
Interface Segregation Principle
Why wrong: The Interface Segregation Principle (ISP) states that no client should be forced to depend on methods it does not use, advocating for many small, focused interfaces rather than a single general-purpose one. An abstract Shape class with a single area() method does not create a bloated interface that forces subclasses to implement irrelevant functionality. The violation in the scenario concerns subclass substitutability, not the granularity of the interface, so ISP is not the principle at play.
B
Liskov Substitution Principle
The Liskov Substitution Principle (LSP) asserts that any subclass must be able to replace its base class without altering the correctness of the program. When Shape declares an abstract area() method, it establishes a behavioral contract that every subclass must honor; if a subclass overrides area() with an incompatible return type, raises an unexpected exception, or changes invariants, it breaks substitutability. This is exactly the design concern addressed by LSP, making it the correct principle for the described scenario.
C
Single Responsibility Principle
Why wrong: The Single Responsibility Principle (SRP) states that a class should have only one reason to change, concerning the cohesion of its own methods and state. An abstract area() method on a Shape class does not introduce multiple responsibilities; it simply defines a contract for subclasses to implement. SRP is about internal class design and does not address the relationship between a base class and its derived types, so it is misapplied here.
D
Dependency Inversion Principle
Why wrong: The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules, and both should depend on abstractions; it also says abstractions should not depend on details. While an abstract Shape class is indeed an abstraction, DIP primarily concerns the direction of dependencies between modules, not the behavioral substitutability of subclasses. The scenario is about ensuring derived shapes can replace their base class transparently, which is the domain of LSP, not DIP.

Full breakdown with real-world context →

Question 5easymultiple choice

Read the full Scenario explanation →

A developer writes a function that reads a file and processes its content. The function should handle the case where the file does not exist without catching other I/O errors. Which exception should be caught?

Trap 1: PermissionError

PermissionError is a built-in exception that signals insufficient access rights to an OS resource—for example, when a file exists but the current user's mode denies reading it. Since the missing-file condition produces errno ENOENT rather than EACCES or EPERM, PermissionError never fires when the file simply is not present. Therefore it is not the appropriate exception to catch or expect for this scenario, even though permission checks happen before file access.

Trap 2: IOError

IOError in Python 3 is just an alias of OSError, and the name is deprecated from the Python 2 era where it represented every generic input/output problem, including device failures, disk-full conditions, and network errors. If the developer used it to handle a missing file, it would both be stylistically outdated and far too broad, potentially swallowing unrelated I/O errors. A precise handler should target FileNotFoundError instead, avoiding the old alias and relying on the modern exception hierarchy.

Trap 3: OSError

OSError is the common parent class of many filesystem and OS exceptions, including FileNotFoundError, PermissionError, IsADirectoryError, and NotADirectoryError. While catching OSError would technically intercept a missing-file situation, it would also catch every other OS-level failure, making the except block impossible to tailor—there would be no way to know whether the file was missing or some other kernel call failed. This lack of specificity makes OSError a poor choice when the intent is to recover specifically from a nonexistent file path.

Study all Scenario common traps →

A
PermissionError
Why wrong: PermissionError is a built-in exception that signals insufficient access rights to an OS resource—for example, when a file exists but the current user's mode denies reading it. Since the missing-file condition produces errno ENOENT rather than EACCES or EPERM, PermissionError never fires when the file simply is not present. Therefore it is not the appropriate exception to catch or expect for this scenario, even though permission checks happen before file access.
B
IOError
Why wrong: IOError in Python 3 is just an alias of OSError, and the name is deprecated from the Python 2 era where it represented every generic input/output problem, including device failures, disk-full conditions, and network errors. If the developer used it to handle a missing file, it would both be stylistically outdated and far too broad, potentially swallowing unrelated I/O errors. A precise handler should target FileNotFoundError instead, avoiding the old alias and relying on the modern exception hierarchy.
C
OSError
Why wrong: OSError is the common parent class of many filesystem and OS exceptions, including FileNotFoundError, PermissionError, IsADirectoryError, and NotADirectoryError. While catching OSError would technically intercept a missing-file situation, it would also catch every other OS-level failure, making the except block impossible to tailor—there would be no way to know whether the file was missing or some other kernel call failed. This lack of specificity makes OSError a poor choice when the intent is to recover specifically from a nonexistent file path.
D
FileNotFoundError
FileNotFoundError is the specific built-in exception that Python raises when an attempt to open or access a file path cannot succeed because the path does not exist, typically with errno ENOENT. For a read operation, open(path, 'r') will immediately raise it if the file is not present before any other processing occurs. Because it is narrowly scoped, catching FileNotFoundError lets the developer provide exactly the right fallback—like creating the file or printing a meaningful message—without masking permission problems or unrelated OS failures.

Full breakdown with real-world context →

Question 6mediummultiple choice

Study the full Python automation breakdown →

A class inherits from two parent classes that both have a method with the same name. When calling the method on the child, only one parent's version is executed. What Python mechanism determines which one?

Trap 1: Method overloading by signature.

Python does not support method overloading.

Trap 2: Explicit super() call in the child class.

super() is used to call parent methods, but it follows MRO.

Trap 3: Inheritance depth (closest parent wins).

MRO considers multiple factors, not just depth.

Study all Scenario common traps →

A
Method overloading by signature.
Why wrong: Python does not support method overloading.
B
Explicit super() call in the child class.
Why wrong: super() is used to call parent methods, but it follows MRO.
C
Inheritance depth (closest parent wins).
Why wrong: MRO considers multiple factors, not just depth.
D
Method Resolution Order (MRO).
MRO determines the order of method lookup in multiple inheritance.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Scenario sessions

Start a Scenario only practice session

Every question in these sessions is drawn from the Scenario domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Scenario questions →Mixed PCAP session

Frequently asked questions

What does the PCAP exam test about Scenario?: Scenario questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Scenario questions in a focused session?: Yes — the session launcher on this page draws every question from the Scenario domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other PCAP topics?: Use the topic links above to move to related areas, or go back to the PCAP question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the PCAP exam covers. They are not copied from any real exam or dump site.

Scenario only

10 questions 20 questions 30 questions 50 questions

Mixed PCAP session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All PCAP questions Scenario domain overview PCAP exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Scenario practice questions

What to know about Scenario

Common Scenario exam traps

Scenario questions

A Python class 'BankAccount' has a method 'withdraw(amount)' that deducts 'amount' from 'self.balance'. A developer writes a subclass 'SavingsAccount' that overrides 'withdraw' to add a penalty if balance drops below minimum. Which design pattern is being used?

Consider a class `D` that inherits from multiple base classes `B` and `C`. The developer wants to call a method from a specific parent class while ensuring correct method resolution order (MRO). Which is the safest way?

A Python class 'Shape' defines an abstract method 'area'. Subclasses 'Circle' and 'Square' implement 'area'. A function 'calculate_area(shape)' expects a 'Shape' instance. Which principle ensures that the function works correctly without knowing the specific subclass?

A developer writes a function that reads a file and processes its content. The function should handle the case where the file does not exist without catching other I/O errors. Which exception should be caught?

A class inherits from two parent classes that both have a method with the same name. When calling the method on the child, only one parent's version is executed. What Python mechanism determines which one?

Track your progress over time

Start a Scenario only practice session

Related PCAP topic practice pages

Modules and Packages practice questions

Strings practice questions

Object-Oriented Programming practice questions

Exceptions and File I/O practice questions

PCAP fundamentals practice questions

PCAP scenario practice questions

PCAP troubleshooting practice questions

Frequently asked questions

Track your progress

Study resources

Exam traps to avoid