Monitoring integrations on a new Data Domain were configured by three people over the past week, and each one says their piece 'probably works'. What standard should the team apply before sign-off?
Select an answer to reveal the explanation.
Short Explanation
'Probably works' is the wrong verb tense for an acceptance sheet. Every destination you configured deserves its own small fire drill - a trap that arrives, a log line that lands, an email someone opens. One pipe proving up doesn't vouch for the others; you test each one you built.
Full Explanation
Each alerting destination is an independent path with its own failure surface - protocol version, community or credentials, destination address, firewall state - and a single event can sail into one destination while dying silently at another. Only per-destination verification with an observed receipt converts belief into evidence, and recording each receipt gives the acceptance sheet the thing it actually needs: an artifact per line. Accepting one successful delivery as blanket proof confuses the health of the alerting engine with the health of every path out of it; SNMP working while email is blocked is a normal, unremarkable state that the one-event test is statistically likely to bless anyway. Second-pair-of-eyes review catches typos but not policy: a blocked UDP port, a receiver ACL that drops the appliance's address, or a v3 authentication mismatch all look perfect in configuration text and only speak up when a message actually moves. Waiting two weeks for organic events leaves the riskiest stretch - the first days of production - running on unproven alerting, and a quiet system may generate no test event at all in that window. Exam caveat: verify the receiving side maps severity correctly too - a trap that arrives labeled and filed wrong is half a pass. Operational check: the acceptance record lists every configured destination with its test event, receipt location, and timestamp.