CompTIA Cloud+ CV0-003 Exam: Operation of a Cloud Environment

Objective: Given a scenario, maintain efficient operation of a cloud environment.
This guide focuses on several different areas that revolve around ensuring that the operation of the cloud environment is efficient. You will learn about different lifecycle features, including the concept of roadmaps. You will also learn about different topics related to patching and upgrading systems. Lastly, you will learn about the different features that dashboards and reporting provide to allow you to more efficiently manage a cloud environment.

Topics:
- Confirm Completion of Backups
- Lifecycle Management
- Change Management
- Asset Management
- Patching
- Impacts of Process Improvements on Systems
- Upgrade Methods
- Dashboard and Reporting

1. What type of roadmap describes when each version of a product will be provided?
2. If your organization is using software that is one version older than the most current stable release, you are using a(n) _____ release.
3. True or false: A blue-green upgrade method is exactly the same as an active-passive upgrade method.

Answers:

1. Release roadmap
2. N-1
3. False

Confirm Completion of Backups
Backups are often performed automatically, and as a result, there is an assumption that the backup completed successfully. This assumption can result in a false sense of security because backups that didn’t complete or had errors may result in the loss of data.
Consequently, there should be some sort of process in place to ensure that backups are completed successfully. In some cases, this process can be performed by the backup utility itself. If it is not something that can be handled by the backup utility, another process needs to be put in place to handle this task.

Lifecycle Management
In this section you will explore lifecycle management of cloud resources.

Roadmaps
In lifecycle management, roadmaps provide a timeline for the implementation of the product from start to finish. Roadmaps are also used to align the product with business goals and are designed to provide an easy way to visualize the lifecycle management of a project.

Each product may have multiple roadmaps because the visibility of the process may be different for different people. For example, executives may just need to see the “big picture,” whereas implementers need to see every detail. Customers may also have a different roadmap because they will be focused on when features will be released. Roadmaps can often be grouped into one of the following categories:
- Features roadmap: This roadmap describes when features will be added to the product.
- Release roadmap: This roadmap describes when each version of the product will be released.
- Portfolio roadmap: This roadmap is a collection of product lifecycles and how they are related to one another.
- Strategy roadmap: This roadmap defines the overall high-level actions that must take place to meet the goals of the product during its lifecycle.

Old/Current/New Versions
A product’s lifecycle management process must include how different versions of the product will be maintained and supported. For example, suppose the current release of a product is version 3.2. In this case, how is version 3.1 handled? Is it still supported by the organization? Is the product still being patched on a regular basis? What are the steps needed to migrate customers from 3.1 to 3.2? And, of course, you need to ask these same questions (and more) for version 3.0 and any previous version.
For new versions, you need to make decisions regarding new features and the migration process from older releases. How does the organization let the customer know about upcoming new features? What happens if a new feature is not available in the release it was originally planned for? Will some features of new versions also be implemented in older versions that are still supported (a process called backporting)?

Upgrading and Migrating Systems
Upgrading a system is the process of enhancing an existing system to provide more features or better performance. For example, you may opt to add more RAM to an existing system to increase available memory for an operating system.
Migrating a system is the process of moving a resource from one physical location to another. For example, instead of upgrading a system by adding more RAM, you could migrate the operating system to a new hardware platform that has more RAM than the original.
The same concepts apply in cloud computing. Operating systems are placed within virtual machines (VMs) in the cloud, and these virtual machines have underlying hardware components. In some cases, you may be able to enhance an existing virtual machine (like adding more virtual memory), but in other cases you might find migrating to a new virtual machine to be a better solution. For example, if you need a faster or more powerful CPU, this isn’t something that you just add to an existing virtual machine (at least not as a typical cloud vendor solution).
Note that upgrade versus migration doesn’t just apply to virtual machines. Any cloud resource, including applications and database software, uses underlying hardware resources that may either be upgraded or require a migration to provide more power and flexibility.

Deprecations or End of Life
Most products will eventually reach a point where they no longer serve a useful purpose or no longer align with the organization’s strategic or business needs. Typically, an organization takes one of two approaches:
- Specify an end of life for the product: This approach involves indicating when the product will no longer be supported and should no longer be used. It is also referred to as sunsetting a product.
- Deprecate the product: Using this approach, an organization indicates that the product should no longer be used and is unlikely to be supported in the future. Typically, a deprecated product is replaced with a newer product, but the organization isn’t prepared to force customers to move to the new product. Consider deprecated to mean “it is still available, but the developer doesn’t recommend you use it anymore.”

Change Management
IT change management describes the practices designed to ensure successful prioritizing, approval, scheduling, and execution of changes to IT systems.

Asset Management
Asset management involves all of the processes that are involved in ensuring that an organization’s assets, including physical, financial, and information-based assets, are managed in a structured manner. This way, the organization can make good business decisions because management is well aware of current assets and how they can be applied to current and future business needs.
Asset management involves several processes, including
- Planning the need for future assets
- Acquiring assets
- Operating the assets
- Maintaining the assets
- Securing the assets
- Disposing of the assets when no longer needed

Configuration Management Database (CMDB)
In a large organization, asset management can be a complex and complicated undertaking. To aid an organization, a Configuration Management Database (CMDB) is often employed. CMDB software not only stores data about assets but also provides insights or visibility into assets that the organization owns.
One challenge of cloud computing is that cloud assets are much more dynamic than traditional assets. For example, if you purchase a server for your data center (a traditional asset), this is a fairly easy asset to catalog in a CMDB. But a similar cloud-based resource would be a virtual machine, which could be deactivated and destroyed (and quickly rebuilt) at a moment’s notice. As a result, a CMDB that manages cloud assets should have the capability to automatically catalog assets based on actions taken within the cloud environment.

Patching
Patching is the process of applying changes to software to resolve known problems. This section will cover several different types of patches that may be applied. 

Features or Enhancements
While many patches are designed to fix an issue with a product, some patches are designed to provide additional features or enhancements to the software. The addition of these features is typically performed in a full product upgrade, but in some cases a new feature may be requested by a customer and it needs to be implemented before the next upgrade cycle.

Fixes for Broken or Critical Infrastructure or Applications
One of the more common reasons a patch is deployed is to fix a problem in the product. Typically, this is referred to as a bug fix, and it is meant to be a temporary fix until the next update of the product.

Scope of Cloud Elements to Be Patched
Because cloud resources are often interrelated, a patch to one resource often requires patches to other resources. The scope of the cloud elements to be patched includes all of the cloud resources that need to be patched to successfully deploy changes.

Hypervisors
If you are working with a public cloud vendor, the vendor is responsible for maintaining patches for the hypervisor software. These patches may be applied without your knowledge, but if the patches can have an effect on your organization’s virtual machines or provide additional features that you can utilize within your virtual machines, the vendor will often inform you about these patches.
If your virtual machines reside in a private cloud within your organization’s data center, your organization is responsible for applying patches in a timely manner to the hypervisor software. Applying patches can be tricky because it is certainly possible that a hypervisor patch may cause problems with the virtual machines running on that hypervisor. You should consider performing tests before deploying patches on production systems. Consider following some of the principles discussed in the “Upgrade Methods” section later in this guide, including deploying a blue-green deployment structure.

Virtual Machines (VMs)
Keep in mind that a VM is a virtual instance of an operating system on a hypervisor. Patching VMs in the cloud can pose challenges because the cloud environment doesn’t typically include the means to patch operating systems. Patching the OS is almost always the responsibility of the cloud customer.
OS patches come from the OS developer, and there is typically a central location where you can learn about new patches. There are also automation tools that can be used to make the process of patching a large number of systems easier.

Virtual Appliances
A virtual appliance is a type of virtual machine image. The difference between a virtual appliance and a standard virtual machine is that the virtual appliance has been preconfigured to perform a specific task (or set of tasks). This makes the process of patching more difficult because both the operating system and the applications of the virtual appliance will require patches on a regular basis.
Some vendors who create virtual appliances also provide patches for the appliance, but this isn’t always the case.

Networking Components
When an organization uses a cloud vendor to deploy its cloud infrastructure, the networking components (routers, switches, and so on) are entirely the responsibility of the cloud vendor. If, however, your organization is implementing a private cloud on-premises, patching the network components is the responsibility of your organization.
Modern network components are complex and typically include a full operating system. As with any OS, the vendor who created the network component will release occasional patches. Typically, these vendors will have patch release announcements and may even have a regular patch release cycle.

Applications
In terms of patching applications, the scope will depend on the origin of the application as well as the responsibility level associated with the application. For example, if you are using a Software as a Service (SAAS) application, the cloud vendor or the application developer is 100 percent responsible for patching the application. It is important to review the service-level agreement (SLA) and other contracts to verify which organization is responsible for patching.
If the application is not SAAS, it will likely be the cloud customer’s responsibility to patch (see “Cloud Shared Responsibility Model” in “Different Types of Cloud Models,” for further details). This patch may be performed manually or via an automation tool.

Storage Components
A storage component is an underlying device where data is stored. It can include a magnetic hard drive, a solid-state drive, or a tape device. In terms of patching, the devices themselves may require occasional firmware updates (see the “Firmware” section next). Additionally, the software used by an operating system to access the storage device (called a device driver) may also need to be patched occasionally.

Firmware
Firmware is software that is designed to provide control over device hardware. In a public cloud, customers rarely have any control over the firmware that is being utilized by the physical hardware (exceptions can include when a customer leases the entire physical system for their use). As a result, the patching of firmware in a public cloud is almost always fully in the scope of the cloud vendor.
In a private cloud environment, where the control of the physical systems is in the hands of the organization using the private cloud, firmware is the responsibility of the organization.
The terms application and software are often mistakenly used interchangeably, but these terms are not synonymous. An application is a type of software, but software encompasses all types of code that are executed on a system. Often to distinguish between application software and other types of software, the term systems software is used.
In terms of the scope of software patching in a cloud environment, systems software and application software are similar. The biggest difference is that application software is more often SAAS, and the patching falls under the responsibility of the cloud vendor or the application developer. Systems software is more often not SAAS and it is the responsibility of the cloud customer to ensure the software is properly patched.

Operating System (OS)
See the “Virtual Machines (VMs)” section earlier in this guide.

Policies
Just because a patch is released doesn’t mean that it should be immediately applied. Patches are often temporary fixes and may cause more problems than they fix. Some patches are also minor and unnecessary, at least in terms of the business goals of your organization.
Your organization should have policies on which patches to apply and how they should be applied. For example, you might have a policy that patches are first deployed in a testing environment and tests are performed before releasing in a development environment.
You should also consider which versions of software you wish to deploy. Some organizations opt to have the latest version installed, whereas others tend to stay one version behind. See the following “N-1” section for more details.

N-1
For the term N-1, N refers to the most recent stable release of software, whereas N-1 refers to the previous most recent stable release of the software. There are advantages and disadvantages to always upgrading to the latest release versus staying one release behind the most current release, including:
- Features: The N release typically has newer features that the N-1 release does not.
- Compatibility: The N-1 release tends to be more compatible with other existing or older software, whereas the N release might work better if you have updated other related software.
- Security: The N-1 release tends to require less security patching than the N release because the code is more mature and more of the bugs have been worked out.

Rollbacks
A rollback is a method of undoing the steps taken during a patch. In some cases a patch may not permit a rollback. In these situations you should make sure you test the patch in a testing environment and make sure you back up all related data before patching a live system. You should also have another plan in place to recover the software, which could include performing a full backup on all software before implementing the patch.

Impacts of Process Improvements on Systems
For organizations to grow, meet new demand, and keep pace with competitors, they implement process improvement methods. Process improvement is a business practice in which an organization’s business process is reviewed and analyzed to discover changes that would result in better performance, improved customer experience, reduced costs, and other results that would benefit the organization.
Process Improvement can have an effect on cloud systems in several different areas, including
- Changes in policies that can affect the accessibility, security, and performance of cloud resources.
- Changes in which cloud resources are used within an organization. This can be a minor change (switching from one software to another) or major (changing cloud vendors).

Upgrade Methods
In this section you will learn different upgrade methods that your organization may incorporate when upgrading resources in the cloud.

Rolling Upgrades
Rolling upgrades (also called continuous delivery) is the process of frequently providing updates to software. With this upgrade method, there are no specific release points (although it is common for rolling upgrades to happen nightly), but rather when the developer is ready, a new upgrade is released.
One advantage of a rolling upgrade is that new features are more rapidly released to customers. However, rolling upgrades may be more susceptible to bugs.
Most developers that provide rolling upgrades also provide traditional “release point” upgrades. For example, the popular Firefox web browser provides a nightly rolling upgrade but also provides regular standard releases.
See “Blue-Green” in “Solution Design in Support of the Business Requirements.”
See “Canary” in“OS and Application Security Controls.”

Active-Passive
An active-passive upgrade is similar to a blue-green upgrade. With an active-passive upgrade, the upgrade is deployed to the active environment, and the passive environment is not changed.
If any problems occur in the active environment because of the patching, the passive environment is treated temporarily as the active environment. When the problems are worked out in the original active environment, the original passive environment is again treated as passive, and the original active environment is used again as the actual active environment.
If, after testing and a specific period of time, the active environment seems to be functioning properly, the patch is applied to the passive environment.
This upgrade is different from a blue-green upgrade system in which the two systems “flip-flop” between upgrades as active and passive.

Development/QA/Production/DR
You may have several similar environments that will have upgrades applied to them at different times. For example, instead of relying on a single deployment of a web server, you will likely want to have multiple deployments, each with a specific purpose. These deployments include the following:
- Development environment: You create or test new code for the software here.
- Quality assurance (QA)environment: This environment must mirror your production environment as closely as possible. You use this environment to test upgrade procedures before deploying them on a production environment.
- Production environment: In this environment customers use the software.
- Disaster recovery (DR) environment: This environment is very close to the production environment. If the production environment is not available for some reason, the DR environment should be able to take over the role of the production environment.

Dashboard and Reporting
A dashboard is a web-based infographic that provides you with insights into your cloud environment. The graphics can include charts, graphs, or text that displays information about the current status of cloud resources and components or information over a period of time. Below is afigure that provides an example of some of the types of data representations you could place on a dashboard.


AWS Cloudwatch Dashboard Data Representations

Note that in addition to dashboards, most cloud vendors provide other reporting methods, including the following:
- Alarms or alerts: A method to proactively warn you about a possible problem. 
- Logs: A place where you can see details about events that took place in your cloud environment. 
- Metrics: Methods of looking at data results over a period of time with the goal to determine a course of action to take. For example, web server statistics can show that there is a spike in traffic every three months when your organization launches a new version of a popular product. You could use this information to proactively scale up your web servers 12 hours before the press release that announces the new version and then scale down the web servers 48 hours later.
In this section you will learn about different features of dashboards and the data that can be reported.
Tags are metadata that can be applied to resources. For example, you could have a tag called “department” that can be set to values like “sales,” “development,” or “production.”
Tags are useful for reporting because you can create reporting rules like “Show me all of the virtual machines that have a value of ‘sales’ for the tag named ‘department.’” This information is critical when you need insights into which department, project, or individual is responsible for resources (and how much that is costing your organization).

Costs
Using the cloud can result in lowering your organization’s operating costs, but if you aren’t careful regarding how your resources are utilized (and how many resources there are), a cloud environment may end up costing your organization a lot of money. There are horror stories of organizations that were not aware of active resources and were hit with a large charge when their end-of-month bill arrived.
Reviewing a dashboard daily that shows the current costs incurred for the month can greatly reduce the chance of a large surprise bill at the end of the month. Most cloud vendors also make it easy to set alerts if your current costs exceed an amount.

Chargebacks
Imagine you have a large organization with different departments, each of which is financially responsible for its own resource utilization within your cloud infrastructure. Although you could have separate cloud accounts for each department and have the cloud vendor bill each individual department, there are some reasons why this is a bad choice, including
- Higher overall costs: Most cloud vendors will reduce costs the higher your volume of utilization is. In other words, a single account (or multiple accounts grouped together for billing purposes) with 1,000 virtual machines would pay less overall than 15 separate accounts with a total of 1,000 virtual machines.
- Less visibility: Even if each department is financially responsible for cloud resources, your IT department still needs to be able to see what is going on in the organization in terms of cloud utilization.
- Less control: IT departments want to provide standard controls (such as availability and security) across the entire organization. Having multiple separate cloud accounts makes this very difficult.

As a result of these drawbacks, most organizations will either have a single cloud account or group together accounts under one billing account. To handle the financial responsibility of each department, the IT department can use a system called a chargeback in which it internally bills each of the other departments.

Showbacks
Review the preceding “Chargeback” section to understand that concept first. Now suppose an IT department wants the advantages of a single billing account that incorporates several department cloud accounts, but corporate policy doesn’t allow for chargebacks. In this case the IT department will likely utilize a showback, which makes resource utilization and costs for each department visible but does not result in an actual charge to the department.

Elasticity Usage
In cloud computing, the term elasticity refers to the ability to increase resource capability (scale up) or decrease resource capability (scale down) according to demand.
For example, consider an application that accepts point-of-sale data (credit card charges), validates the data, and then sends data to a database. The store where this data is coming from is open from 8 a.m. to 8 p.m. each day, and there is an increase in sales from 5 p.m. to 7 p.m. Additionally, the store has big sales on holidays and a monthly sale on the 15th of every month.
As a result, this application requires little to no compute capacity during the hours of 8 p.m. to 8 a.m. It needs normal compute capacity from 8 a.m. to 5 p.m. and increased capacity from 5 p.m. to 8 p.m., on holidays, and on the 15th of each month. This is a generalization, of course, and the required capacity can vary greatly based on new product lines, when customers receive their own paychecks, and other factors.
The best solution therefore might be to schedule compute capacity based on the hours of the sales and the previously mentioned factors, but also to monitor the activity on the server and have the compute capacity automatically scale up or down as required. You can also take a look at the metrics over time to determine how often the capacity scales (the elasticity usage) to better determine normal versus high-volume capacity needs.

Connectivity
Imagine you have a critical cloud resource, like a database, that needs to always be available. How would you know if the resource was no longer responding? You could rely on the feedback from users, but that approach isn’t ideal because user feedback often takes time to reach the correct people. Ideally, you would monitor connectivity to key systems by using a dashboard or an alerting system.

Latency
Network latency is a measurement of how long it takes for a network packet to travel from the sender to the receiver. Large latency values have a major impact on the performance of services, as well as the user experience.
Because of the impacts of latency, having an easy way to discover latency issues is important. Some cloud vendors allow you to monitor latency and display this information on dashboards.

Capacity
Capacity refers to the amount of availability of a specific resource, such as network bandwidth, storage space, or compute power. Monitoring capacity is one of the more common features of dashboards.

Incidents
Another feature often found on dashboards is incidents. Incidents are like alerts that indicate when an action has taken place.

Health
A health dashboard will provide you with an idea of if there are any issues for resources or services. Cloud vendors typically provide a health dashboard that indicates how the vendor’s services are functioning, like AWS’s Service Health Dashboard shown below.


AWS Service Health Dashboard

Cloud vendors also provide a health dashboard that is specific to your organization’s cloud account, like AWS’s Personal Health Dashboard shown below.


AWS Personal Health Dashboard

Overall Utilization
Overall utilization is a “big picture” visualization found on dashboards. This information gives you an idea of how a resource or service is being used and how to plan for future utilization patterns based on current patterns.

Quiz:
1. Which roadmap is used to define the overall high-level actions that must take place to meet the goals of the product during its lifecycle? A.Strategy B.Portfolio C.Release D.Features
2. Asset _____ involves all of the processes that are involved in ensuring that an organization’s assets, including physical assets, financial assets, and information-based assets, are managed in a structured manner. B.Control C.Tagging D.Inventory
3. Which of the following systems would typically be the responsibility of the cloud vendor to patch? (Choose two.) A.Virtual machines B.Operating systems C.Applications D.Firmware
4. Which of the following is normally a cloud reporting method? A.Alarms B.Logs C.Metrics D.Transaction reports

Answers:
1. Strategy
2. Management
3. Applications and firmware
4. Transaction reports