Quiz: Running on Real Hardware

Answers with explanations at the end.

1. You must choose between a 133-qubit device with median two-qubit gate error 0.0042 and a 127-qubit device with median error 0.0117. Your circuit uses 6 qubits and 400 two-qubit gates. Which do you choose, and why is the qubit count irrelevant?

2. True or false: the device with the lowest median two-qubit gate error is the best device to run on.

3. On FakeSherbrooke, the two-qubit gate error ranges from 0.0035 to 1.0 across qubit pairs, and the median gate error across four different devices ranges from 0.0042 to 0.0117. Which choice — which device or which qubits — has more effect on your result, and by roughly what factor?

4. A qubit reports readout_error = 0.5000. Give two physically distinct situations that produce this value, and explain how you would tell them apart.

5. Write the identity relating readout_error, prob_meas1_prep0, and prob_meas0_prep1.

6. Qubit 92 has $P(1|0) = 0.0127$ and $P(0|1) = 0.6685$. You have two circuits: one whose correct answer is 000, one whose correct answer is 111. Which will be badly damaged by including qubit 92, and which will survive nearly intact?

7. A preflight check rejects any qubit with readout_error > 0.6. Which of FakeSherbrooke's twelve bad qubits does it catch, and why is this threshold dangerous?

8. AerSimulator.from_backend(FakeSherbrooke()) and SamplerV2(mode=FakeSherbrooke()) return different distributions for a measure-only circuit on qubit 84. One returns roughly {'0': 2050, '1': 2046} and the other returns {'1': 4096}. Which is which, and what single observation about the seed tells you which one is not sampling?

9. The layout-scoring function in §12.3 adds readout and gate errors, though errors actually compound multiplicatively. It also weights each link by 3, a factor borrowed from SWAP decomposition that does not apply. Why is the function still useful?

10. Enumerating all connected 3-qubit paths on a 127-qubit device gives 394 candidates, with a 131.9× spread in score between best and worst. Measured correct fractions for a 3-qubit GHZ were 0.9727, 0.9207, and 0.2844. Match each to best, median, and worst, and state the ratio between the extremes.

11. You submit a job, get a job ID, and your laptop crashes. Is the result lost? What is the minimum you needed to have recorded?

12. Why should you never cancel a queued job and resubmit it?

13. When is least_busy() the right choice, and when is it the wrong one?

14. You are running a 200-iteration VQE. Explain why a session matters here in a way it would not for a single circuit, and name one cost of using one.

15. State the first two steps of the noise-or-bug decision procedure, and explain why step 2 makes an airtight inference rather than a probabilistic one.

16. A circuit returns the wrong answer on hardware. You run it on a noiseless simulator and it returns the wrong answer there too. What have you learned, and what have you ruled out?

17. Your measured correct fraction is 0.9727 and your error budget, built from calibration data before the run, predicted 0.9706. Why is this a stronger conclusion than "the histogram looks fine"?

18. In Case Study 2's Run B, only four of eight possible outcomes appeared: 111, 110, 011, 010. What do these four share, and what does that tell you about the hardware?

19. Case Study 2's Run C showed two clean peaks of nearly equal height — the shape of a healthy GHZ state — at 000 and 011, with 111 appearing 5 times in 4096 shots. Why is a tall peak on a single wrong outcome never noise?

20. Run B had a measured correct fraction of 0.2844 against an error budget predicting 0.0000 — the measurement was better than predicted. Step 4 of the procedure lists "much smaller deviation than predicted" as a sign you accidentally ran a simulator. Why did this not mislead the investigation?

Answers

1. The 133-qubit device with error 0.0042. With 400 two-qubit gates, survival probability goes roughly as $(1-e)^{400}$: $0.9958^{400} \approx 0.19$ versus $0.9883^{400} \approx 0.009$ — a factor of about 20. Qubit count is irrelevant because you need 6 and both have far more; extra qubits you do not use contribute nothing.

2. False. It depends on the circuit. fake_kyiv has the best readout error (0.0127) and the worst gate error (0.0117); fake_torino has the best gate error (0.0042) and the worst readout (0.0229). A shallow circuit with many measurements is readout-dominated and wants Kyiv; a deep one wants Torino.

3. Which qubits, by roughly a hundredfold. Between devices the spread is about 2.8× (0.0117/0.0042); within one device it is about 288× (1.0/0.0035). Choosing good qubits matters far more than choosing a good device.

4. (a) A genuine coin flip: $P(1|0) = P(0|1) = 0.5$, the qubit reports randomly. (b) A stuck qubit: $P(1|0) = 1$, $P(0|1) = 0$ — it always reports 1, and $(1+0)/2 = 0.5$. Tell them apart by reading prob_meas1_prep0 and prob_meas0_prep1 directly, or by preparing $|0\rangle$ and measuring: a coin flip gives ~50/50, a stuck qubit gives all 1s. Qubit 84 on FakeSherbrooke is case (b).

5. $\texttt{readout_error} = \dfrac{P(1|0) + P(0|1)}{2} = \dfrac{\texttt{prob_meas1_prep0} + \texttt{prob_meas0_prep1}}{2}$

6. The 111 circuit is badly damaged — qubit 92 misreports a $|1\rangle$ as 0 about 67% of the time. The 000 circuit survives nearly intact: it misreports a $|0\rangle$ only 1.3% of the time. The averaged readout_error of 0.3406 cannot distinguish these two cases at all.

7. It catches none of them. The highest averaged readout error on the device is qubit 84's 0.5000, which is below 0.6 — so the threshold passes the single worst qubit on the chip. The threshold is dangerous precisely because averaging caps a stuck qubit at 0.5: any threshold above 0.5 on the averaged value can never catch a stuck qubit. Check both directions instead.

8. AerSimulator.from_backend returns the ~50/50 result, because NoiseModel.from_backend symmetrizes into [[0.5, 0.5], [0.5, 0.5]]. SamplerV2(mode=backend) returns {'1': 4096}, honoring the asymmetry. The seed changes nothing in the second — {'1': 4096} for seeds 1234, 7, and 99 alike — which shows nothing is being sampled; it is deterministic.

9. Because it only has to rank, not to predict. The measurement confirms the ranking holds: best (0.9727) > median (0.9207) > worst (0.2844), in exactly the predicted order. An inaccurate score that orders candidates correctly is entirely sufficient for choosing among them.

10. Best [122, 123, 124] → 0.9727; median [67, 66, 65] → 0.9207; worst [83, 84, 85] → 0.2844. Ratio of extremes: 3.4×. Same circuit, same chip, same second.

11. No, the result is not lost. Jobs persist server-side. You needed the job ID; retrieve with service.job(job_id). This is why the job ID should be recorded at submit time rather than after result() returns.

12. You lose your queue position and start from the back. Queue time typically dominates total turnaround, so cancelling and resubmitting nearly always makes things slower, not faster.

13. Right for iteration and development, where turnaround matters more than result quality. Wrong for results you will report, because it optimizes for availability, not device quality — the least busy device is often least busy for a reason. For a real result, choose on §12.1's metrics and accept the wait.

14. Without a session, each of the 200 iterations queues independently, so queue time — not QPU time — dominates completely. A session reserves a window and keeps your position between iterations. The cost: sessions are metered while open, including while your classical optimizer is thinking, so slow classical work is billed as if it were quantum work.

15. ① Did it run where you think? (check backend.name, the final layout, and preflight.) ② Does it fail in noiseless simulation too? Step 2 is airtight because noise cannot cause a failure that persists when noise is removed — that is a deductive statement, not a statistical one. It eliminates an entire hypothesis class with one run.

16. You have learned it is a bug, definitively, and you have ruled out every noise explanation — decoherence, gate error, readout error, crosstalk, calibration drift, all of it. The investigation moves to your code, and no amount of error mitigation will help.

17. Because "explained" is a stronger claim than "looks fine." The budget was built from calibration data before seeing the result and accounts for the missing 2.7% gate by gate and readout by readout. Nothing is left over. Without that, a healthy-looking result might be hiding a second effect that happens to be small — you would have no way to know.

18. All four have the middle bit set to 1, and the four missing outcomes are exactly those with a middle bit of 0. The middle clbit reads physical qubit 84, which is stuck at 1. The histogram names the broken qubit — information that the scalar "correct fraction 0.2844" discards entirely.

19. Because noise spreads. Depolarizing, readout, and thermal errors distribute probability across many outcomes, falling off with the number of bit flips required. A single wrong outcome holding a quarter of all shots is a deterministic error, which means it lives in the circuit, the layout, or the bit ordering — never in the device. Here, 011 instead of 111 says qubit 2 was never entangled.

20. Because step 1 had already fired — preflight caught the stuck qubit and two dead ECR pairs before any modeling was done. The procedure is ordered so that cheap, unambiguous checks come first and the subtler, interpretation-dependent ones are never load-bearing. The general rule: when an early step gives a clean answer, stop; do not keep walking down the list gathering evidence that requires interpretation.