PCAP Modules and Packages Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Create virtual environment, Activate virtual environment, Install packages, Deactivate virtual environment

  Why this is correct

  The correct sequence begins with `python -m venv <env>` (or `virtualenv <env>`), which builds an isolated directory containing its own Python interpreter, standard library, and `site-packages`. Activation (e.g., `source <env>/bin/activate` on Unix or `<env>\Scripts\activate` on Windows) prepends the environment's binary directory to your `PATH`, so the `python` and `pip` commands resolve to that environment's versions. Only after activation should you run `pip install <package>`, because pip now writes into the environment's `site-packages` rather than the global one. Finally, `deactivate` removes the `PATH` changes and `VIRTUAL_ENV` variable, returning your shell to its pre-activation state.

• ✗

  Activate virtual environment, Create virtual environment, Install packages, Deactivate virtual environment

  Why it's wrong here

  This sequence is invalid because the activation command (e.g., `source myenv/bin/activate`) will fail if `myenv` does not already exist; activation requires a pre-existing structure with a `pyvenv.cfg` and a `bin` or `Scripts` directory that only the creation step produces. Without first running the venv-creation command, there is no isolated interpreter or `site-packages` to reference, so the shell simply returns an error and the rest of the steps cannot proceed. In contrast, the correct order is to create the environment first, then activate its known path, ensuring the activation script can locate the necessary files.

• ✗

  Create virtual environment, Install packages, Activate virtual environment, Deactivate virtual environment

  Why it's wrong here

  Running `pip install` before activation causes the `pip` command to resolve to the global (system) Python's pip, so the packages are written into the global `site-packages`, not into the virtual environment intended for isolation. This defeats the entire purpose of a virtual environment, which is to keep project dependencies separate from system-wide packages and from other projects. Activation must occur immediately after creation and before any package installation so that the `PATH` is updated and pip targets the environment's own `site-packages`; otherwise, the environment remains empty and the global environment becomes polluted.

• ✗

  Create virtual environment, Activate virtual environment, Deactivate virtual environment, Install packages

  Why it's wrong here

  Deactivating the environment immediately after activation leaves the shell back with the global Python and pip, so any subsequent `pip install` command installs packages globally rather than inside the virtual environment. The sequence implies that package installation happens after deactivation, which means the environment never receives the dependencies it was created to hold—rendering the setup useless. The proper order is to keep the environment active during all installation work, then deactivate only after all packages are installed and you no longer need the isolated interpreter on your `PATH`.

Go deeper

Related to this question