That's a pretty cool story, I say definitely nurture her technical side. I've noticed that in the west, especially America, there's a subcurrent of almost discouragement for girls to be interested in technology. It's vague, it's subtle, but it's certainly there. You just need to counteract any potential crap she might get, primarily from people in TV marketing. it sounds like you're doing a great job already so I don't really need to say any more on that.
It does remind me though how on Spiceworks and even in my own IT company, that when there's a service disruption similar to yours or a machine cannot talk to the world, they don't go through the OSI model and check everything one by one. Doing that saves a lot of time, because I think IT people often simply assume it's always either bad cable or software misconfiguration/failure on the machine itself, not potentially each layer in between. A similar situation happened a few months ago, where a network switch went bad at one of our offices so the connections to a few servers suddenly vanished.
One of our novice employees decided to hard reboot all of the VM hosts he couldn't contact, which was 4 out of about 12 total. Everything presumably came back up and started as it's supposed to, but it still didn't work, and he and someone else were having a hell of a time trying to figure this out. They called the office manager who was out and he suggested checking the switch, and they did, and it still didn't work. The other guy was pretty busy as well, otherwise the rest of this story probably wouldn't have happened.
So this young guy hard resets the machines again, and still nothing, so finally he calls me. As a general rule, you're never supposed to call me unless it's a major problem and nobody can figure it out.
So, he tells me all that happened, and the first thing I said to him, verbatim was:
Don't you think if the network connections to multiple physical machines stopped working, it wouldn't be the machines, but probably something else?
Oh, yeah, I guess that makes sense, I just assumed it was the hosts.
So, I told him to go through the OSI model, use it as a general guide, and check everything and told another guy there to make sure he did it right and understood checking doesn't mean looking to see if the light is on. During the first stage, they figure out it was is the switch that had gone bad. It still lights up, it seems like it works, but it simply doesn't. They changed it out and everything came back up.
Except... email, the hard rebooting really messed with Exchange, and even thought it was spanned across three servers with DAG, it flipped out. That wasn't hard to sort out, obviously and things were back to normal in no time.
Checking each thing first and knowing whether or not it works is a good way to go about it, and I think a lot of young people especially forget that. In a sense, if it's not something I can fix right through this terminal and it's still plugged in, then it's completely broken.
You may be wondering also why there wasn't teaming with multiple switches. Actually, there was, however they were in the process of moving the machines to the other server room across the building, so it was a situation of the bare minimum being there just for that day until after EOD. It was a hell of a time for the switch to go out, but it taught this guy a powerful lesson.
I didn't fire him, though he thought I was going to. I told him "that's why you're paid what you are, it's entry level, any of the other guys made the same mistake they'd probably be fired, primarily for the idiotic hard rebooting thing. Next time think about the problem, and go down the OSI model list, and never, ever hard reboot anything unless you know for certain the machine is hung up."
I guess that was kind of long, but I also see people on Spiceworks running into this thing a lot too. Sometimes I jump the gun myself and then when my initial suspicions are wrong, I remember to go back to the list.