Hit a homerun: preparing for the Professional Cloud Network Engineer certification
Tom Taggart
Solution Architect, Google Cloud
Obtaining and maintaining professional certifications is a big part of a successful career in networking. The process starts as an exercise in studying and testing and evolves into a benchmark of your experience, skill and ability. In a nutshell, the certs and the scars walk hand in hand.
The problem with certifications is that no one tells you exactly how to study—at least not efficiently and effectively. Ideally the process of learning and practically applying the knowledge you gain should be interwoven and mutually reinforcing.
I know all this because I’ve lived it all during a long career in networking, over the course of which I’ve obtained, refreshed, and acquired new certifications to follow industry trends, including multiple expert-level ones from Novell, Microsoft, and Cisco Systems. When it was time to stop refreshing those and let them expire, I did so and sailed boldly into the cloud. I now have several cloud certifications including the AWS Certified Advanced Networking - Specialty and Google’s Professional Cloud Network Engineer.
In this post I’m going to share with you a methodology I developed and used over and over again throughout the years for preparing to take a certification exam and learning new material. I call it the “Home Run Method,” based on the idea of hitting a home run and running all the bases in American baseball. When you hit the ball you start running with all you’ve got and you have to work diligently to touch all the bases. If you miss one or the ball gets to a base before you do you are out and have to start all over again. This framework will help you organize your study time in a very efficient manner and support a deep understanding of the material. This is crucial because after you are certified you have to be the expert your certification says you are.
Create your batting list
Well before the first pitch, a baseball game starts with the manager creating their lineup— the players and the order in which they go to bat. Likewise, when preparing for a certification, you need to make a master list of the features and products you will be studying. You derive this list from the Professional Cloud Network Engineer exam guide and the GCP Console navigation menu. Review the information you collect and cross check against the product documentation to fill in any knowledge gaps you have. For example, if you’re studying for the VPC topic, your list might look something like this:
Virtual Private Cloud
Overview
VPC Networks
Networks and Subnets
Auto mode vs Custom mode
Subnets and IP ranges
Primary address range
Secondary address range
Reserved IP addresses
Auto mode IP ranges
VM IP addresses and interfaces
Internal IP addresses
External IP addresses
Alias IP address ranges
Multiple network interfaces
Firewall Rules
Default and implied rules
Additional rules in default network
Always blocked traffic
Rule components
Source and target filtering by service account
Service account vs network tag filtering
Firewall Rules logging
Routes
Route types
Default
Subnet
Static
Dynamic
Applicability and order
Static route parameters
Next hops
VPC network peering
Shared VPC
Special configurations
Private access
Proxy VM
NAT VM
VPN VM
This list will be your study guide, a complete list of the topics that you need to master. For the remainder of this blog I’ll use the Firewall Rules feature as an example. I also assume that you have set up a GCP account with two user accounts. The first account is your organization owner. The second account represents a security admin account that does the configuration.
Step up to home plate
The players have taken the field, and the game is underway. Time for the first batter (you), to take a swing at the balls (topics) coming your way.
Step one is to familiarize yourself with the feature you are studying. You always start this part by drafting up a description of the problem the feature solves or writing out the question the feature answers—basically defining the why of the feature. You may be able to do this right away or you may have to do some research. You don’t need an exhaustive list of whys, just one business problem that the feature solves. For our Firewall Rules example, here are some of the high-level questions you might ask :
How do I implement the idea of least common privilege and protect my VM instances unauthorized traffic streams?
How do I make sure only valid traffic streams get to my VM instance and that exploratory, accidental, or malicious traffic streams get blocked?
Once you have a feel for why the feature exists, you need to gain a holistic view of the feature on GCP. You can do this by:
Reading the concept documentation for the specific feature to get a high level understanding.
Reading any related quota documentation, scanning for your specific feature, to find if any default limits exist and if they are negotiable.
Reading the pricing documentation for the feature or parent feature to make yourself aware of how the feature does or does not impact your monthly bill.
Researching if there is any IAM documentation for the feature.
Quickly scanning the release notes and searching for the feature specifically to get a feel for history and delivery timelines.
Finally, take a step back and think about any security implications for the feature. For example,
If I don’t configure any firewall rules I am not conforming to the security best practice of principle of least privilege.
If my firewall rules are too aggressive I could shut out authorized traffic.
If a rule is incorrect I could let in bad traffic or keep out good traffic.
Could an IAM mistake lead to giving someone firewall rule creation/editing access?
The idea here is to simply explore security at a high-level. It’s a brainstorming exercise to stretch your thinking in regard to a feature and its business impact. You always want to have a good sense of how a piece of technology solves a problem and any incidental implications that come along with it.
Heading to first base
You’ve taken the first swing, and it was a hit! Your journey around the bases has now begun in earnest. Now you need to learn how to configure the feature. If you read point four of my last blog you know that you can use the API, SDK, Console, or one of several client libraries to configure your cloud environment. For our example, we’ll use the documentation for the SDK and Terraform, a popular open-source provisioning and config management tool. The process looks like this:
1. Log into the GCP console as your security admin user.
2. Check your quotas to make sure you are not approaching an upper bound.
If you are approaching an upper bound you can request additional quota.
Try to execute a few SDK commands. Notice that they fail. This is because you have not assigned the appropriate IAM security roles.
Log in using the Owner account.
Assign the security admin account the appropriate custom IAM roles.
Log back in as the security admin.
Use the SDK gcloud commands as you go and sanity check what you do by reviewing how to do the same thing on the console.
What you really want to get a strong feel for is how the SDK commands are formatted and what options are required. Here’s an example:
You’ll notice that the first line states what the command is going to do. In this case, the command creates a firewall rule. The following lines are all options that tweak how the firewall rule is implemented, one option per line. You’ll also notice that every line except the last ends in a backslash. This is an old Unix shell interpreter technique. The backslash is escaping the end-of-line character that occurs when you hit the enter key. This allows you to spread a long or confusing command line across several terminal lines for easier reading.
5. After you’ve read the documentation, used the SDK commands, and sanity checked with the console, go back and implement all the SDK commands with Terraform. The above SDK command yields the following Terraform resource:
The last part of this step is the most important. In traditional networking most work is done from the command line in an imperative paradigm. Moving to the cloud really opens the door to a declarative network management. It’s crucial to get a feel for the pros and cons of the declarative approach and evolve your skills in that direction. Terraform also has its own idiosyncrasies that you’ll want to get a feel for.
Rounding second base
By now, you’re running hard, but you need to check for signs of trouble—will the ball be thrown back to second base before you get there and stop you in your tracks?
In a perfect world, nothing stands between you and your goal, and computers and software do what you tell them to do all the time. In the real world, where errors happen and people make mistakes, there are times when software winds up in a state in which it was not originally configured. So in this next step you go through the exercise of verifying how a feature is actually configured: finding its running state.
The best way to validate state is to use both the SDK and the console. You can find a detailed list of the SDK commands for doing this here. For our firewall example you can use the following commands:
The list and describe arguments will give you high-level and low-level details, respectively. You also want to explore gcloud topic formats, specifically the --filter and --format options. Doing so will give you a strong command over what is presented in the output.
The following Terraform command is also useful, giving you a list of resources that have been successfully created:
As a final step, sanity check the configuration in the GCP console.
Passing third base
The end is near; you can practically feel the high-fives your teammates will give you when you cross home plate. But now’s not the time to pat yourself on the back; you need to keep running full steam ahead, and dig deep to understand your chosen topic. Specifically, once you’ve gone through the exercises of configuration and verification, it’s time to look at monitoring and troubleshooting a particular feature. There are three areas where you want to look for troubleshooting tooling:
Any SDK options
Google Cloud-based tooling
Third-party tooling
There are many options. The idea is to explore what is available and how it works. Troubleshooting is where you can learn the most about how a feature really works, and understanding that distinguishes you from people who only know how to configure a feature. Given the firewall example here are some of the available options:
SDK
For monitoring and troubleshooting traffic affected by a Firewall Rule you can enable Firewall Rules logging. The --enable-logging option turns on logging in Stackdriver:
Third-party tooling
For deeper packet-based inspection on VMs you can use tools like tcpdump or Wireshark.
Terraform debugging can also come in handy when troubleshooting deployment issues.
Google Cloud tooling
For a broader discussion of alerting, monitoring, debugging, error reporting and building management dashboards, check out the Stackdriver documentation. Stackdriver is a Google Cloud product all in itself and a deep dive is outside the scope of this blog, but you will want to block out time to learn Stackdriver well.
Sliding into home plate
Endings need to be as crisp as beginnings. You don’t lollygag into home base—you slide in with purpose. For your final step you’ve come full circle and are about to take the test. Now’s your time to review and tie up loose ends:
Quickly review the concepts, pricing, quota, and IAM documentation that you read more closely in the first base phase.
Use the GCP Console as a quiz tool. Look at all the options given to configure a feature. Are there fields you don’t understand or missed? It’s good to do this with the SDK commands as well. If you see something that you don’t understand, a field, an option, go back to the Concepts and How-to Guides. You may even have to do a little more internet research. The idea is to catch any soft spots in your understanding and address them right away.
If there are details that you want to commit to memory note them and use spaced repetition software such as Anki to help you practice.
Remove and deconfigure any resources that you created during your study. You don’t want to forget and leave VMs or other cloud features running that may incur costs.
OK, you’ve come a long way with one feature. Now it’s time to select the next one on your list and start the whole process over again.
That’s the whole process. It works. If you follow it methodically and tenaciously you’ll have a much deeper understanding of Google Cloud networking and you’ll be that much closer to getting certified. It’s now time for you to go start building your study roadmap by checking out the Professional Cloud Network Engineer exam guide. We are also offering one month of free access to Networking in Google Cloud Platform Specialization on Coursera to help you prepare for the exam. Also, be sure to checkout Network Performance and Optimization hands-on labs on Qwiklabs. Go ahead and step up to the plate!
