As others have mentioned, the correct answer is actually (a) for "binary data" only. Implicit conversions, while they work most of the time, shouldn't be relied upon, and in this case, it isn't doing what you think it is. You can specify an INT value when executing SET CONTEXT_INFO, but that isn't exactly what is getting "passed in", as the following test demonstrates.

Executing the following:

SET CONTEXT_INFO 12;

DECLARE @ImplicitConvert VARBINARY(128) = 12;

SELECT CONTEXT_INFO() AS [FullValue],
       CONVERT(INT, CONTEXT_INFO()) AS [BackToInt],
       CONVERT(INT, CONVERT(BINARY(4), CONTEXT_INFO())) AS [BackToIntViaBinary(4)],
       CONVERT(VARBINARY(128), 12) AS [ExplicitConvert],
       @ImplicitConvert AS [ImplicitConvert];

Returns:

FullValue                 BackToInt   BackToIntViaBinary(4)   ExplicitConvert   ImplicitConvert
0x0000000C00000....0000   0           12                      0x0000000C        0x0000000C

I partially truncated the "FullValue" value as we don't need to see the remaining (out of 128) bytes worth of 0's. But as you can see, an INT was passed in, but you cannot get the INT back out unless you truncate the value down to the 4 bytes of an INT. While the "12" is correctly (implicitly) converted to 0x0C, it seems a bit misleading to say that this "works". But along those lines, even just saying "binary" data isn't enough since explicitly converting to VARBINARY(128) has the same effect as when passing in just "12".

The only reliable datatype to set CONTEXT_INFO to, where you get out exactly what you put in, is BINARY(128), as you can see below:

DECLARE @Bin128 BINARY(128) = 23;
SET CONTEXT_INFO @Bin128;

SELECT CONVERT(INT, CONTEXT_INFO()) AS [BackToInt];
-- 23

Take care,
Solomon..