(NB: in this posting, when referring to switches, I have in mind Enterprise switches like the Catalyst 2K and 3K series.)
"Classification is enabled only if QoS is enabled on the switch."
Yes and no. On switches, I recall you do need to have QoS enabled to do "classification", but by default, I also recall, "classification" is not done, excluding, on older Cisco switches, all frames and packets, being remarked with "default" tag.
"By default, QoS is enabled on the switch."
I believe that's true for the later gen Cisco switches, but not true on older Cisco switches, like 3560/3750 and earlier. I also recall that also true for earlier/original 2960 switches, but don't know about the later gens of that series of switches.
"Does this mean the switch is automatically categorizing traffic? I'm assuming it is not and that this is referring to "classification" that has been configured?"
Again, depends on generation of switch. Also again, besides earlier switches, when QoS (optionally) enabled, by default, reset QoS tags to default (zero) setting. Later switches have QoS enabled by default, but also by default, don't remark/retag (much like a router, although switches, I believe, will have default of multiple egress queues where routers, generally, just have one FIFO queue).
Also depends whether AutoQoS has be triggered. (The later versions of AutoQoS, I believe, tries to provide Cisco's 11/12 class model, both for ingress and egress.)
"Following the above, are ACLs the only way to specify the traffic I want to mark?"
No they are not, but options vary per platform, and sometimes, IOS version and/or IOS feature set (or license).
Recall switches, except for some very old models, can use class-map (using non-ACL match and/or set tag statements) and policy-map to classify and/or tag in an ingress policy. Later switches might support class-map and policy-map egress classification and/or tagging too.
". . . and it is best practice to mark traffic as close to the source as possible."
Yes and no. Assuming you "trust" the markings, often marking ASAP is good, but if there a need to remark, even "trusted" markings, that's fine too. Further, I've often delayed classification and/or tagging (BTW, tagging often appears to be misunderstood, it's really there to more quickly process frames/packets, looking at a tag, rather than a lengthy frame/packet analysis, again and again and again . . . ) until I really needed it, like dealing with traffic from LAN to WAN where there's often a major loss in available bandwidth.
"I'm marking traffic per best practices and the QoS baseline model."
Marking per the 11/12 class models (Cisco's or the RFC's) usually doesn't "hurt" anything, but using that model, for actual QoS, in my (not so humble) opinion, is overly complex; often disappointing those using such with its results (beyond, perhaps, for real-time traffic).
