Q1 — B ("ibm_quantum_platform"). The valid channel literals in runtime 0.48 are "ibm_quantum_platform", "ibm_cloud", and "local". The legacy "ibm_quantum" channel is retired; "ibm_q", "ibm_quantum_experience", and "aer" were never valid channels.

Q2 — C (Session mode). VQE is the textbook iterative workload: the next job's inputs are not ready until the previous job's result has been classically post-processed. Session mode gives a dedicated window with exclusive QPU access so each iteration runs without re-queuing. Batch is for independent jobs whose inputs are all ready at the outset.

Q3 — D (Batch mode). All inputs are ready up front and the jobs are independent, so batch schedules them together, parallelizes their classical preprocessing, and is generally cheaper than a session. The docs explicitly recommend batch whenever you don't need the extra benefits of sessions.

Q4 — A (Job mode). Docs: "Always use job mode to submit a single primitive request." Sessions/batches provide no queue-time benefit for the first (only) job, so they add cost and complexity for nothing.

Q5 — C (Job mode). Passing a backend object as mode= without any context manager is the definition of job mode: a single standalone primitive request.

Q6 — D. Exiting the context manager auto-closes the session (same as session.close()): it enters "In progress, not accepting new jobs" — running and queued jobs finish, new submissions are rejected. Immediate termination of queued jobs is session.cancel(), not context exit.

Q7 — B. service.least_busy(operational=True, simulator=False) returns the operational real device with the fewest pending jobs. The other calls are invented APIs.

Q8 — B. V2 primitives on IBM hardware only accept ISA circuits — circuits already expressed in the target's basis gates and connectivity. They never auto-transpile; a non-ISA circuit is rejected with an error (an IBMInputValueError explaining the instruction is not supported by the target). Fix: generate_preset_pass_manager(backend=backend, ...).run(qc).

Q9 — C. Estimator PUB order is (circuit, observables, parameter_values, precision) with the trailing entries optional. Sampler PUB order is (circuit, parameter_values, shots).

Q10 — A ((2, 5)). PUB inputs broadcast like NumPy arrays: observables shape (2, 1) against parameter-set shape (5,) broadcasts to (2, 5). Verified locally with StatevectorEstimator: result[0].data.evs.shape == (2, 5).

Q11 — B. run() is asynchronous for every primitive implementation (even local ones return a PrimitiveJob immediately); job.result() is the blocking call. A single run() may carry many PUBs.

Q12 — C. Missing the interactive TTL only temporarily deactivates the workload; normal scheduling resumes on the device. A subsequent job goes through the normal queue and reactivates the session, provided the max TTL has not been reached. The max TTL timer never pauses.

Q13 — A (they fail). When the maximum TTL is reached the workload ends and any remaining queued jobs fail. (Also, a currently running job won't run to completion if doing so would exceed the instance's cost limit.)

Q14 — C. Batch jobs are independent, share no state, and are not guaranteed to run in submission order. Batches do not grant exclusive access — other users' jobs and calibration jobs can interleave if capacity allows.

Q15 — B. Open Plan users cannot submit session jobs. Job and batch modes are available to them.

Q16 — B. StatevectorSampler (in qiskit.primitives, the SDK) is the ideal local reference primitive: no account, no noise, no ISA requirement. Option A needs an account/backend object, C wraps a fake backend in a Session unnecessarily (and sessions with local backends are just local mode anyway), D requires the cloud service.

Q17 — C. Fake backends are built from QPU snapshots: coupling map, basis gates, qubit properties, and a device noise model that is applied automatically during simulation (using Aer under the hood when installed). They are local — no credentials involved.

Q18 — C. Fake backends enforce the target just like real hardware: h is not in FakeManilaV2's basis (cx, id, rz, sx, x), so the run raises IBMInputValueError: 'The instruction h on qubits (0,) is not supported by the target system...' (verified locally). Transpile with a preset pass manager first, then you'd get noisy near-50/50 counts.

Q19 — A. Correct pattern: with Session(backend=backend) as session: then EstimatorV2(mode=session). B invents session=True; C passes mode= to Session and backend= to the primitive (both wrong keyword names); D passes the string "session", which mode= does not accept.

Q20 — B. SamplerV2.__init__ signature: mode: BackendV2 | Session | Batch | None. A backend object = job mode (or local testing mode if it's a fake backend / Aer simulator); a Session or Batch object selects those modes. Mode strings are not accepted.

Answer key: 1-B, 2-C, 3-D, 4-A, 5-C, 6-D, 7-B, 8-B, 9-C, 10-A, 11-B, 12-C, 13-A, 14-C, 15-B, 16-B, 17-C, 18-C, 19-A, 20-B.

Lab solutions

All lab code below was executed with the project venv (/home/kartikey_purohit/development/ibm-qiskit/.venv/bin/python).

Lab 1 — The noisy GHZ bet

from qiskit import QuantumCircuit
from qiskit.transpiler.preset_passmanagers import generate_preset_pass_manager
from qiskit_ibm_runtime import SamplerV2
from qiskit_ibm_runtime.fake_provider import FakeManilaV2
 
backend = FakeManilaV2()
 
ghz = QuantumCircuit(3)
ghz.h(0)
ghz.cx(0, 1)
ghz.cx(1, 2)
ghz.measure_all()
 
pm = generate_preset_pass_manager(backend=backend, optimization_level=1)
isa_ghz = pm.run(ghz)
 
job = SamplerV2(mode=backend).run([isa_ghz], shots=4000)
counts = job.result()[0].data.meas.get_counts()
print(sorted(counts.items(), key=lambda kv: -kv[1]))

Predictions:

000 and 111 dominate. Combined they keep roughly 80-90% of shots — NOT >99%. Observed run: 000 ≈ 1750, 111 ≈ 1600 of 4000 (~84%), with 011, 001, etc. absorbing the rest via the snapshot noise model (two CX gates + readout error compound on 3 qubits).
No — the raw circuit raises IBMInputValueError because h is not in the target's basis gates. Fake backends enforce the ISA requirement exactly like V2 primitives on hardware.

Lab 2 — Sweep and guess the curve

import numpy as np
from qiskit import QuantumCircuit
from qiskit.circuit import Parameter
from qiskit.primitives import StatevectorEstimator
 
theta = Parameter("t")
pqc = QuantumCircuit(1)
pqc.ry(theta, 0)
 
params = np.linspace(0, 2 * np.pi, 9).reshape(9, 1)
result = StatevectorEstimator().run([(pqc, "Z", params)]).result()[0]
print(np.round(result.data.evs, 3))
 
# Extension: two observables broadcast against the sweep
result2 = StatevectorEstimator().run([(pqc, [["Z"], ["X"]], params)]).result()[0]
print(result2.data.evs.shape)
print(np.round(result2.data.evs, 3))

Predictions:

⟨Z⟩ = cos(θ) for an Ry(θ) rotation. Observed: [1., 0.707, 0., -0.707, -1., -0.707, -0., 0.707, 1.] — a cosine.
θ=0 → 1, θ=π/2 → 0, θ=π → −1.
Single observable, 9 parameter sets → evs.shape == (9,). Extension: observables (2,1) broadcast against params (9,) → evs.shape == (2, 9); the X row traces sin(θ) (Ry(θ)|0⟩ has ⟨X⟩ = sin θ).

Lab 3 — Batch rehearsal, offline

from qiskit import QuantumCircuit
from qiskit.transpiler.preset_passmanagers import generate_preset_pass_manager
from qiskit_ibm_runtime import SamplerV2
from qiskit_ibm_runtime.fake_provider import FakeSherbrooke
 
backend = FakeSherbrooke()
print(backend.num_qubits)                     # 127
print(sorted(backend.target.operation_names))
 
pm = generate_preset_pass_manager(backend=backend, optimization_level=1)
 
circuits = []
for n in (2, 3):
    qc = QuantumCircuit(n)
    qc.h(0)
    for i in range(n - 1):
        qc.cx(i, i + 1)
    qc.measure_all()
    circuits.append(pm.run(qc))
 
sampler = SamplerV2(mode=backend)
jobs = [sampler.run([c], shots=1024) for c in circuits]   # submit all first
for job in jobs:                                          # collect afterwards
    print(job.result()[0].data.meas.get_counts())

Predictions:

No — FakeSherbrooke's 2-qubit basis gate is ecr, not cx (operation names: delay, ecr, for_loop, id, if_else, measure, reset, rz, switch_case, sx, x). The pass manager rewrites cx into ecr-based sequences.
This maps to batch mode: independent jobs, all inputs ready at the outset, submitted together and collected afterwards. On hardware you would wrap it in with Batch(backend=backend) as batch: and use SamplerV2(mode=batch). Session would work but costs more and its exclusive-access benefit buys nothing for independent jobs.
None. Real batch jobs share no state and have no ordering guarantee — each job must be fully self-contained.