Ok so, I have a canvas. I have labeled it with the tag “GameUI” and am able to reference it and everything.
I have tested that if I have the object active before I test, and use the line “.SetActive(false)” that it will disable the object. But if I do “.SetActive(true)” it doesn’t work, which ultimately throws an error.
Here’s a snippet:
gameUI = GameObject.FindGameObjectWithTag("GameUI");
gameUI.SetActive(true);
Any guidance for a newbly dude like myself would be great. 
Not pasting the error makes it much harder to diagnose the problem.
However, this one is fairly straightforward. Any of the “Find” methods don’t find inactive GameObjects. It’s the first line that is failing.
You can have the UI object be active at start, find it then and deactivate it, then (using the same reference you found earlier) activate it later. Or, you can make “gameUI” public and drag-assign it in the Inspector, which doesn’t depend on the active state of the object.
I did a workaround. I attached the UI to the player so I didn’t have to worry about it until the player spawned. It’s now always active and works just fine.
The reason I didn’t post the error was because it was in reference to another line of code that was returning null reference because the canvas object was not being made active before the next line was called, thus throwing an “unrelated” error to this specific issue.
I was hoping it was something in the editor I was missing, as in “the checkbox isn’t making it active/inactive, it’s actually disabling it” or something to that extent.
The checkbox in the editor does, in fact, enable/disable the object, correct? If that’s the case, is there a method like “Find” that would find an inactive object?
The one at the top left of the inspector (above the transform values) does. Most components also have their own checkboxes, which controls that component’s “.enabled”.
Not really, but “Find” is generally not the best way to get references to objects anyway. You can use singletons, drag-to-inspector public references, etc, etc, and these are generally better in practice.
I think in this case, having a singleton game manager class, which itself holds a reference to the UI (which would be assign in the inspector) is probably the best way to go about it.