A team lead asked me why their SSO login test could not be made to work. They had spent two weeks on it. Three engineers had tried. Someone suggested the tests were badly written.
Nothing was badly written. They were fighting the architecture, and nobody had explained it to them.
Senior work with any tool starts here: you should be able to predict what the tool cannot do, before you try it. For Cypress that prediction comes from one fact.
Cypress runs inside the browser, in the same window as your application.
Everything else follows. Read the consequences slowly, because each one explains a whole category of problem you will meet.
It shares the browser's event loop with your app. This is why commands queue rather than execute immediately, and why async/await does not work the way JavaScript developers expect. The queue is not a stylistic choice. It is how Cypress schedules work in a loop it does not own.
It can see the DOM directly. No protocol, no serialisation, no round trip to another process. This is why retrying every command is cheap enough to do by default, and it is the single biggest reason Cypress feels stable to beginners.
It is bound by the browser's security model. Your test code is web page code. It obeys the same-origin policy, because the browser enforces that on everything running in a page. This is the wall that team hit.
It sees one browser tab. The test lives in a tab and can only reach what that tab can reach.
Now the useful part. Here is what those four facts predict, and you can derive every one without reading a documentation page.
Cross-origin navigation is hard. Your app is at app.company.com. SSO sends the user to login.okta.com. The moment the browser leaves your origin, Cypress's code cannot follow, because the browser will not let a page script reach across origins. cy.origin() exists to handle this and it is a real, working answer with real constraints. Predicted from fact three.
Multiple tabs are not supported. Not "not yet". A tab cannot control another tab. Predicted from fact four.
Native file dialogs and browser-level dialogs are outside reach. They are operating system windows, not page content.
Network interception works well. Cypress sits in the same context as the app's requests, so watching and modifying them is natural. Predicted from fact two.
Automatic retrying comes free. Same reason.
Now the honest comparison, because a senior engineer is asked this in interviews and should answer without defensiveness.
Playwright and Selenium sit outside the browser and send it commands over a protocol. That costs them: a round trip per command, and less direct knowledge of what the page is doing. It buys them: multiple tabs, multiple origins, multiple browser contexts, and no same-origin restriction, because they are not page code.
Neither architecture is better. They are different trades. Cypress bought developer experience and retry-ability by accepting the browser's constraints. The others bought freedom by accepting distance.
What this means for you as a senior engineer. When someone asks "can Cypress do X?", you do not guess and you do not try it for two weeks. You ask whether X requires leaving the origin, controlling another tab, or reaching outside the page. If it does, the answer is no or "only through a specific workaround", and you can say so on the spot with a reason.
That ability, to answer from architecture rather than experiment, is most of what this track is teaching.
Remember this: Cypress runs inside the browser. Every power and every wall follows from that one sentence.
Reference: Cypress architecture.