Hello again! I hope you all had a great Valentine’s Day weekend! As mentioned in my tweet last week, I skipped last week to finish out my first pass of the blueprint. The topics we will be looking at this week will focus on most of section 4.0 – Application Deployment and Security and all of section 5.0 – Infrastructure and Automation. This closes out the remaining DEVCOR exam topics, so stay tuned for my complete DEVCOR exam blueprint impressions later in this post.

Introduction

Thank you for being patient with my posting schedule this past month. These exam topics have been extremely tough. In particular, the remaining topics in section 4.0 revolved around security, and I don’t mean encryption/hashing methods, routing protocol authentication, or how to configure IPSec tunnels. These security topics involved how an application is deployed and is accessed by the end user. If you went through college/university, you most likely had at least one IT security course that mentioned topics around OWASP threats (cross-site scripting (XSS), CSRF, SQL injection). If so, crack open that old textbook because that is exam topic 4.10 – Implement mitigation strategies for OWASP threats. Along with that example, there are specific topics for configuring SSL certificates (4.9), implementing a logging strategy for an application (4.6), and explaining privacy concerns (4.7). These topics really shift your mindset towards the “Dev” part of “DevNet” (sorry, I had to). Now let’s jump into the topics!

Week 5 and 6 Topics

There are many topics to cover. Here’s the entire list of topics we will be covering this week, straight from the blueprint:

I will not be able to dive into each of these topics, but I will talk about each of them within general categories. For example, 4.3 – 4.4 relate back to my week 4 topics surrounding application development. Sections 4.5 – 4.11 all surround application security. All of section 5 (5.1 – 5.5) involves infrastructure automation using telemetry, automation platforms (Ansible/Puppet), and building apps ON the network devices using IOx. Now that we’ve grouped each of these topics, let’s take a look at each category.

The application development topics in section 4 were very interesting. I learned how to develop an application using Docker/Kubernetes and deploy it using a CI/CD pipeline. After learning each of these topics, you start to understand at a high-level how companies are agile in their code development, while also maintaining proper checks and balances using CI/CD. I don’t know about how others felt while reviewing these topics, but before learning about these technologies, I never saw an application more than one large monolithic app. I never really considered all the microservices that make up a large website such as Amazon, eBay, and many others. Docker and Kubernetes allows developers to manage all aspects of their dev environment without needing to provision multiple VMs, which ultimately reduces time. It also allows developers to modularize their app so that devs can work on different aspects of the same app (i.e. login, shopping cart, etc.) at the same time. This allows for more updates and innovation for each of these individual components, since a group of developers can be dedicated to that one component. To wrap it all up, I dove into the details of CI/CD. If you’ve read my other blog posts, you would’ve seen that I have some experience with CI/CD in GitLab for managing Cisco network devices in a virtual environment (EVE-NG) on Google Cloud Platform (GCP). I do not proclaim myself as a CI/CD expert or even a novice, but I would say I understand the importance of CI/CD and some of the steps that make a pipeline (build, test, deploy). I definitely enjoyed studying these topics and will be reviewing them again on my second passthrough of the blueprint.

Application security was by far the toughest set of topics to get through during my studies. Full disclosure: I skimmed over these topics vs the others. I purposely did this because I didn’t want to get caught up or discouraged while reviewing these topics, causing me to abandon my studies all together. My goal was to ‘check the box’ with these topics on my first passthrough and then hit them HARD on my second passthrough. I plan on dedicating multiple days for each of these topics on my second pass. I can openly say that these will be my weak points of this exam. A note to everyone reading, it’s important to identify your weaknesses when studying for a cert (and really anything in life) and know that you will have to focus more time on those topics than others. It sucks because these topics won’t be as enjoyable as the others, but you must do it. Even though these topics are my weakness, I did find them very interesting. In particular, the tenets of the “12-factor app” really helps open your eyes to the best practices of developing a secure app. This exam topic helps you elevate the existing scripts you may have created when studying for the DevNet Associate. You should no longer be hardcoding credentials in your scripts, and instead look at using environment variables. I’m glad the DEVCOR exam reviews this topic because I remember googling best practices for securely storing credentials. I had to look it up because I was using my scripts at my job to perform simple tasks, such as gathering CDP neighbor details. I didn’t want to store my TACACS credentials in plaintext within my script. This topic is just another example of how the DevNet Professional cert is preparing you for a career beyond developing simple, one-off scripts and focus more on implementing best practices of app development.

The last category of topics I reviewed was surrounding infrastructure automation. All the topics in this category make up section 5.0 – Infrastructure and Automation. This section felt more like home because I could relate to all the topics in this section. Many of the topics were high-level, such as explaining model-driven telemetry (MDT). MDT is made up of many components including RESTCONF/NETCONF, YANG data models, gRPC, and many other protocols that generate and transport the data to your monitoring server. So in order to explain MDT, you have to know the details of the underlying components. Other topics in this section include constructing workflows using Ansible and Puppet, identifying a configuration management solution based on certain requirements, and describing how to deploy an application on a network device using IOx. Let’s take a quick look at each of these other topics. Building a workflow using Ansible and Puppet was pretty natural for me. I’ve created many Ansible playbooks and understand the overall workflow using variables, roles, plays, and tasks. I have minimal experience using Puppet, but the DSL of Puppet Bolt was pretty straightforward and felt a lot like JSON. If you have not had any experience using Puppet or Bolt, I encourage you to take a look. Creating a simple manifest file (Puppet’s version of a playbook) can be less than 5 lines of code using certain modules. The last topic on the blueprint, 5.5 – Describe how to host an application on a network device (including Catalyst 9000 and Cisco IOx-enabled devices), is probably the most interesting topic in section 5. I think the idea of deploying an application (as a Docker container) on a network device is next-level. However, I’m struggling to understand the sustainability of this deployment model. I understand why you may deploy an app directly on a network device, whether for security, data processing, or even troubleshooting purposes. The issue I have is the maintainability of these applications and the operational responsibility. I’ve read from multiple sources that DNA Center is the obvious answer to maintaining the apps dispersed across all the Cisco Cat 9k devices in your environment. However, one big consideration is vendor lock-in. With the decision to use DNA Center as your automation platform of the future, you must consider the licensing and other commitments you are making to Cisco by integrating DNA Center. There is no wrong answer, it’s just a fact when committing to any tool or software. I personally find DNA Center as a great platform to centralize your automation efforts, as long as you are in an all Cisco environment or plan to refresh your existing infrastructure with Cisco Catalyst 9k switches. It has a very robust API and many built-in integrations to tools such as ServiceNow and Infoblox. The other question mark I have for deploying apps on a network device is the troubleshooting and triage efforts when things go south. Who’s ultimately responsible for the uptime of the app? What happens when the application goes down? What if the network team needs to upgrade the IOS-XE software on the switch, can the app take downtime? What if the switch loses power for a long period of time due to an outage? I know the answers to these questions will vary from organization to organization, but it brings up some considerations when creating a proper operational procedure for maintaining these apps. Overall, I really enjoyed all the topics in section 5 of the blueprint.

My Week 5 and 6 Impressions

I put a lot of my thoughts inline with each topic throughout the post, but let me highlight my impressions on each category of topics mentioned throughout this post. The application development topics, specifically CI/CD, were enjoyable to review. I already have some experience creating a CI/CD pipeline in GitLab, so studying this topic helped formalize my experience. The application security topics found in section 4 are going to be very tough for me. I know I will need to spend at least a week just on these topics. The last category of topics surround infrastructure automation. Like the app development category, the topics in this category came more natural, as I have some experience with MDT, configuring devices using RESTCONF, and tools such as Ansible. I do find the last topic in this section, deploying an app on a network device, interesting and hope to find more uses cases for this technology. As I always say, you should understand the WHY before figuring out the HOW.

DEVCOR Exam Blueprint Impressions

Now that I’ve completed my first passthrough of the entire DEVCOR exam blueprint, I wanted to provide my impression of the blueprint in its totality. As a whole, I find this blueprint to be very challenging. I think this exam really creates the foundation to becoming a developer. Like I’ve mentioned in a previous post, I found myself in a developer’s mindset throughout my studies. I wasn’t focused on specific networking concepts or technologies like in previous Cisco exams. I didn’t need to know the different timers of EIGRP or OSPF. I didn’t need to understand BGP. This exam really puts app development as front and center, with networking as a topic you’re looking to automate using best practices of app development. I look forward to my second passthrough of the blueprint and know that I’ll learn something new while reviewing these topics again.

Conclusion

Sorry for the long post this week, but we had a lot of exam topics to cover. With this post completing my high-level review and impressions of the DEVCOR exam blueprint, look forward to smaller posts in the future that will be more technical and focused on a specific DEVCOR exam topic. Beginning this week, I will be going through the entire blueprint a second time, but slower and with more focus. I will be using Cisco’s Digital Learning on-demand DEVCOR course as a study guide (check it out here). I’ve heard great things about it, so I figured it would be a great investment. I will most likely include reviews of the course in my future posts. Thank you for reading through this mini-series of my exam blueprint impressions throughout my DEVCOR journey. I look forward for you to stay tuned to my future posts that will continue my DEVCOR journey. If you have any questions/feedback, please hit me up on Twitter (@devnetdan)!