Question 157 of 511
Exceptions and File I/OhardMultiple ChoiceObjective-mapped

Quick Answer

The correct answer is to use file locking with `fcntl.flock` and re-open the file when a lock cannot be acquired, because the external process overwriting or truncating `market_feed.bin` invalidates the original file descriptor, causing the stale descriptor to trigger Errno 9 on subsequent reads. On Linux, when a file is replaced, the old inode is deleted while the Python script still holds a descriptor pointing to it, making any read operation fail with "Bad file descriptor." This scenario tests your understanding of file descriptor management and inter-process synchronization, a common pitfall in the PCAP exam’s section on file I/O and OS interaction. The trap is assuming the `with` statement guarantees safety against external modifications, but it only manages the descriptor lifecycle, not concurrent access. Memory tip: "Lock before you look, re-open if it’s broke" — always coordinate with external writers to keep your file descriptor fresh.

PCAP Exceptions and File I/O Practice Question

This PCAP practice question tests your understanding of exceptions and file i/o. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.

You are a Python developer at a financial firm. Your team maintains a high-frequency trading system that reads real-time market data from a binary file 'market_feed.bin'. The file is updated every millisecond by an external process. Your script uses a `with` statement to open the file in binary read mode and reads exactly 1024 bytes each iteration in an infinite loop. Recently, the script has been crashing intermittently with an `OSError` with message '[Errno 9] Bad file descriptor'. The error occurs at random times, sometimes after minutes, sometimes after hours. The system runs on Linux. The script runs as a daemon. You suspect the issue is related to file descriptor exhaustion or the external process manipulating the file. What is the most likely cause and the best course of action?

Clue words in this question

Noticing these words before you look at the options changes how you read each choice.

  • Clue: "best"

    Why it matters: Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.

  • Clue: "most likely"

    Why it matters: Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.

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

Use file locking (e.g., fcntl.flock) to coordinate access with the external process, and re-open the file if a lock cannot be acquired.

The most likely cause is that the external process overwrites or truncates 'market_feed.bin' between reads, causing the file descriptor held by the Python script to become invalid (stale). On Linux, when a file is replaced or truncated by another process, the original file descriptor may point to a deleted inode, and subsequent reads yield 'Bad file descriptor'. Option D is correct because file locking (e.g., fcntl.flock with LOCK_SH or LOCK_EX) coordinates access, and re-opening the file after a lock failure ensures a fresh, valid descriptor.

Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Open the file without using a context manager and manually close it after each read.

    Why it's wrong here

    Manual close does not prevent the external process from invalidating the descriptor.

  • Increase the read buffer size to 4096 bytes to reduce the number of read operations.

    Why it's wrong here

    This does not fix the underlying file descriptor issue.

  • Catch OSError and re-open the file within the except block, then continue reading.

    Why it's wrong here

    This can work but may still encounter the error if the file is truncated repeatedly; also does not address the root cause.

  • Use file locking (e.g., fcntl.flock) to coordinate access with the external process, and re-open the file if a lock cannot be acquired.

    Why this is correct

    File locking prevents the external process from truncating the file while your script is reading, avoiding the bad file descriptor.

    Clue confirmation

    The clue words "best", "most likely" in the question point toward this answer.

    Related concept

    Read the scenario before looking for a memorised answer.

Common exam traps

Common exam trap: answer the scenario, not the keyword

Python Institute often tests the misconception that catching and retrying an OSError (Option C) is sufficient, but the trap is that it ignores the underlying race condition and can lead to infinite loops or data corruption, whereas proper synchronization (Option D) prevents the error from occurring in the first place.

Detailed technical explanation

How to think about this question

Under the hood, when an external process replaces 'market_feed.bin' (e.g., via rename() or truncate()), the original file descriptor's inode is orphaned. On Linux, reading from an orphaned descriptor that points to a deleted file returns EBADF (Errno 9). File locking with fcntl.flock() uses advisory locks that coordinate between cooperating processes; the external process must also acquire the same lock. In high-frequency trading, a common pattern is to use a lock file or a named semaphore to ensure exclusive write access, and the reader re-opens the file after each successful lock acquisition.

KKey Concepts to Remember

  • Read the scenario before looking for a memorised answer.
  • Find the constraint that changes the correct option.
  • Eliminate answers that are true in general but not in this case.

TExam Day Tips

  • Watch for words such as best, first, most likely and least administrative effort.
  • Review why wrong options are wrong, not only why the correct option is correct.

Key takeaway

Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

Real-world example

How this comes up in practice

A company's IT admin needs to give a contractor read-only access to production logs without sharing account credentials. Using role-based access control (RBAC) and temporary scoped permissions — not a permanent shared password — is the correct pattern. Questions like this test whether you can apply least-privilege access across cloud identity services.

What to study next

Got this wrong? Here's your next step.

Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.

Related practice questions

Related PCAP practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

Practice this exam

Start a free PCAP practice session

Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.

FAQ

Questions learners often ask

What does this PCAP question test?

Exceptions and File I/O — This question tests Exceptions and File I/O — Read the scenario before looking for a memorised answer..

What is the correct answer to this question?

The correct answer is: Use file locking (e.g., fcntl.flock) to coordinate access with the external process, and re-open the file if a lock cannot be acquired. — The most likely cause is that the external process overwrites or truncates 'market_feed.bin' between reads, causing the file descriptor held by the Python script to become invalid (stale). On Linux, when a file is replaced or truncated by another process, the original file descriptor may point to a deleted inode, and subsequent reads yield 'Bad file descriptor'. Option D is correct because file locking (e.g., fcntl.flock with LOCK_SH or LOCK_EX) coordinates access, and re-opening the file after a lock failure ensures a fresh, valid descriptor.

What should I do if I get this PCAP question wrong?

Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.

Are there clue words in this question I should notice?

Yes — watch for: "best", "most likely". Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.

What is the key concept behind this question?

Read the scenario before looking for a memorised answer.

About these practice questions

Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Keep practising

More PCAP practice questions

Last reviewed: Jun 30, 2026

Question Discussion

Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.

Loading comments…

Sign in to join the discussion.

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.