Organizational Impact of Adopting SRE
Adopting SRE is an organizational change as much as a technical one. Exam questions probe the engagement models: an embedded model places SREs inside a product team; a consulting model has SREs advise without owning on-call; and an enablement or "SRE as a library" model scales a small central team by giving product teams tooling, SLO templates, and training while the product team keeps ownership. A very common structure is the hybrid: a central platform/SRE team owns shared reliability infrastructure and a handful of critical services, while product teams own SLOs for their own services. Candidates should recognize that SRE does not eliminate the need for on-call, nor does it consolidate all operational responsibility in one team - ownership boundaries must be explicit.
Traps include assuming a central SRE team should own reliability for every service in the company (it cannot scale and creates a gatekeeper bottleneck); assuming an org can "become SRE" by re-titling operations staff while leaving ticket-driven work untouched; and assuming DevOps and SRE are opposing philosophies. They share the same goals - SRE is best understood as a prescriptive implementation of DevOps principles, with error budgets and toil budgets as its distinguishing mechanisms.
Other organizational levers that appear in questions: executive sponsorship for the error budget policy (otherwise it is unenforceable under delivery pressure); compensation and on-call load for sustainable rotations; hiring and career ladders that reward reliability work; and measuring adoption by behavior (SLO coverage, toil percentage, postmortem action closure, MTTR trend) rather than by headcount. Rule of thumb: a sustainable on-call rotation keeps a person paged roughly once or twice per shift and keeps toil below about half of an SRE's time, so the rest goes to engineering.