A municipal forest maintains an external trust to a vendor domain. What should the tester do conceptually regarding that trust?
Select an answer to reveal the explanation.
Short Explanation
A trust is a bridge between neighborhoods. Before you walk across, check whether that other neighborhood is even on the engagement map. Scope first, then path talk.
Full Explanation
If a municipal forest maintains an external trust to a vendor domain, the tester should recognize that trusts can extend attack paths across domains and confirm whether the vendor domain is in scope before pursuing those paths. Assuming all trusts are out of scope forever and never mentioning them hides material architecture risk. Treating trusts as irrelevant because authentication never crosses boundaries is factually wrong. Automatically compromising the vendor domain first because trusts supposedly authorize unrestricted partner testing invents scope. Exam caveat: discover and disclose trusts; traverse only with explicit authorization. Operational check: document trust type and direction, pause cross-domain attacks, obtain written scope for the vendor domain if needed, and report trust risk even when partner testing is deferred. In municipal operations, record the rationale in the engagement notes so future testers and city defenders understand which approach was chosen and which failure modes the rejected options would create for civic services. Re-validate the same judgment after the next change window so the control still holds under the city’s current tooling, identity posture, and RoE amendments.