"Pointer to pointer to int issue"

Answer C is closest to being correct. The line

free( *ppInt2 );

is definitely incorrect. The error is not one that can be detected by the compiler. But it is quite likely to cause a run-time error. (But it is not guaranteed to cause a run-time error. More on this below.)

The rule for malloc and free is pretty simple: every pointer you hand to free must be exactly one that you received from a previous call to malloc (or calloc, or realloc). In the code, the malloc and free calls for pInt and ppInt1 correctly follow this rule. But for ppInt2, the pointer returned by malloc is assigned to ppInt2, but the pointer handed to free is *ppInt2, the value pointed to by ppInt2. But since *ppInt2 -- that is, the value pointed to by ppInt2 -- hasn't been initialized in any way, it's a garbage value, which free is likely to crash on. The end result is more or less exactly as if you had said

int main()
{
    int *p;
    free(p);     /* WRONG */
}

But, again, a crash is not guaranteed. So the more correct answer would therefore be worded as

C' - free(*ppInt2) is not correct. It’ll likely give a run time error.

I'm afraid that someone who says that answer D is correct may not really know what they are talking about. I would suggest not continuing further with this quiz -- who knows how many other wrong or misleading answers it contains?

It's always hard to understand undefined behavior, because undefined behavior means that anything can happen, including nothing. When someone says "I heard that doing X was undefined, but I tried it, and it worked fine", it's just like saying "I heard that running across a busy street was dangerous, but I tried it, and it worked fine."

The other thing about undefined behavior is that You have to think about it, and understand it, carefully. Pretty much by definition, no language translation tool -- no C compiler or other tool -- is guaranteed to warn you about it. You have to know what's undefined, and what to therefore steer clear of. You can't say "Well, my program compiles without errors or warnings, and it seems to work, so it must be correct." In other words, you can't try to foist the "correct vs. incorrect" determination off onto the machine -- you have to own this distinction.

But perhaps you knew all that. Perhaps the real question is simply, "If answer C is correct, how can the program not fail with a run-time error, in fact how can it repeatedly not fail?" This question has two answers:

1. As mentioned, undefined behavior means anything can happen, including nothing (i.e. no errors), including nothing on multiple successive runs.

2. On many systems, the first time malloc gives you a pointer to some brand-new memory, it's always all-bits-0 (that is, more or less as if you'd called calloc). This is absolutely not guaranteed by the C Standards -- you should never depend on it -- but on those systems, it's so likely that it might as well be guaranteed. Furthermore, on virtually all systems, a pointer value that's all-bits-0 is a null pointer. So, and again only on those particular systems, and again only the first time malloc gives you a pointer to brand-new memory, the code ppInt2 = malloc(10 * sizeof(int*)) will give you 10 null pointers. And since free is defined as doing nothing if you pass it a null pointer, in this specific case, free(*ppInt2) will never fail, not even at run time. (Perhaps this is what the person setting the quiz had in mind, because if you make these additional assumptions, answer C as written is basically not correct, and answer D basically is -- I hate to admit this -- more or less accurate.)

Returning to an earlier analogy, if someone makes these additional assumptions, and notices that the code never fails, and tries to claim that answer D is correct instead, it's basically like saying, "I heard that running across the street was dangerous, but I tried it in the middle of the night, and it worked fine. I even ran back and forth ten times. I never got hit by a car, not even once". And, unfortunately, there are programmers out there who follow similar logic, who will write programs that do the C programming equivalent of running across the street at all times. And these programmers then complain, as if it's not their fault, when inevitably their luck runs out and there's a horrible, fatal crash.