The second option is far better for the purposes of data structure, it allows more sophisticated querying (what if you ever wished to do a JOIN with option #1?), data mining etc. It also allows better extensibility, you should look at the columns being the denominators of your data, and your rows being RAW INFORMATION. Without the column header, you would not be able to interpret the raw data on its own, and/or it variability.
Look at it like this, for one thing- if you wished to add a new config- the overhead of doing so in option#1 is less practical than with option#2. You would need to add a new column in your table, then (likely) update all your SQL statements that reference the table to be aware there is a new column. If you add a new config in option#2, it is merely a new row, your table structure remains the same so your implementation of it within your code remains unchanged.