Private VLANs
Private VLANs are another thing that you might not see where you work. The concept is simple. You have a Primary VLAN that is promiscuous that can talk to everyone. Then you have Secondary VLANs that are either Community [can talk among themselves and to the Primary] or Isolated [can only talk to the Primary]. Of course, different Secondary Community VLANs can't talk to each other and that's about it.
For the Written Exam, the material in various study guides pretty much accurately and adequately prepares you for just about anything they would throw at you as a question. However, there are a number of caveats that crop up when you practice for the Lab that might make you at least scratch your head, if not pull your hair out.
CAVEAT: Private VLANs require vtp transparent mode. So that's the first thing you need to do - since the default is vtp server. Also remember in your particular environment - if you have a transparent switch in the path of Servers and Clients, it can cause problems. There is another post that discusses this type of VLAN Nightmare about halfway down the page. My advice to avoid the nightmare is to configure your Layer 2 foundation with all the switches as vtp servers and then go back at the end of the Layer 2 configuration and adjust as needed. However, you often hear the advice "Read the entire Lab Scenario completely before you start configuring." This is another one of those reasons. If you need to use vtp transparent mode to configure Private VLANs, you want to know this up front. In that case, use NOTEPAD so you can set all the switches to transparent and then copy/paste all the VLANs on each switch. I can't emphasize enough to use Notepad to plan your configurations. You don't want to miss a VLAN on just one switch.
CAVEAT: The order of operations is important here. If you try to configure an association for a VLAN that is not yet configured, you will get no error message and the config will not appear. The switch will simply ignore you. You will finish your configuration and look at it - and what you thought you configured is missing. Although it won't 'break' anything, it will waste time. Get in the habit of doing as much as you can correctly the first time.
As you are learning/practicing, use the Configuration Guide to help you. That helps you to remember where to find it in the documentation if you need to find/use any obscure details about the configuration. It also has a lot of really good information which can help you understand why you are doing what you're doing.
So start with configuring the switches as vtp transparent. Then create your VLANs. Just create the VLANs and make them private. Do not try to associate anything yet. 
If you look at what I have in Notepad, you'll see that I put the name of the switch and then what I need to configure beneath it. Then I can copy/paste for the next switch and adjust as needed in Notepad. Prep the "set" of switches and then Paste each configuration 'batch.' Again, it saves time and allows you to focus on the bigger picture.
Once you have the VLANs created, then associate the primary with your secondary VLANs:
vlan 100
private-vlan association 100 1000,2000,3000
CAVEAT: Notice the commas in that command. If you try to do each separately:
vlan 100
private-vlan association 100 1000
private-vlan association 100 2000
private-vlan association 100 3000
What will happen is that each command will overwrite the previous one and you will end up with only VLAN 3000 associated with the Primary VLAN. Now, if in the 'real world' you have an existing association, you can use the command private-vlan association [add | remove] to add and remove Secondary VLANs without overwriting your current configuration. At this point, check your work with the "sh vlan priv" to make sure that your VLANs are properly configured and associated. Note that no ports are listed yet. You will want to use this command again once you finish configuring your ports to see them listed in the correct spot.
Next configure your switchports that will use the Secondary VLANs. Again, use Notepad since all the secondary ports will be configured similarly. You can copy and paste and then just change the interface number and association.
int fa0/2
switchport private-vlan host assoc 100 1000
switchport mode private-vlan host
Then go to your promiscuous port (or ports). This one is a little different:
int fa0/1
switchport private-vlan mapping 100 1000,2000,3000
switchport mode private-vlan promiscuous
Once you have all that mapped out in Notepad, copy and paste into your switches. Keep an eye out for any typos or syntax errors you may have made. If you made a mistake anywhere, correct it in the Notepad layout so the other copy/paste operations go smoother.
Now to test. Yes, you should always test. It takes a bit more time, but you really need to get Layer 2 working solidly because the rest of your exam builds on that foundation. To help speed things along and make sure you have the proper connectivity, use a tcl script. Don't panic, it's not that hard. You start at the enable prompt. In Notepad, you would set up:
tclsh
foreach x {
10.15.100.1
10.15.100.2
10.15.100.3
10.15.100.4
10.15.100.5
10.15.100.6
} {ping $x}
When you copy and paste that into the switch, you will see the prompt change and then disappear. The "tclsh" puts you into a tcl shell mode which changes the prompt to SW1(tcl)# . Then after you enter the line "foreach x {" which starts the list of items, the usual prompt (that you're used to) will disappear and be replaced by "+>" which is indicating to you that you are in "list your items" mode (my term).
Once you hit enter after the last line, your "script" will run. The nice thing about this is that each ping completes before the next one starts. The bad thing about this is that each ping completes before the next one starts. If all the items in the list have connectivity (like they should at the promiscuous port), it will execute very quickly. However, you will notice that the results at the isolated ports (which should only be able to ping the Primary and themselves) will take a longer time to complete. In some ways that's a good thing because it gives you time to see which ones have connectivity. Do a "sanity check" to make sure that the devices that should be able to reach each other can do so - but also that the ones that should not be able to reach each other (most importantly) fail to ping.
CAVEAT: When you have completed your ping test, exit out of tcl using the command tclquit . You want to do that while you're thinking about it rather than leave it for later. You could get caught up in something else and forget. This would be disasterous for you. Tcl commands are interpreted first and some tcl and IOS commands are the same. Some (most) of the R/S lab will be graded by a proctor using a script. It is expecting the devices to be in cli mode, not tcl mode. It could very well screw up your grading if you forget to exit tcl mode. And the proctor is not going to troubleshoot and 'fix' it for you. So make it a habit to exit tcl when you finish what you're doing. Good practices make for good performance.