Why might GDB refuse to set another breakpoint on an embedded target?

Because it has run out of hardware breakpoint slots. On a flash-resident program the debugger must use hardware breakpoints (software breakpoints can't be patched into flash), and the chip has only a small fixed number of breakpoint comparators, often around six on a Cortex-M, so once you've set that many, attempting another fails with a message like "cannot insert breakpoint" or "no hardware breakpoint slots available." The same applies to watchpoints, which draw from a separate small pool of data-watchpoint comparators (the DWT), so you can only watch a few addresses at once. The fix is simply to delete breakpoints/watchpoints you no longer need (delete, info breakpoints to see them) to free slots, and to be economical, set the few that matter rather than leaving stale ones around. Related subtleties: temporary breakpoints (tbreak) auto-delete after one hit and so don't hold a slot long; conditional breakpoints may consume a slot but evaluate the condition in software (halting on every hit), which is slow rather than slot-limited; and if you've copied a function to RAM you could use software breakpoints there to sidestep the limit. The core point an interviewer wants is that the limit is a hardware resource constraint imposed by flash execution, not a GDB bug, the desktop habit of unlimited breakpoints doesn't transfer.