A bank wants Meraki branch health and the ThousandEyes tests for those same branches in one operational view. Which approach meets that request?
Select an answer to reveal the explanation.
Short Explanation
Two maps of the same city help you only when they are taped into one picture. You integrate Meraki and ThousandEyes so branch health and the tests share a view. A private spreadsheet, switching one product off, or a collector that keeps its own copy leaves the bank with split operations.
Full Explanation
The bank asked for one operational view of each branch, which means Meraki health and the ThousandEyes tests have to be read together rather than reconciled by hand. Integrating Meraki and ThousandEyes so branch health and the tests share one operational view is the approach that meets that request, because each branch's local health and the synthetic tests for that site stay on the same picture. A hand-maintained spreadsheet that copies Meraki branch health each morning is a side record. It goes stale, it omits the tests, and it is not an operational view either product can share. Turning ThousandEyes off so branch health remains on the Meraki dashboard alone deletes the test results the bank still needs. A second collector that stores branch metrics and does not share them with either product adds another inventory and another screen, which is the split the request was meant to end. Exam caveat: naming both products is not the same as integrating them; the view has to contain both datasets for the same branch. Operational check: pick one branch and confirm its Meraki health and its ThousandEyes tests are visible together without a manual export.