CompTIA Cloud+ CV0-003 Exam: Troubleshoot Deployment, Automation, and Orchestration Issues

This guide covers the following official CompTIA Cloud+ exam objectives:
Objective: Given a scenario, troubleshoot deployment issues.
Objective: Given a scenario, troubleshoot automation or orchestration issues.

In this guide you will learn some of the troubleshooting techniques used during deployments, automation, and orchestration. Recall that deployment is the process of implementing cloud resources. Automation is the process of making deployments streamlined by handling most or all of the deployment tasks automatically, without manual intervention. And orchestration is the process of deploying a collection of resources that are related to each other. (See “Automation Activities” and “Orchestration Sequencing” in “Automation and Orchestration Techniques” if you don’t recall the details of these topics.)
Note that CompTIA chose to make troubleshooting deployment issues a separate objective from troubleshooting automation or orchestration issues, but they are merged together in this guide because of how closely related these topics are.

Topics:
- Connectivity Issues
- Performance Degradation
- Configurations
- Applications in Containers
- Misconfigured Templates
- Missing or Incorrect Tags
- Insufficient Capacity
- Licensing Issues
- Vendor-Related Issues
- Account Mismatches
- Change Management Failures
- Server Name Changes
- IP Address Changes
- Location Changes
- Version/Feature Mismatch
- Automation Tool Incompatibility
- Job Validation Issue
- Patching Failure

1. True or false: DNS issues can affect network performance.
2. True or false: Configuration scripts can be in different formats, like JSON and YAML.
3. True or false: Tags are used exclusively for creating cost reports.
4. True or false: The regional location within a cloud vendor’s system has no effect on how the configuration of an orchestration tool functions.

Answers:
1. True
2. True
3. False
4. False

Connectivity Issues
Regardless of whether you are using an on-premises or vendor-based cloud infrastructure, connectivity issues can have a major impact on cloud performance. Some cloud vendors provide tools to help you determine if a network issue is related to connectivity. For example, Google Cloud provides Connectivity Tests.
For the Cloud+ exam, the primary focus is to know how to troubleshoot cloud service provider (CSP) or Internet service provider (ISP) outages. That is the main focus of the next section.

Cloud Service Provider (CSP) or Internet Service Provider (ISP) Outages
The cloud service provider is the vendor that provides the cloud services. To troubleshoot connectivity issues with a CSP, consider the following:
- The image below is an example of the AWS Service Health Dashboard. This site is a critical first step in troubleshooting connectivity issues to rule out the possibility of an unresponsive cloud service.
- If you are not able to access one of your cloud resources, verify that you are able to connect to other resources within the same cloud environment or network. You should determine if the connectivity issue is related to a specific resource or to all of your resources to narrow down the issue.
- If you can connect to where the resource is configured in the CSP environment, you should verify that the resource is configured correctly.
- Review cloud network configurations to determine that a network configuration isn’t the cause of the problem. This includes IP settings and security appliance settings, like NAC or WAF settings.
- Don’t hesitate to reach out to your support team at the CSP. Most organizations pay good money to have 24/7 support, and when you’re having connectivity issues, that is one of the times to take advantage of the support the CSP provides.


AWS Service Health Dashboard

Of course, the traditional network connectivity troubleshooting steps, tactics, and tools should also be used when troubleshooting connectivity issues with a cloud service provider. You should always consider a networking issue within your own network or with your Internet service provider.
Outages related to issues with your organization’s ISP will be easier to troubleshoot. The reason is that an outage with your ISP will have an impact not just on accessing your cloud resources but also on other network-based activity in your organization.
As with any network connection issue, the connection problems may not be something that your ISP controls. Check internal networking configurations and applications, such as firewalls and routers, to ensure that they are configured correctly. Contact your ISP immediately if connectivity issues persist.

Performance Degradation
In terms of networking, performance degradation refers to a decrease in response speed on the network. Network performance degradation can be caused by a number of different problems, including
- Increased bandwidth usage
- Poor physical connections
- Malfunctioning networking devices
- DNS issues
- ISP issues
- Quality of service (QoS) issues

Network performance degradation is often tied to an issue referred to as latency, which will be discussed in more detail next.

Network latency refers to delays in communication across a network. There are several metrics that you can use to determine if you have a latency issue, including the following:
- Round-trip time: This is the time it takes for a packet to be sent to another system and the response time of the return packet. Note that in this case the network packets should not require processing on the server because just the time to traverse the network is being evaluated.
- Server response time: This metric measures the delay caused by the application as well as the time it takes to traverse the network between the client and the server. Comparing this value to the round-trip time provides a better understanding of the cause of the problem because it can either be the network itself or a server response issue.
- Jitter: This is a value that describes a difference in the delay between packets. A high jitter value can indicate a network issue related to irregularities in packet flow.

Configurations
As previously mentioned, configuration errors in a network can have an impact on the performance of the network. Configuration errors can be the result of users manually configuring network resources, but they can also be the result of scripts, which are often used to automate the implementation of networks. Scripts will be covered in more detail next.

Scripts
Scripts provide a powerful function of automating the process of implementing a resource. They are often used to implement the complex components that make up a cloud network, including the IP address settings, security groups, WAFs, and other cloud network resources.

Although scripts are great for automation processes, they can result in hard-to-troubleshoot errors. When troubleshooting scripts, consider the following:
- Whenever possible, test scripts fully in a testing or development environment before deploying them in a production environment.
- Scripts may fail because of changes made by the cloud vendor. A cloud vendor may release new features for a resource or change existing feature options.
- Some vendors provide tools to validate scripts before you use them. Take advantage of these tools if they exist.
- Scripts are sensitive to syntax errors. In many cases, standard formats (JSON, YAML, and so on) are used, and these formats have syntax validators that you should use to discover errors.
- Don’t rely on third-party organizations to create your scripts unless you have a strong support contract. If no one in your organization understands the scripts you are using, when a script fails, you won’t have a way to troubleshoot it.

Applications in Containers
For more information on using applications in containers, see “Containers” in “High Availability and Scaling in Cloud Environments.”

Misconfigured Templates
For details about handling misconfigured templates, see “Templates” in “Integrate Components into a Cloud Solution.”

Missing or Incorrect Tags
A tag is metadata that is associated with a cloud resource. Tags are used for a variety of purposes, including
- Creation of cost reports
- Access control
- Automation operations
- Operational support
- Security risk management

Note that tags are typically key-value pairs. For example, you might have a key named “department” and a value named “sales” for a specific resource. Or you might have a key called “location” and a tag value named “US” for a resource.
When applied correctly, tags provide a huge benefit. However, when a resource is missing a tag or has an incorrect tag, this can result in problems. For example, consider a scenario in which a tag named “stage” is used to remove all of the resources that make up a cloud network. You perform an operation in which you want to delete all resources with a value of “test” for the tag named “stage.” If some of the resources in that network don’t have this key-value combination, they won’t be removed. Failure to remove them could cause issues with other resources in your cloud infrastructure, and it could result in additional charges to your cloud account for resources that are still active but not being used.

Insufficient Capacity
Lacking capacity can create issues in cloud resources because the resources will not be able to handle demands placed on the resources. All of the topics discussed in this section were covered in detail in earlier guides. As a result, see the following:
- Scaling configurations: See “Scalability” here and “Rightsizing” in “Optimize Cloud Environments.”
- Compute: See “Compute” here and “Virtualization” in “Compute Sizing for a Deployment.”
- Storage: See “Storage” here and “Storage System Features” in “Storage in Cloud Environments.”
- Bandwidth issues: See “Performance Degradation” and “Latency” in this guide, and “Bandwidth” here.
- Oversubscription: See “Oversubscription” here.

Licensing Issues
Licensing can be a complicated topic in cloud computing because licenses are based on different usages, such as per-user, socket-based, and subscription based. It is important to understand which license is being used, what limits are imposed based on the license, and how to best determine which license is best for your situation.
These issues were covered in - “Licensing” in “Capacity Planning.”

Vendor-Related Issues
When deploying in a cloud environment, you may be faced with issues that originate from the vendor. This section will focus on these issues.

Migrations of Vendors or Platforms
Recall from “Cloud Migrations” that vendor issues can be related to different platforms between vendors (or your on-premises solution); for example, those which can result in vendor lock-in. You might also face issues such as different storage or database solutions being provided by vendors that you are migrating to.

Integration of Vendors or Platforms
Recall that the “Integration” section of “Solution Design in Support of the Business Requirements” covered the topic of performing requirement analysis for the integration. It is during this analysis that you first troubleshoot potential problems with integrating your on-premises solutions with the cloud solutions that you are deploying.
Integration, however, is not a one-time function. In the future you will be adding, removing, and replacing on-premises solutions, and they will likely need to integrate with your existing cloud infrastructure. Additionally, whenever you remove, add, or modify an existing cloud resource, you will need to ensure that it doesn’t have a negative impact on your on-premises infrastructure.
One way of troubleshooting potential integration problems is to deploy a blue-green environment in both your on-premises infrastructure and cloud infrastructure. Doing so allows you the opportunity to perform tests and troubleshoot issues before they are placed in a production environment. See the “Blue-Green” section in here for further details.

API Request Limits
An application programming interface (API) is a mechanism that is used to provide a well-known communication method between a client and a server. A client will issue an API request to a server, typically using representational state transfer (REST); see “Authorization” in “Troubleshoot Security Issues.”
One potential issue with API requests is that cloud vendors will limit how many API requests can be made. This number may be associated with billing costs because your license plans may limit how many API requests can be made in a specific period of time. For example, you may be limited to 50,000 API requests for a specific cloud resource.
What happens when you reach your limit? In most cases this results in further requests being refused. Refused requests can have a significant impact on your cloud performance if the server that the API is being sent to is mission critical.
In other cases, if you exceed your API limit, you may be charged for each request over the limit. Going over the limit can result in much higher than expected costs.
One way to avoid these problems with limits is to create an alert. Alerts are warnings that can be sent via email, text messages, or other means; they can warn you that you are approaching or have exceeded a limit. If you do implement alerts, make sure you have a plan of action in the event that an alert is sent. This plan should include ensuring that the right people are notified of the alert and what steps to take to mitigate the problems associated with reaching an API limit.

Cost or Billing Issues
With a subscription model, you typically don’t need to pay for the resources that you have used until the end of the billing period (typically a month). If you are using a subscription model and you aren’t careful, you might end up with a surprisingly large bill at the end of the billing period.
Cost isn’t something to be taken lightly. Some smaller organizations have found themselves in a very difficult financial situation because of a surprise cloud vendor bill. Even larger organizations are sometimes caught off guard by a large bill.
As with API limits, the best way to troubleshoot this potential problem is to set up an alert. In this case, you can set up a billing alert that will warn you if you are close to or have exceeded a specified budget. Remember to have a good plan of action to handle this situation should it arise.

Also keep in mind that billing happens automatically, and in many cases, the bill is settled via a credit card charge. What happens if the charge exceeds the spending limit of the credit card? If the charge is declined, it can result in the immediate freeze of your cloud services. If your cloud resources are mission critical, a freeze on services can end up costing you even more money in lost revenue. Best practice to avoid this issue includes:
- Use a dedicated credit card for your cloud bills.
- Set a reminder for yourself to check the cloud bill and the available credit on your credit card a few days before the billing cycle ends.
- Routinely pay down or pay off the credit card balance.

Account Mismatches
When performing automation or orchestration operations, you will be providing account information to authenticate to the cloud environment. This may, at times, require providing information for multiple accounts when you are orchestrating operations because orchestration will involve creating several different resources that are related to one another.

These situations can become very complex, and it is possible that the wrong accounts may be used. This can result in some of the cloud resources failing during the orchestration process. To troubleshoot this issue, consider the following:
- Most automation and orchestration operations have log entries that indicate what failed and why. Consult these logs to determine whether an account mismatch is the problem.
- Attempting to create the failed resource manually using the account that was provided to the orchestration tool to determine whether an account mismatch is the problem.
- Utilize a blue-green environment to best ensure mission-critical operations are not affected by orchestration operations.

Change Management Failures
Every successful organization uses change to promote growth. This could be change in management, in the organization structure, and certainly, change in the IT infrastructure. The manner in which change is implemented is referred to as change management.

Change management is a complex discipline that includes several different models, including Lewin’s Change Management Model and Kotter’s 8-Step Change Model. Don’t get too hung up on this topic because it is not a major part of the Cloud+ exam. You should at least know that there are four primary phases in the change management process:
- Understand the need for the change.
- Plan the change.
- Implement the change.
- Communicate the change with all impacted individuals and organizations.

The change management process will often have a powerful impact on orchestrating resources in the cloud. Often this impact will be positive, but in some cases it can result in time-consuming delays and even complete restarts of the orchestration project.
This is no simple problem to troubleshoot. The best solution is to ensure all phases in the change management process are completed fully and with great thought. Ensure multiple individuals (stakeholders) have input into the changes that are being made to best ensure that the changes will go as smoothly as possible.

Server Name Changes
This isn’t likely to be a surprise: if you are referring to a server by name in an orchestration process and that server name changes, the orchestration process won’t go as you planned it. Before implementing an orchestration operation, double-check all server names. If an orchestration process fails due to a server name change, the log files should indicate that the server is “unreachable” or provide a similar error.

IP Address Changes
For more information on IP address changes, see the preceding “Server Name Changes” section because an IP address change is very similar.

Location Changes
Consider this scenario: you are using an orchestration tool and have configured it perfectly so that it creates a series of resources exactly as you want. You have tested it, and it works perfectly. A colleague in your organization asks whether you would share your orchestration configuration, and you are happy to oblige.
The next day you get a message from this colleague in which she informs you that the orchestration process failed. After doing some research, you discover that the colleague used your orchestration configuration to implement resources in a different geographic region. This region didn’t have support for some key resources that the region you created the orchestration configuration for did support.
Location changes can impact orchestration processes like this one. Different features are supported in different regions, or the limits for one region are different than those in another region. As a result, you can’t just assume that an orchestration process that works in one region will automatically work in another. You should research the differences between the regions, update your configurations, and perform the same testing operations that you did when you created the original configuration.

Version/Feature Mismatch
Cloud vendors update the services that they provide at a fairly rapid pace. Although they will often keep a feature with a new version, sometimes features are removed (see “Deprecated Features” later in this guide), add new features, or modify existing features.
For example, the cloud vendor you currently work with may now support older magnetic disk drives, which you use in one of your orchestration operations because of their lower costs. But what happens to that orchestration process in a couple of years when the cloud vendor decides to no longer support magnetic disk drives?
The best way to troubleshoot this problem is by being proactive and keeping up to date with changes in the vendor’s features. When you notice upcoming changes, verify that they won’t have an impact on your orchestration processes.

Automation Tool Incompatibility
The popularity of automation tools has exploded in recent years as automation has become more important in the IT industry. This increased popularity has led to a large increase in the number of automation tools that perform a variety of functions. For an idea of the functions that some of these tools offer, consider the following list:
- Git: A software version control tool
- Gradle: A software build tool
- Jenkins: A build management tool
- Docker: A tool for managing containers
- Chef: A configuration management tool
- Ansible: Another configuration management tool

This list is in no way complete. The number of automation tools that are available is a benefit in that they provide many options. However, in a cloud environment, this number poses a challenge to cloud vendors. Cloud vendors are not able to support a large number of options, so they often limit the options. This means if you are migrating to the cloud and are using an automation tool currently on-premises, you may need to also migrate to a different automation tool.
Migrating to a different tool is a bigger task than it may initially sound. Keep in mind that many of these automation tools have very specific features and configuration formats. For example, both Chef and Ansible can perform tasks like the automation of software on a remote system. How they do this is different, and even their configuration file formats (one is in JSON and the other is in YAML) are different.

Deprecated Features
When a developer of a tool, language, or utility decides to remove a feature from the product, the developer often decides to deprecate it rather than remove it completely. Deprecated means “we left it in there, but we don’t recommend using it anymore and reserve the right to remove it in a future release.” Sometimes a deprecated feature is slated to be removed in the next release, but in other cases it may be part of the product for many years.
In other words, it is important to realize when a feature that you are using has been deprecated. By reading the release notes of a product, you can determine which features are deprecated and put together a game plan on how you use the product to avoid the deprecated features.

API Version Incompatibility
As with any software program, the APIs used to interact with a server will change over time. This is normally the result of changes in the server software. As new features are added, new APIs are introduced. When a feature is changed, a new version of the API will be released. And when a feature is deprecated or removed from the server, the API will either be modified (often deprecated features result in a warning when used) or removed.
As with any change to software, it is important to keep up to date with changes. Included with the server’s release note should be coverage of changes made to APIs. To avoid issues, review release notes and be sure that your API calls are for the correct version of the server’s APIs.

Job Validation Issue
When an automation task is performed, it is referred to as a job. A job can be something simple, such as creating a user account, or sometimes more complex, such as deploying a web server and configuring extensions on the web server.
When you’re working with automation tools, it is important that there is a process called job validation. This process is designed to ensure that the job was performed correctly. In some cases, job validation might be included with the automation tool that you are using. You may either receive a report at the end of the automation process or be able to see the validation results by looking at log files.
However, this feature isn’t always available, so you may need to automate the job validation task yourself. Automating it may include writing some code that will determine if the job is functioning properly.
In any event, if the job validation process has an issue, this situation can pose even greater challenges. For example, the job validation process may indicate no problems when the task itself did fail. This result can lead to the false belief that the resource was deployed correctly.
While a failed deployment causes issues, those issues are likely to be noticed soon enough when users or other resources attempt to use the newly deployed resource or service. Perhaps even more frustrating is the situation that occurs when job validation indicates a failure, but the resource was deployed correctly. This situation can cost you time as you try to determine the cause of the problem when there isn’t a problem in the first place.
If you are having issues with your job validation processes, it is important to migrate the automation process to a testing platform and determine the root cause. Only when the cause is found and a fix is in place should the automation tool be used again in a production environment.

Patching Failure
Patching systems is often a tedious and time-consuming (hence, also costly) process. As a result, automation processes are often used to patch the software and operating systems of cloud resources. Both cloud vendors and clients use automation tools to perform this task.
When this process fails, it can have serious negative impact. Recall that patches often include important security fixes, so if a patch process fails, it can result in a vulnerable system.
As previously mentioned, automation tools normally either generate a report or generate log files. Reviewing these reports or logs for failed patching operations is a critical component of automation. Remember that automation is designed to aid in the process of making changes, but it doesn’t completely replace the responsibility of humans to ensure the security and functionality of cloud resources.

Quiz:
1. Which is a value that describes a difference in the delay between packets? A.Server response time B.Jitter C.Round-trip time D.Juke
2. Which of the following are typical data formats for configuration scripts? (Choose two.) B.XML C.YAML D.HTML
3. Which of the following is not a typical use of tags? A.Access control B.Automation operations C.Authentication method D.Security risk management
4. Which of the following are considered steps in change management? A.Understand the need for the change. B.Plan the change. C.Implement the change. D.All of these are steps in change management.

Answers:
1. Jitter
2. JSON and YAML
3. Authentication method
4. All of these are steps in change management.