Title: CertiQ — C1000-179 / 4 · Run quantum circuits

Question: A researcher needs to run 30 circuits that are fully independent of each other (no circuit depends on another's results) on a busy IBM Quantum device, and wants to minimize total time spent waiting in the queue. Which execution mode fits best?
A.Batch mode — submit the 30 jobs together as one batch
B.Session mode — open a session and submit the 30 jobs inside it
C.Job mode — submit 30 separate individual jobs
D.One session per circuit — open 30 sessions, one job each
Answer: Correct: A
Batch mode is designed exactly for collections of independent jobs: the jobs are scheduled as a group, can run back-to-back with parallelized classical processing, and the whole collection clears the queue faster than individually queued jobs — without reserving the device between jobs the way a session does.
References
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
- quantum.cloud.ibm.com/docs/guides/run-jobs-batch
Meta: s4-q001 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: You are running a variational algorithm: each iteration submits one Estimator job whose circuit parameters are chosen by a classical optimizer from the previous iteration's expectation value. You want to avoid re-queuing between iterations and keep the QPU responsive to the tight classical-quantum feedback loop. Which execution mode is the best fit?
A.Batch mode
B.Session mode
C.Job mode (submit each iteration as a separate individual job)
D.Combine all iterations into a single primitive job
Answer: Correct: B
A session gives dedicated, exclusive access to the QPU for a window, so an iterative workload whose next input depends on the previous result runs back-to-back without each job re-entering the fair-share queue. This is the documented use case for sessions: iterative workloads requiring frequent classical-quantum communication.
References
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
- quantum.cloud.ibm.com/docs/guides/run-jobs-session
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q010 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: You want to compare the effect of several different error-mitigation settings on one circuit and observable. The jobs are independent, all known at the outset, and you want them to run as closely together in time as possible (to limit device drift) while still being able to inspect each job's result separately. Which execution mode does the documentation recommend?
A.Job mode, submitting all jobs and hoping the scheduler groups them
B.Session mode
C.Batch mode
D.A separate session per mitigation setting
Answer: Correct: C
All jobs are independent and available at the outset, so they can be scheduled collectively in a batch: you wait through the queue only once, the classical pre-processing runs in parallel, and the jobs run closely together to limit drift, while you still get each job's result individually. Because sessions are generally more expensive, batch is preferred whenever dedicated access is not required.
References
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/run-jobs-batch
Meta: s4-q011 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: The circuit qc is built with abstract gates and passed straight to a primitive bound to a real-device backend, without any transpilation. What happens when this code runs?
from qiskit import QuantumCircuit
from qiskit_ibm_runtime import SamplerV2
from qiskit_ibm_runtime.fake_provider import FakeManilaV2
backend = FakeManilaV2()
qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)
qc.measure_all()
sampler = SamplerV2(mode=backend)
job = sampler.run([qc])          # qc was never transpiled
print(job.result()[0].data.meas.get_counts())
A.It prints counts split roughly 50/50 between '00' and '11' — the primitive transpiles the circuit automatically before running.
B.It raises an error: the circuit's instructions do not match the backend's ISA (the h gate is not in the target's instruction set), so the primitive rejects it.
C.It raises a TranspilerError because no pass manager was created.
D.It prints counts over only '00', silently dropping the gates the backend does not support.
Answer: Correct: B
Runtime primitives require ISA circuits: the circuit must already conform to the backend's instruction set architecture (native basis gates and qubit connectivity). Passing an un-transpiled circuit raises IBMInputValueError (the instruction h on qubits (0,) is not supported by the target system). You must build a preset pass manager and transpile first.
References
- quantum.cloud.ibm.com/docs/guides/hello-world
- quantum.cloud.ibm.com/docs/guides/transpile
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q012 · predict-output · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: You have opened a batch with batch = Batch(backend=backend) and want to create a SamplerV2 that submits its jobs inside that batch. Which construction is correct?
from qiskit_ibm_runtime import SamplerV2, Batch
batch = Batch(backend=backend)
sampler = ...  # which one?
A.SamplerV2(session=batch)
B.SamplerV2(batch=batch)
C.SamplerV2(mode=batch)
D.SamplerV2(mode="batch")
Answer: Correct: C
In V2, the execution mode is passed through the single mode= parameter, which accepts a Backend, Session, or Batch object. SamplerV2(mode=batch) binds the primitive to the batch so its jobs are scheduled together.
References
- quantum.cloud.ibm.com/docs/guides/run-jobs-batch
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q013 · mcq · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: Which of the following statements about batch mode are TRUE? (Select two.)
A.The classical pre-processing (for example, compilation) of the jobs runs in parallel, so a batch finishes significantly faster than running the same jobs serially.
B.Jobs in a batch are not guaranteed to run in the order they were submitted, and they do not get exclusive access to the QPU.
C.Batch mode reserves the QPU exclusively, so no other users' jobs or calibration jobs can run during the batch.
D.Wrapping a single job in a batch reduces that job's queuing time compared with job mode.
E.Batch mode is only available on paid plans; Open Plan users cannot submit batch jobs.
Answer: Correct: A, B
Batch parallelizes the classical processing of independent jobs and packs their quantum execution tightly, so a batch completes faster than serial submission. However, batched jobs are not guaranteed to run in submission order and do NOT get exclusive access — other users' jobs and calibration jobs may run in between if there is capacity.
References
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
- quantum.cloud.ibm.com/docs/guides/run-jobs-batch
Meta: s4-q014 · multi · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: A developer on the free Open Plan writes code that opens Session(backend=backend) and submits jobs inside it. What is the documented outcome, and what should they do instead?
A.The session runs normally — the Open Plan supports all three execution modes.
B.Open Plan users cannot submit session jobs; the workload must run in job mode or batch mode instead.
C.Sessions work on the Open Plan but are limited to a single job each.
D.The Open Plan supports sessions but not batch mode.
Answer: Correct: B
The documentation states explicitly that Open Plan users cannot submit session jobs; their workloads must run in job mode or batch mode. Sessions (dedicated, exclusive access) are reserved for paid plans.
References
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/run-jobs-session
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
Meta: s4-q015 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: This code, adapted from a Qiskit V1 tutorial, fails on the line that constructs the sampler. What is the bug?
from qiskit_ibm_runtime import SamplerV2
from qiskit_ibm_runtime.fake_provider import FakeManilaV2
backend = FakeManilaV2()
# isa: a circuit already transpiled for `backend`
sampler = SamplerV2(backend=backend)
job = sampler.run([isa])
A.SamplerV2 has no backend= parameter; the execution target is passed through mode= — use SamplerV2(mode=backend).
B.SamplerV2 must be imported from qiskit.primitives, not qiskit_ibm_runtime.
C.The circuit must be passed to the constructor, not to run().
D.run() needs the backend as a second argument: sampler.run([isa], backend).
Answer: Correct: A
In V2 the backend= keyword was removed from the primitive constructors; the execution mode (a Backend, Session, or Batch) is supplied through mode=. SamplerV2(backend=backend) raises TypeError: unexpected keyword argument 'backend'; the fix is SamplerV2(mode=backend).
References
- quantum.cloud.ibm.com/docs/guides/hello-world
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/run-jobs-batch
Meta: s4-q016 · spot-bug · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: Your workload is a set of independent circuits with no feedback between them. A colleague suggests always using a session 'to be safe'. According to IBM's guidance, why is batch usually the better default here?
A.Batch mode guarantees your jobs run before any other user's jobs.
B.Sessions cannot run more than one job, so they cannot handle a set of circuits.
C.Sessions are generally more expensive than batches, so you should use batch whenever you do not need a session's dedicated exclusive access.
D.Sessions do not support the SamplerV2 and EstimatorV2 primitives.
Answer: Correct: C
Sessions provide dedicated, exclusive access but at higher usage cost. The docs recommend using batch whenever you don't need that dedicated access — as with a set of independent jobs — because batch delivers the same parallel classical processing and single queue wait more cheaply.
References
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q017 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: The circuit is transpiled to the backend's ISA (which pads it to the device's qubit count), but the two-qubit observable is passed to the Estimator without being mapped to the transpiled layout. What happens?
from qiskit import QuantumCircuit
from qiskit.quantum_info import SparsePauliOp
from qiskit.transpiler.preset_passmanagers import generate_preset_pass_manager
from qiskit_ibm_runtime import EstimatorV2
from qiskit_ibm_runtime.fake_provider import FakeManilaV2
backend = FakeManilaV2()
qc = QuantumCircuit(2); qc.h(0); qc.cx(0, 1)
obs = SparsePauliOp("ZZ")
pm = generate_preset_pass_manager(backend=backend, optimization_level=1)
isa = pm.run(qc)
estimator = EstimatorV2(mode=backend)
job = estimator.run([(isa, obs)])   # obs NOT mapped with apply_layout
print(job.result()[0].data.evs)
A.It prints an expectation value close to +1.
B.It raises a ValueError: the 2-qubit observable does not match the transpiled circuit's qubit count — the observable must be mapped with obs.apply_layout(isa.layout) first.
C.It prints an expectation value close to 0 because the observable is ignored.
D.It raises IBMInputValueError because the observable is not an ISA operator.
Answer: Correct: B
Transpiling to the device maps the 2-qubit circuit onto the 5-qubit target, so the circuit now has 5 qubits while the observable still has 2. The Estimator raises ValueError (the number of qubits of the circuit ... does not match the number of qubits of the ...-th observable). You must align the observable with obs.apply_layout(isa.layout).
References
- quantum.cloud.ibm.com/docs/guides/hello-world
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/transpile
Meta: s4-q018 · predict-output · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: You want the Runtime service to automatically pick a real QPU that is currently operational and has the shortest queue. Which call does this?
from qiskit_ibm_runtime import QiskitRuntimeService
service = QiskitRuntimeService()
backend = ...  # which call?
A.service.least_busy(operational=True, simulator=False)
B.service.least_busy(simulator=True)
C.service.backend()
D.service.most_available()
Answer: Correct: A
least_busy returns the backend with the fewest pending jobs. Passing operational=True restricts to devices that are up, and simulator=False restricts to real QPUs, so you get the least-busy operational hardware backend.
References
- quantum.cloud.ibm.com/docs/guides/hello-world
- quantum.cloud.ibm.com/docs/guides/run-jobs-session
Meta: s4-q019 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: Inside a with Batch(backend=backend): block you construct sampler = SamplerV2(mode=backend) — passing the backend object rather than the batch — and submit jobs. What happens?
with Batch(backend=backend):
    sampler = SamplerV2(mode=backend)   # backend, not the batch
    job = sampler.run([isa])
A.The jobs run in batch mode because they are lexically inside the with Batch(...) block.
B.The jobs run in job mode, not batch mode — setting the mode to a backend bypasses the surrounding batch context.
C.It raises an error because a primitive inside a batch context must set mode=batch.
D.The batch is silently converted into a session.
Answer: Correct: B
The execution mode is determined by the mode argument, not by lexical position. If you set the mode to a backend object, the program runs in job mode even inside a batch or session context. To run inside the batch, pass the batch (mode=batch) or construct the primitive with no mode inside the context so it inherits the batch.
References
- quantum.cloud.ibm.com/docs/guides/run-jobs-batch
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q020 · mcq · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: A SamplerV2 is constructed with no mode and is not inside any session or batch context, then run is called. What is the result?
from qiskit_ibm_runtime import SamplerV2
# isa: a transpiled circuit; no Session/Batch context is open
sampler = SamplerV2()          # no mode given
job = sampler.run([isa])
A.It raises TypeError because mode is a required positional argument.
B.It runs on a default local simulator.
C.It raises ValueError: A backend or session must be specified. — a primitive needs an execution target.
D.It automatically selects the least busy backend.
Answer: Correct: C
mode defaults to None, so construction succeeds, but a primitive must ultimately have an execution target. With no mode and no enclosing session/batch, calling run raises ValueError: A backend or session must be specified.
References
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/hello-world
Meta: s4-q021 · mcq · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: Which TWO statements correctly describe what happens when you CLOSE a session (for example, by exiting the with Session(...) context manager)? (Select two.)
A.Closing resets the session's maximum TTL back to zero and reopens it.
B.Jobs already submitted (running or queued) continue to completion, and their results can still be retrieved.
C.All queued jobs are immediately cancelled and their results are lost.
D.The session stops accepting new jobs.
E.The backend is removed from the service and must be re-fetched.
Answer: Correct: B, D
Closing a session puts it into 'In progress, not accepting new jobs': it stops accepting new submissions but finishes processing jobs that are already running or queued, and you can still retrieve their results. Exiting the context manager is equivalent to session.close().
References
- quantum.cloud.ibm.com/docs/guides/run-jobs-session
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q022 · multi · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: A developer expects counts to hold measurement results, but the last line fails with an error and the result data is empty. What is the bug?
qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)
# (no measurement instructions)
isa = pm.run(qc)
job = SamplerV2(mode=backend).run([isa], shots=1024)
counts = job.result()[0].data.meas.get_counts()   # fails / empty
A.The circuit has no measurement instructions, so the Sampler returns an empty result with no meas register; add qc.measure_all() (or explicit measurements) before transpiling.
B.get_counts() was removed in V2; you must use job.result().counts.
C.shots=1024 is too low to populate the classical register.
D.The Sampler cannot run an entangling circuit; you must use the Estimator instead.
Answer: Correct: A
The SamplerV2 returns the outcomes of classical registers written by measurements. With no measurement, the result DataBin has no meas field, so data.meas raises AttributeError and the result is empty. Adding qc.measure_all() (which also creates the meas register) before transpiling fixes it.
References
- quantum.cloud.ibm.com/docs/guides/hello-world
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q023 · spot-bug · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: You plan an iterative workload that uses Probabilistic Error Cancellation (PEC), where a learned noise model should stay valid across many jobs. Why is a session particularly suited to this, compared with batch or job mode?
A.Sessions automatically re-learn the noise model before every single job, which batch cannot do.
B.Only sessions support error mitigation; batch and job mode disable PEC entirely.
C.In a dedicated session the jobs run close together, so a noise model learned once stays valid for subsequent jobs; in batch or job mode the next job may sit in the queue long enough that the noise model becomes stale.
D.PEC requires exclusive access because it physically recalibrates the QPU hardware between jobs.
Answer: Correct: C
A session's dedicated window keeps jobs running tightly together, so you can learn the noise model once and reuse it while it is still accurate. In batch or job mode a later job can spend so long in the queue that the device drifts and the learned model becomes stale.
References
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q024 · mcq · Difficulty 3/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: When you construct QiskitRuntimeService() without specifying a channel, which channel is used by default?
A.ibm_cloud
B.ibm_quantum_platform
C.ibm_quantum
D.local
Answer: Correct: B
The default channel is ibm_quantum_platform. Because this is almost always the appropriate channel, the docs omit it from the examples; you only pass channel= to override it.
References
- quantum.cloud.ibm.com/docs/guides/initialize-account
- quantum.cloud.ibm.com/docs/guides/hello-world
Meta: s4-q025 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: FakeManilaV2 has five qubits connected in a line (0-1-2-3-4). The circuit below uses only the backend's native basis gates, but qubits 0 and 4 are not directly connected. It is submitted without routing. What happens?
backend = FakeManilaV2()          # line topology 0-1-2-3-4
qc = QuantumCircuit(5)
qc.sx(0)
qc.rz(0.7, 0)
qc.cx(0, 4)                       # 0 and 4 are NOT adjacent
qc.measure_all()
job = SamplerV2(mode=backend).run([qc])
A.It raises a TypeError because a 5-qubit circuit is too large for FakeManilaV2.
B.It runs fine; using only the backend's basis gates is sufficient, so connectivity does not matter.
C.It runs after the primitive automatically inserts SWAP gates to route the CX.
D.It raises an error: cx on qubits (0, 4) is not supported because those qubits are not connected — the circuit still must be routed to the coupling map, not just expressed in basis gates.
Answer: Correct: D
An ISA circuit must satisfy BOTH the native basis gates AND the device's qubit connectivity. Using only basis gates is not enough: a two-qubit gate between non-adjacent qubits raises IBMInputValueError (the instruction cx on qubits (0, 4) is not supported by the target system). A preset pass manager would route it by inserting SWAPs.
References
- quantum.cloud.ibm.com/docs/guides/transpile
- quantum.cloud.ibm.com/docs/guides/hello-world
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q026 · predict-output · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: A session (or batch) reaches its maximum time to live (max TTL) while some of its jobs are still running and others are still waiting in the queue. What happens?
A.The session is automatically extended until the queue empties.
B.All jobs, running and queued, are immediately cancelled.
C.The max TTL timer pauses until all queued jobs complete.
D.Jobs that are already running finish, but jobs still queued are failed/cancelled.
Answer: Correct: D
When the maximum TTL is reached the session/batch is closed. Jobs that are already running are allowed to finish, but any jobs still queued are failed. The max TTL timer starts when the first job starts and does not pause.
References
- quantum.cloud.ibm.com/docs/guides/run-jobs-session
- quantum.cloud.ibm.com/docs/guides/run-jobs-batch
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q027 · mcq · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: Which snippet correctly opens a session on backend, runs a transpiled circuit isa with a Sampler inside it, and retrieves the counts?
# backend is a real-device (fake) backend; isa is transpiled for it
A.with Session(backend=backend) as session: job = SamplerV2(mode=session).run(isa) # unwrapped counts = job.result()[0].data.meas.get_counts()
B.with Session(backend=backend) as session: job = SamplerV2(mode=session).run([isa]) counts = job.result()[0].data.meas.get_counts()
C.session = Session(mode=backend) # mode=, not backend= job = SamplerV2(mode=session).run([isa]) counts = job.result()[0].data.meas.get_counts()
D.with Session(backend) as session: job = SamplerV2(session).run(isa) # unwrapped counts = job.result()[0].data.meas.get_counts()
Answer: Correct: B
Session takes the backend (Session(backend=backend)), the primitive binds to the session with mode=session, and run takes an iterable of PUBs, so the circuit is wrapped in a list: run([isa]). Exiting the context manager closes the session while the submitted job runs to completion.
References
- quantum.cloud.ibm.com/docs/guides/run-jobs-session
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q028 · mcq · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: You partition a long list of independent circuits into several jobs and run them in batch mode. Besides shorter queuing, what practical advantage does this give over submitting everything as one giant job?
A.You get each job's results individually, so you can cancel the remaining jobs if early results are unsatisfactory, or re-submit only the one job that failed.
B.Batch mode guarantees exclusive access to the QPU for the whole run.
C.Batch mode applies stronger error mitigation than a single job.
D.A batch never counts against your usage or cost.
Answer: Correct: A
Partitioning into multiple batched jobs makes results more flexible to work with: you receive each job's result separately, so you can stop early by cancelling remaining jobs, or re-run just a failed job instead of the entire workload.
References
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
- quantum.cloud.ibm.com/docs/guides/run-jobs-batch
Meta: s4-q029 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: On a trusted laptop, you want to authenticate once and then reuse your credentials in later Python sessions without pasting your API key each time. Which approach matches the documented workflow?
A.Store the backend name in save_account so that least_busy is no longer needed.
B.Pass token= and instance= to QiskitRuntimeService() every time; there is no way to persist them.
C.Call QiskitRuntimeService.save_account(token="<api-key>", instance="<CRN>") once; afterwards service = QiskitRuntimeService() loads the saved credentials.
D.Call QiskitRuntimeService.login() with your IBM id and password.
Answer: Correct: C
QiskitRuntimeService.save_account(token=..., instance=...) saves credentials to disk once (recommended only in a trusted environment). Later, QiskitRuntimeService() with no arguments loads the saved default account, so you never paste the key again.
References
- quantum.cloud.ibm.com/docs/guides/hello-world
- quantum.cloud.ibm.com/docs/guides/initialize-account
Meta: s4-q030 · mcq · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: For which TWO of the following workloads is SESSION mode the most appropriate execution mode? (Select two.)
A.Fifty independent circuits, all known upfront, that you want to clear the queue as cheaply as possible.
B.An experiment that needs the QPU reserved exclusively so that no other users' jobs or calibrations interleave with your circuits.
C.A variational eigensolver whose next circuit depends on the classical optimizer's use of the previous result.
D.A single circuit you want to run once as quickly as possible.
E.A large collection of unrelated benchmarking circuits where minimizing cost is the priority.
Answer: Correct: B, C
Sessions shine for iterative workloads whose inputs are not all ready at the outset (A) and for experiments that need dedicated, exclusive access to the QPU (B). Both justify a session's higher cost.
References
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/run-jobs-session
Meta: s4-q031 · multi · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: A developer has a backend name as a string and writes SamplerV2(mode="ibm_manila"), expecting the primitive to resolve it. What is the result?
from qiskit_ibm_runtime import SamplerV2
sampler = SamplerV2(mode="ibm_manila")
A.It works only if a QiskitRuntimeService has already been initialized in the session.
B.It works: the primitive looks up the backend by that name.
C.It raises ValueError — mode must be a Backend, Session, or Batch object (or None), not a string.
D.It raises KeyError because no backend named 'ibm_manila' exists.
Answer: Correct: C
SamplerV2's mode accepts a Backend, Session, or Batch object (or None). A string is rejected at construction with ValueError: mode must be of type Backend, Session, Batch or None. You must pass the resolved backend object (for example from service.backend("ibm_manila") or service.least_busy(...)).
References
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/hello-world
Meta: s4-q032 · mcq · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: In a session, what is the difference between the interactive TTL and the maximum TTL?
A.The interactive TTL is what you configure with max_time; the maximum TTL cannot be set.
B.The interactive TTL caps the session's total lifetime; the maximum TTL is the time allowed for any single job to run.
C.They measure the same thing; 'interactive' is simply the Open Plan name for the maximum TTL.
D.The maximum TTL caps the session's total lifetime from when it starts; the interactive TTL is the idle gap allowed between consecutive jobs before the session is temporarily deactivated.
Answer: Correct: D
The maximum TTL is the total time the session may run, measured from when the first job starts; you set it with max_time. The interactive TTL is the allowed idle time between jobs — if no job is queued within that window, the session is temporarily deactivated (and must be reactivated through the normal queue). The interactive TTL cannot be configured.
References
- quantum.cloud.ibm.com/docs/guides/run-jobs-session
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q033 · mcq · Difficulty 3/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: You want to run a transpiled circuit as a single standalone job (job mode) on backend. Which construction is correct?
from qiskit_ibm_runtime import SamplerV2
# backend is a real-device (fake) backend
sampler = ...  # which one?
A.SamplerV2(session=backend)
B.SamplerV2(backend=backend)
C.SamplerV2(mode="ibm_manila")
D.SamplerV2(mode=backend)
Answer: Correct: D
Job mode is achieved by giving the primitive a backend as its mode: SamplerV2(mode=backend). A primitive whose mode is a backend (rather than a Session or Batch) submits a single standalone job.
References
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/hello-world
Meta: s4-q034 · mcq · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: According to the documented best practices, which execution mode should you use to submit a single primitive request (one small experiment)?
A.Job mode (mode=backend, with no session or batch context).
B.Session mode, to guarantee it runs before other users' jobs.
C.Batch mode, to reduce the single job's queuing time.
D.It makes no difference; all three modes add exactly the same overhead for one job.
Answer: Correct: A
The guidance is explicit: always use job mode to submit a single primitive request. Job mode is easiest for a small experiment and may even run sooner than batch.
References
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q035 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: This 'map the problem -> optimize -> execute' workflow skips a step and fails at run. Which change makes it run correctly?
backend = FakeManilaV2()
qc = QuantumCircuit(2); qc.h(0); qc.cx(0, 1)
obs = SparsePauliOp("ZZ")
estimator = EstimatorV2(mode=backend)
job = estimator.run([(qc, obs)])     # runs the abstract circuit + raw observable
print(job.result()[0].data.evs)
A.Transpile to an ISA circuit and map the observable to its layout before running: isa = pm.run(qc); mapped = obs.apply_layout(isa.layout); estimator.run([(isa, mapped)]).
B.Increase the shots via estimator.options.default_shots before running.
C.Wrap the circuit and observable in an extra list: estimator.run([[qc, obs]]).
D.Pass the backend as a second argument to run: estimator.run([(qc, obs)], backend).
Answer: Correct: A
The 'optimize' step is missing: the circuit was never transpiled to the backend's ISA (its h/cx are not native and unrouted), so run raises IBMInputValueError. Building an ISA circuit with the preset pass manager and mapping the observable with apply_layout fixes it and yields an expectation value.
References
- quantum.cloud.ibm.com/docs/guides/hello-world
- quantum.cloud.ibm.com/docs/guides/transpile
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q036 · spot-bug · Difficulty 3/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: Your workload is a single circuit. A colleague wraps it in a batch, expecting the batch to reduce its queuing time. Why does this not help?
A.Single jobs submitted in a batch are always redirected to a simulator.
B.Batches only speed up circuits with more than 100 gates.
C.The batch cancels the single job because a batch requires at least two jobs.
D.The queuing time does not decrease for the first job submitted within a batch (or session), so wrapping a single job in a batch provides no queuing benefit.
Answer: Correct: D
Batching helps by scheduling multiple jobs together and parallelizing their classical processing. But the first job in a batch still waits in the normal queue, so a batch (or session) provides no benefit when there is only one job.
References
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/run-jobs-batch
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
Meta: s4-q037 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: Inside with Session(backend=backend) as session: you want an Estimator that submits its jobs inside the session. Which construction is correct?
with Session(backend=backend) as session:
    estimator = ...  # which one?
A.EstimatorV2(session=session)
B.EstimatorV2(mode=session)
C.EstimatorV2(mode="session")
D.EstimatorV2(backend=session)
Answer: Correct: B
As with the Sampler, the execution mode is passed through mode=, which accepts a Session object. EstimatorV2(mode=session) binds the Estimator to the open session.
References
- quantum.cloud.ibm.com/docs/guides/run-jobs-session
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q038 · mcq · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: Which THREE of the following statements about Qiskit Runtime execution modes are correct? (Select three.)
A.Job mode submits a single primitive request made without a context manager.
B.In session mode the user has exclusive access to the QPU during the active window; no other jobs, including calibration jobs, run.
C.In batch mode the classical pre-processing of the jobs is parallelized so the quantum execution can be packed tightly together.
D.Batch mode gives each job dedicated, exclusive QPU access, just like a session.
E.Session mode is available to Open Plan users, just like batch mode.
F.Sessions are generally cheaper than batches for the same set of independent jobs.
Answer: Correct: A, B, C
Job mode is a single request without a context manager (A). A session grants exclusive access with no other users' or calibration jobs during the active window (B). Batch parallelizes the classical processing to pack quantum execution tightly (C).
References
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/choose-execution-mode
Meta: s4-q039 · multi · Difficulty 3/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: You saved two accounts named open_acct and premium_acct without marking a default, then run service = QiskitRuntimeService() with no arguments. According to the documented behavior, which account's credentials are used?
A.It raises an error because no default account is set.
B.The account that was saved most recently.
C.open_acct, because free (Open) plans are always preferred.
D.The account whose name comes last alphabetically — here premium_acct.
Answer: Correct: D
When multiple credential sets are saved, none is marked default, and none is specified at initialization, the service uses the one whose name comes last alphabetically. premium_acct sorts after open_acct, so premium_acct is used.
References
- quantum.cloud.ibm.com/docs/guides/initialize-account
Meta: s4-q040 · mcq · Difficulty 3/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: When does a session (or batch) actually start — that is, when does its maximum TTL timer begin counting?
A.When its first job begins execution.
B.The moment you construct the Session/Batch object.
C.When you exit the context manager.
D.When you call service = QiskitRuntimeService().
Answer: Correct: A
A session or batch starts when its first job begins execution; that is when the maximum TTL timer starts. (Note: if you open a session but submit no jobs for 30 minutes, it closes automatically.)
References
- quantum.cloud.ibm.com/docs/guides/run-jobs-session
- quantum.cloud.ibm.com/docs/guides/run-jobs-batch
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q041 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: Using local testing mode, a session is opened on FakeManilaV2 and its backend() accessor is called. What is printed?
from qiskit_ibm_runtime import Session
from qiskit_ibm_runtime.fake_provider import FakeManilaV2
backend = FakeManilaV2()
with Session(backend=backend) as session:
    print(session.backend())
A.None — a local session has no associated backend.
B.<FakeManilaV2 object ...> — it returns the backend object itself.
C.fake_manila — session.backend() returns the backend's name (a string).
D.It raises an error because no QiskitRuntimeService was provided.
Answer: Correct: C
Session.backend() returns the name of the QPU bound to the session as a string. For a session opened on FakeManilaV2 it returns 'fake_manila'. Local testing mode lets you open a Session(backend=fake_backend) and run primitives without any credentials.
References
- quantum.cloud.ibm.com/docs/guides/run-jobs-session
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q042 · predict-output · Difficulty 2/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: You have two transpiled ISA circuits isa1 and isa2 and want to run both in a single Sampler job on backend. Which call is correct?
sampler = SamplerV2(mode=backend)
job = ...  # run both isa1 and isa2 in one job
A.sampler.run([[isa1, isa2]])
B.sampler.run(isa1, isa2)
C.sampler.run([isa1], [isa2])
D.sampler.run([isa1, isa2])
Answer: Correct: D
run takes one iterable of PUBs. Two circuits are two PUBs, so they go in one list: run([isa1, isa2]). The result then has one pub-result per circuit.
References
- quantum.cloud.ibm.com/docs/guides/execution-modes
- quantum.cloud.ibm.com/docs/guides/hello-world
Meta: s4-q043 · mcq · Difficulty 1/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.

Question: A Bell circuit is transpiled and run with the Estimator on a noisy fake backend to measure <ZZ>. Ideally the Bell state gives <ZZ> = +1. Which best describes the value actually obtained?
backend = FakeManilaV2()
qc = QuantumCircuit(2); qc.h(0); qc.cx(0, 1)     # Bell state
obs = SparsePauliOp("ZZ")
pm = generate_preset_pass_manager(backend=backend, optimization_level=1)
isa = pm.run(qc)
mapped = obs.apply_layout(isa.layout)
evs = EstimatorV2(mode=backend).run([(isa, mapped)]).result()[0].data.evs
print(evs)
A.Exactly +1.0, with no effect from device noise.
B.A value close to 0.
C.A value close to -1.
D.A value close to +1 but slightly below it (roughly +0.9), because the two qubits are strongly Z-correlated and noise only slightly reduces the correlation.
Answer: Correct: D
In the Bell state the two qubits' Z outcomes are perfectly correlated, so <ZZ> is +1 ideally. On a noisy device the measured value is close to but a bit below +1 (about +0.9 here), reflecting the small reduction from noise.
References
- quantum.cloud.ibm.com/docs/guides/hello-world
- quantum.cloud.ibm.com/docs/guides/execution-modes
Meta: s4-q044 · predict-output · Difficulty 3/3
AI-generated, execution-verified — CertiQ. Unofficial: not affiliated with, endorsed by, or sponsored by IBM.