While I think making the code table driven is a reasonable idea, I think you're doing that (mostly) the wrong way.

If you're going to go beyond the obvious solution (e.g., @DanienMeSer's), you should accomplish something by doing so. The obvious problems (IMO) with the original code are that it's not very extensible (e.g., if you had 50 cases instead of three, you'd probably need to rewrite entirely), and it doesn't separate concerns very well (e.g., the logic and the I/O are quite tightly intermingled).

At least IMO, the key here is ensuring that each function (including main) has a clearly defined purpose and layer of abstraction at which it operates. If it delegates everything to lower layers, then it's not doing anything to justify its own existence. At the opposite extreme, doing everything in one layer/function means you're not actually using functions, classes, etc., to keep the code simple and manageable.

With that idea in mind, I'd start by thinking about what the ideal top-level code would look like, then write the lower layers to support that. In this case, it seems to me that it makes sense for the top layer to generate inputs, and write out the result for each:

for (int i=start; i<end; i++)
    console.WriteLine(fizzbuzz(i));

That's pretty simple, but it still accomplishes something useful: it generates inputs, writes outputs, and isolates logic from I/O. This is a decided contrast to a Main that just contains a single function call to doEverything(); (usually under some other name) that just forces the reader to navigate through more code before they find anything meaningful.

From there, we obviously need to define the fizzbuzz function to do the dirty work:

string fizzbuzz(int i) {
    // logic here
}

We have two choices for implementing that. One is mostly monolithic, but still make use of your table to produce the values:

string fizzbuzz(int i) {
    string ret;
    foreach (var comb in combinations) {
        if (i % comb.Item1 == 0)
            ret += comb.item2;
    }
    if (ret.Length() == 0)
        ret = i.toString();
    return ret;
}

Personally, I think I'd break that up into two pieces though: one that's a simple map from multiple of 3/5 to "fizz"/"buzz", and the other to provide a default value in case the first "fails":

string check_mult(int i) {
    string ret = new String();
    foreach (var comb in combinations) {
        if (i % comb.Item1 == 0)
            ret += comb.item2;
    }
    return ret;
}

...then the second, with the full fizzbuzz logic, which is now pretty trivial:

string fizzbuzz(int i) {
    string ret = check_mult(i);
    if (ret.length() == 0)
        ret = i.toString();
    return ret;
}

I'd note that these also give us some building blocks that at least at first blush look like they stand at least a little chance of being useful. One maps multiples of arbitrary numbers to arbitrary strings, and another attempts to map numbers to strings, with a default of mapping the input directly to a string if the first fails.

If you wanted to make this a bit more generic, you'd put just a bit more of the logic into the table, so the first element in the tuple was an object instead of just a value. Then instead of dealing only with multiples of specified values, you could deal with an arbitrary function of an input value. I'll leave that modification for somebody else to deal with though.

First of all I think Daniel MesSer have made some strong points although if you are going for something simpler and more readable I think this approach is even more easy to read:

for(int i = 1; i <= 100; i++) 
{
    string output = null;

    if (i % 3 == 0)
    {
        output += "Fizz";
    }

    if (i % 5 == 0)
    {
        output += "Buzz";
    }

    if (output == null)
    {
        output = i;
    }

    Console.WriteLine(output);
}

Although it is possible to replace the last if with the ?? operator, this is the most readable version, in my opinion.

If there are compelling reasons to introduce a table we could use more or less the same solution. The advantage with this solution is that I've gotten rid of the bool but instead I use a variable that holds the printout for each number. Another benefit of this solution is that I only need to have one call to Console.WriteLine instead of multiple calls to Console.Write / WriteLine embedded in the logic.

var combinations = new Tuple<int, string>[] 
{ 
    new Tuple<int, string> (3, "Fizz"), 
    new Tuple<int, string> (5, "Buzz"), 
};

for (int i = 1; i <= 100; i++)
{
    string output = null;

    foreach (var comb in combinations)
    {
        if (i % comb.Item1 == 0)
        {
            output += comb.Item2;
        }
    }

    if (output == null)
    {
        output = i.ToString();
    }

    Console.WriteLine(output);
}

You could get rid of the foreach and replace it with a LINQ expression but i doubt that the majority would find it easier to read.

var combinations = new Tuple<int, string>[] 
{ 
    new Tuple<int, string> (3, "Fizz"), 
    new Tuple<int, string> (5, "Buzz"), 
};

for (int i = 1; i <= 100; i++)
{
    string output = combinations.Where(combination => i % combination.Item1 == 0)
                                .Aggregate((string)null, (sum, value) => sum += value.Item2);

    if (output == null)
    {
        output = i.ToString();
    }

    Console.WriteLine(output);
}

For fun, why not make the whole thing unreadable by making it into a single LINQ expression:

var combinations = new Tuple<int, string>[] 
{ 
    new Tuple<int, string> (3, "Fizz"), 
    new Tuple<int, string> (5, "Buzz"), 
};

Enumerable.Range(1, 100)
          .Select(i => combinations.Where(combination => i % combination.Item1 == 0)
                                   .Aggregate((string)null, (sum, value) => sum += value.Item2) ?? i.ToString())
          .ToList()
          .ForEach(Console.WriteLine);

You are clearly moving away from what I would call the "clean and simple" approach with your solution. From your description I understand it as if this is how you would solve the problem, given that someone asked you to do it for an interview.

I strongly believe that your solution is overcomplicated for this problem, and too many assumptions are made on your side on how the problem will evolve in the future. Doing stuff like this is in contradiction to the software principle called KISS (keep it simple stupid), and due to these "assumptions" you are making it harder to read, understand and change the code.

I will post the original/clean solution that I think is much better suited for this problem, and then I'll follow up with a short description of why I think the "clean" solution is better than yours.

Clean Solution:

for(int i=0; i <= 100; ++i) {
    string s = ""

    if(i%(5*3) == 0) {
        s = "FizzBuzz";
    } else if (i % 3 == 0) {
        s = "Fizz";
    } else if (i % 5 == 0) {
        s = "Buzz";
    } else {
        s = i.ToString();
    }
    
    Console.WriteLine(s)
}

In the clean solution, it is clear what is happening and what values we check for (even the 5*3-value). In your solution you hide away the only thing interesting in this code (the replacement of strings for numeric values).

You make it harder to grasp what is happening by placing the values and the strings into an unnecessary Tuple-object and hide these important values behind something called comb.item1 and comb.item2.

The only time your solution would make sense is if it's known that the next iteration would require 25 replacements in similar fashion (7="Foo", 11="Bar", 77="FooBar"). However, then you would still run into problems and have to handle the "multiple match" issue in another way [e.g. 357].

The entire idea with programming is to keep the code as easy/clean as possible (good book: Clean Code_ by Martin Fowler) and avoid making "smart solutions" when it is not known what to expect next. Writing overly complicated solutions is something that would make warning bells go off for any recruiter.

Your solution makes it easy to add more replacements, but next iteration might as well be:

replace anything dividable with 9 with 'bazzinga' and then don't bother with fizz and buzz. Unless program is running on a Sunday, Sundays are as everyone knows 'Happy Sunday Sharing'-day, and string should then read 'FizzySundayBuzz' or 'FizzySunday'.

Since you are printing at the same time as you are trying to figure out if it was found, then no, you cannot. If you do not mind using higher level approach such as Linq, then here is my version below. It just might be a tad faster for large number of combinations if Console.Write and Console.WriteLine are slow.

namespace FizzBuzzTest
{
    using System;
    using System.Diagnostics.Contracts;
    using System.IO;
    using System.Linq;

    public static class FizzBuzz
    {
        private static readonly Tuple<int, string>[] combinations = new[] 
        { 
            new Tuple<int, string> (3, "Fizz"), 
            new Tuple<int, string> (5, "Buzz"), 
        };

        public static void PrintFizzBuzz(
            TextWriter textWriter = Console.Out,
            int start = 1,
            int end = 100)
        {
            foreach (string value in GenerateFizzBuzz(start: start, end: end))
            {
                textWriter.Writeline(value);
            }
        }

        public static IEnumerable<string> GenerateFizzBuzz(
            int start = 1,
            int end = 100)
        {
            Contract.Requires(start >= 0, "Negative start value is not allowed.");
            Contract.Requires(end >= 0, "Negative end value is not allowed.");
            Contract.Requires(start > end, "Start must be greater than end.");

            for (int i = start; i <= end; i++)
            {
                var humanReadableTokens = from cmb in combinations
                                          where i % cmb.Item1 == 0
                                          select cmb.Item2;
                string humanReadableStr = String.Concat(humanReadableTokens);
                yield return humanReadableStr == String.Empty ? i.ToString() : humanReadableStr;
            }
        }

        public static int Main(string[] args)
        {
            PrintFizzBuzz();

            // PrintFizzBuzz(textWriter: Console.Error);

            // Or you can create your own subclass of TextWriter which gives you the ability to read and clear its buffer if you want to test FizzBuzz.
            // var testWriter = new testTextWriter();
            // PrintFizzBuzz(textWriter: testWriter);
            // Assert somethng about testWriter.Buffer
            // testWriter.ClearBuffer();
            // Reuse the testWriter object for further testing. 

            // Or you could take the values in from command line if there are exactly two integers.
            // Parse(...);
            // DoFizzBuzz(start: start, end: end);

            return 0;
        }
    }
}

One functional approach making use of new c# could look like:

foreach (int i in Enumerable.Range(1, 100)){
   Console.WriteLine(
        (i % 3, i % 5) switch {
            (0, 0) => "fizzbuzz",
            (0, _) => "fizz",
            (_, 0) => "buzz",
            _ => i
        }
    );
}

Here my proposal, somewhat similar to @euan jones, but use ternary operator to implement "the switch" with old syntax (so no need of boolean, sequence of ternary operators became your evaluation function) :

public static void FizzBuzz (int limit, int fizzNumber, int buzzNumber)
{
    for (int index = 1; index <= limit; index++)
        Console.WriteLine((index % fizzNumber == 0 && index % buzzNumber == 0) ?
                                "FizzBuzz" :
                                (
                                    index % fizzNumber == 0 ?
                                        "Fizz" :
                                    (
                                        index % buzzNumber == 0 ?
                                            "Buzz" :
                                            index.ToString()
                                    )
                                )
                        );
}