Then you’ve got the right of it in understanding an “appropriate” use of pass/fail and the sample option.  

For other folks following along at home and wondering what we mean here:

What we wouldn’t want to see is a test where we’re expecting 100% “pass”, setting sample to zero to evaluate the entire population, and then realizing you’re collecting the entire table.  If memory serves, there is a way to set max baseline collection via sys_property, but if the table is of sufficient size this functionally doesn’t matter after a few thousand records (the job will likely stall out around 10k in many cases).  

In those situations (where you want to prove you’ve set things up properly and you want to show some evidence that things look good) you actually require more than one indicator, or better still, and indicator + evidence collection task (which can be automated).  

You’ll want ONE that has a sample size and is set to pass (this is essentially a  desired state proof).  If any of these indicators are related to CMDB attributes there’s also a much easier desired state audit collection you can use as well!  

You’ll then also want some negative/fail cases to show you are also on the look out for common fail states as part of your due diligence, and these you’d want to set to zero; typically these are the common failure states that you match your queries and collect (hopefully) a smaller number of fails as you evaluate the entire table.