Software and Environment Management

A data scientist runs nvidia-smi on a workstation and sees a CUDA Version of 12.2 listed in the top-right corner of the output. They then run nvcc --version and it reports CUDA compilation tools release 11.8. What does this mismatch most likely indicate?

• ABoth values report the same underlying CUDA runtime, so the mismatch is cosmetic and will not affect GPU-accelerated libraries.
• Bnvidia-smi and nvcc both read from the same CUDA runtime library, so the figures should always agree and any difference points to a corrupted installation.
• CThe driver supports CUDA 12.2, but the CUDA toolkit installed for compiling is version 11.8, so compiled extensions may not match the driver capabilities.check_circle Correct
• DThe CUDA version shown by nvidia-smi reflects the toolkit release, so upgrading the driver would bring nvcc in line without reinstalling the toolkit.

Why A is wrong: This is a common misconception. The two values come from different sources - the driver and the installed toolkit - and a mismatch can cause real runtime errors when a library compiled against 12.2 tries to use toolkit-11.8 symbols.

Why B is wrong: nvidia-smi reads from the GPU driver, not the CUDA runtime library. It is normal and expected for the driver-reported CUDA ceiling to be higher than the toolkit version, so a difference does not automatically mean corruption.

Why C is correct: nvidia-smi reports the maximum CUDA version the installed driver can support, while nvcc reports the toolkit version actually installed. A gap between the two means compiled CUDA code targets an older toolkit, which can cause compatibility issues with libraries expecting 12.x features.

Why D is wrong: nvidia-smi shows the maximum CUDA version the driver supports, not the toolkit release. Upgrading the driver raises that ceiling further but does not change the installed toolkit version reported by nvcc.

A team needs to reproduce a RAPIDS pipeline on a colleague's machine such that not only the Python packages match but also the system libraries, the CUDA runtime, and the way the host driver is presented to the application. Which approach most completely satisfies this full-stack reproducibility requirement?

• AShare an exported conda environment file so the colleague can recreate the identical Python package set on their own operating system.
• BSend a requirements file pinning every Python package version so pip installs the exact same wheels on the colleague's host.
• CDocument the exact CUDA toolkit and driver versions in the README so the colleague can install matching versions manually on their own system.
• DDistribute a container image built on an official RAPIDS base image, run it with the GPU-enabled container runtime, and pin the package versions inside the image.check_circle Correct

Why A is wrong: A conda environment file reproduces the Python and conda-managed layer well, which is why it is tempting, but it does not capture the surrounding operating-system libraries or guarantee the same CUDA runtime image the way a container does.

Why B is wrong: Pinned wheels fix the Python layer, but pip does not control the host system libraries or the CUDA runtime image, so the surrounding stack can still differ between the two machines.

Why C is wrong: Written instructions help, but manual installation is error-prone and still depends on the colleague's base operating system, so it does not deliver the bundled, reproducible full-stack environment a container image provides.

Why D is correct: A container image packages the operating-system libraries, CUDA runtime, and pinned Python packages together, and the GPU-enabled runtime exposes the host driver consistently, so it reproduces the full software stack rather than only the Python layer.

A team wants a colleague who clones their repository months later to rebuild exactly the same set of package versions the original author used, down to the transitive dependencies, rather than just the loosely specified top-level packages. Which artefact, committed to version control, most directly delivers this guarantee?

• AA lock file that records the fully resolved, exact versions of every direct and transitive dependency in the environment.check_circle Correct
• BA README section that lists the main libraries the project uses, so the colleague can install whichever current versions match those names.
• CAn unpinned environment file that names the top-level packages but lets the solver choose versions at install time.
• DA copy of the installed package binaries committed alongside the source code for the colleague to reuse directly.

Why A is correct: A lock file captures the complete resolved dependency graph with exact pinned versions, so rebuilding from it reproduces the identical package set rather than re-solving against newer releases.

Why B is wrong: A prose list documents intent, but it omits exact versions and transitive dependencies, so the colleague would install whatever is current and likely reproduce a different dependency set.

Why C is wrong: An unpinned environment file is tempting because it is machine-readable, but without pinned versions the solver picks newer builds later, so the rebuilt environment can drift from the original.

Why D is wrong: Committing built binaries is brittle and platform-specific, bloats the repository, and is not the standard reproducibility mechanism, whereas a lock file is the portable, supported way to pin a resolved environment.

A team maintains two separate GPU-accelerated projects on the same workstation. Project A requires cuDF 23.10 and Project B requires cuDF 24.06. Without per-project virtual environments, what is the most likely consequence when both projects are run from a single shared Python installation?

• ABoth versions of cuDF are loaded simultaneously into memory, and Python selects the correct one automatically based on the import context.
• BOnly one version of cuDF can be installed in the shared environment, so one project will run against an incompatible version and may produce incorrect results or fail with import errors.check_circle Correct
• CThe projects run correctly because pip resolves version conflicts at import time by inspecting each script's requirements file.
• DThe RAPIDS compatibility matrix prevents installation of cuDF 24.06 when cuDF 23.10 is already present, so the team is warned before any conflict occurs.

Why A is wrong: Python can only have one version of a package active in a given interpreter at a time. There is no automatic context-based version switching within a single installation; installing a second version simply overwrites the first.

Why B is correct: A standard Python installation holds exactly one version of each package. Upgrading cuDF for Project B overwrites the version Project A requires. The affected project then either fails to import or silently uses an API surface that has changed, risking incorrect computation without an obvious error.

Why C is wrong: pip does not perform runtime version selection. Resolution happens at install time, not import time. Once a package is installed, all scripts using that interpreter see the same version, making runtime conflict resolution impossible.

Why D is wrong: pip and conda will typically overwrite the existing version rather than block installation outright, depending on solver settings. A warning or solver error may appear, but the protection comes from isolated environments, not from a built-in compatibility matrix block.

An analyst clones a shared RAPIDS repository and, while a teammate continues pushing commits to the remote main branch, makes no local commits of her own. Later she wants to bring those new remote commits into her local main branch so her working copy is up to date. Which git command both fetches the remote commits and integrates them into her current branch in one step?

• ARun git push, which transfers the newer remote commits down into the current local branch.
• BRun git pull, which fetches commits from the remote and merges them into the current local branch.check_circle Correct
• CRun git clone again, which re-downloads the repository and integrates the new commits into the existing branch.
• DRun git fetch, which downloads the remote commits and immediately merges them into the current branch.

Why A is wrong: Tempting because push also synchronises with the remote, but push sends local commits up to the remote; it never brings remote commits down, so it cannot update the local branch.

Why B is correct: Correct. git pull is a fetch followed by an integration step; it downloads the new remote commits and merges (or rebases) them into the current branch, updating the working copy in a single command.

Why C is wrong: Tempting because cloning does obtain remote history, but git clone creates a fresh copy of the whole repository into a new directory; it does not update an existing working copy in place.

Why D is wrong: Tempting because fetch is the first half of the answer, but git fetch only downloads the remote commits into remote tracking refs and stops there; it does not merge them into the current branch, so the working copy is unchanged.