Yes, I think this is key. This blog post and the quotes in the article are calling this a "gaffe", but in an organization the size and complexity of Microsoft, I'd say that mistaken permissions assignments are inevitable. So I don't think it's really helpful to focus on the "someone in a 220k person company made a mistake at some point" angle.
However, at most companies there is usually a hard thick line between production and test systems. Granting production access to a test account should be basically impossible, so how that happened should be what the investigation should focus on.
On top of that, when one (person/company) sets up a test account they should (at the creation/activation) set the deletion/deactivation date. So even if the admin is hit by a bus, that damn account will go off on DDMMYYYY and not "live long enough to become the villain".
Also, TERRIBLE/HORRIBLE user access management and review. How do they let a test account be live for "months"? Don't they have some alerts for all test accounts in PROD environment to pester them daily??
(I keep ranting about the need of a strong and capable internal IT audit.. this is an alert that your IT audit SHOULD have set up for their Continuous Audit processes)
Might be better to say that most companies think they have that kind of isolation, but pentesting, red teaming and incidents then later proof they don't. I have even seen companies routing prod traffic to test systems, it's not uncommon.
This is almost certainly another key trust misconfiguration, just like the last few major breaches at Microsoft. Last time it was leaving expired keys in place along with not enforcing expiry checks in the client. This time it's configuring the same key in both prod and test.
It's grade school stuff that they keep getting wrong.
However, at most companies there is usually a hard thick line between production and test systems. Granting production access to a test account should be basically impossible, so how that happened should be what the investigation should focus on.