In the practice of Kimball's Dimensional data warehouse design model, do lookup tables (not dimensions) contain a sid column? Trying to create a simple lookup table for a drop down on a BI web page.
The table contains 2 columns, an key and a description.
What is the best practice with regard to Dimensional Modeling when designing this table?
Would key => number, description => character (column => data type) be sufficient or does the key need to be a SID?

Think of a dropdown in a web page or web form like "Country".
If your natural key can only ever be associated with one description, and your lookup table only contains static reference data, then I see no need for a surrogate key.

In the example you gave, your drop down list would contain countries. From my perspective, if the dimensional model is based upon the star-schema then country would not become an independent dimension, but would instead be an attribute on another dimension (such as geography or customer etc). This would not require the surrogate key to be included even if you were to add one and therefore would be a waste of time, effort and storage.

If your dimensional model is based upon the snowflake or your key can be associated with more than one description (for example if the description can change over time) then yes I would include a surrogate key. I would not put this on the reference table though, the surrogate key should belong to the dimension that owns the data.