CNPA Practice Questions

OpenTelemetry is a Cloud Native Computing Foundation (CNCF) project designed to create a unified, vendor-neutral standard for observability data. It provides a collection of APIs, SDKs, and tools to instrument applications and infrastructure for generating, collecting, and exporting telemetry data—specifically traces, metrics, and logs. This standardization allows organizations to use a consistent approach for observability across different services and platforms, avoiding vendor lock-in and simplifying the process of data collection and transmission to various analysis backends. Its primary role is to provide this standardized framework, not to be a backend or analysis tool itself.

A. OpenTelemetry is not limited to logging; it is designed to handle the three pillars of observability: traces, metrics, and logs.

B. OpenTelemetry is an open-source, vendor-neutral CNCF project, the opposite of a proprietary solution tied to specific providers.

D. OpenTelemetry is used for both application performance monitoring (APM) and infrastructure monitoring, not solely focused on infrastructure.

1. Official OpenTelemetry Documentation: The official documentation states

"OpenTelemetry is a collection of APIs

SDKs

and tools. Use it to instrument

generate

collect

and export telemetry data (metrics

logs

and traces) to help you analyze your software’s performance and behavior." This confirms its role as a standardized collection framework for all three data types.

Source: OpenTelemetry Authors

"What is OpenTelemetry?"

opentelemetry.io. Section: Introduction. Retrieved from https://opentelemetry.io/docs/what-is-opentelemetry/

2. Cloud Native Computing Foundation (CNCF): The CNCF

which hosts the project

describes it as "An observability framework for cloud-native software

" highlighting its open-source and standardized nature. This directly refutes the claim that it is proprietary.

Source: Cloud Native Computing Foundation

"OpenTelemetry Project Journey". Section: Project Description. Retrieved from https://www.cncf.io/projects/opentelemetry/

3. University Courseware: Academic materials on modern software engineering often describe OpenTelemetry's role in providing a unified observability standard. For example

course materials on distributed systems explain its function in creating vendor-agnostic instrumentation.

Source: University of California

Berkeley

EECS Course CS 162

"Lecture 21: Fault Tolerance

Microservices

and Cloud-Native Computing"

Fall 2023. Slide 58 discusses the need for standardized observability (Traces

Metrics

Logs) and mentions OpenTelemetry as the industry standard.

The primary benefit of Custom Resource Definitions (CRDs) is that they provide a native mechanism to extend the Kubernetes API. In a self-service platform model, this allows a platform team to define their own custom API objects (e.g., Database, MessageQueue, Tenant) that represent managed services. Application developers can then interact with these high-level abstractions using standard Kubernetes tools (kubectl, GitOps) and declarative manifests, without needing to understand the underlying implementation details. This is accomplished without modifying or forking the core Kubernetes API server code, ensuring the platform remains maintainable and aligned with the upstream Kubernetes project.

A. CRDs only define the resource's API schema. The operational logic for scaling and failover must be implemented in a separate custom controller (Operator), which is not an automatic feature of the CRD itself.

B. CRDs do not eliminate the need for RBAC; they integrate with it. Access to custom resources is controlled by RBAC rules (Roles/ClusterRoles and Bindings) just like any built-in Kubernetes resource.

D. CRDs are a feature within a single Kubernetes cluster. While a controller associated with a CRD could be programmed to interact with multiple clouds, this is not a built-in capability of CRDs and requires significant additional tooling and logic.

1. Official Kubernetes Documentation

"Custom Resources": "A custom resource is an extension of the Kubernetes API... The CustomResourceDefinition API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource." This directly supports that CRDs extend the API without modifying its code.

Source: Kubernetes Authors. (n.d.). Custom Resources. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

2. Official Kubernetes Documentation

"Operator pattern": "Operators are software extensions to Kubernetes that make use of custom resources to manage applications and their components. Operators follow Kubernetes principles

notably the control loop." This clarifies that the logic (refuting option A) is in the Operator

which uses the CRD as its API.

Source: Kubernetes Authors. (n.d.). Operator pattern. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

3. University of California

Berkeley

EECS Course CS 162

Lecture 19: Course materials on cloud computing explain that a key design principle of Kubernetes is its extensibility. The lecture notes describe CRDs as the mechanism to "add new types of resources to the API server" enabling custom controllers to manage them

reinforcing that CRDs are for API extension.

Source: Stoica

I.

& Kubiatowicz

J. (2020). CS 162: Operating Systems and System Programming

Lecture 19: Cloud Computing (continued). University of California

Berkeley. (Specific lecture slides on Kubernetes architecture).

4. Red Hat OpenShift Documentation

"Understanding Operators": "An Operator is a method of packaging

deploying

and managing a Kubernetes application. A Kubernetes application is an application that is both deployed on Kubernetes and managed using the Kubernetes APIs and kubectl tooling. You can think of Operators as the runtime that manages this type of application. Conceptually

an Operator takes a Custom Resource Definition (CRD) and combines it with a controller." This vendor documentation confirms CRDs are the API definition component used to build higher-level platform services.

Source: Red Hat. (n.d.). About Operators. OpenShift Container Platform 4.14 Documentation. Section: "What is an Operator?".

Metrics are numerical, time-series data representing the state of a system, such as CPU utilization, memory consumption, or request latency. They are lightweight, easily aggregated, and ideal for real-time visualization on dashboards and for triggering alerts. This continuous, quantitative data stream allows operators to immediately observe trends, spikes, and saturation points that indicate performance bottlenecks across the Kubernetes cluster. Tools like Prometheus are designed specifically to collect and analyze these metrics for real-time performance monitoring.

A. Logs are verbose, discrete event records used for deep-dive debugging of specific incidents, not for an aggregated, real-time overview of system performance.

B. Traces follow a single request's path through distributed services, pinpointing application-level latency, but not providing a view of overall cluster infrastructure health or resource bottlenecks.

D. Events are Kubernetes objects that report on discrete lifecycle occurrences (e.g., a pod being scheduled). They are reactive symptoms, not the continuous data needed for proactive bottleneck detection.

1. Kubernetes Official Documentation

"Monitoring

Logging

and Debugging": The documentation distinguishes between different observability signals. In the section on "Monitoring

" it states

"Often

metrics are numeric time series data... In a cluster

metrics are useful for understanding system state." This highlights metrics as the primary tool for understanding real-time system performance. (See: kubernetes.io/docs/tasks/debug/debug-cluster/logging-monitoring-troubleshooting-overview/)

2. OpenTelemetry Documentation

"Metrics": As a core CNCF project for observability

OpenTelemetry defines metrics as "a measurement about a service

captured at runtime." It explains that metrics are aggregated to provide statistical insights into system behavior

which is fundamental for identifying performance issues. (See: opentelemetry.io/docs/concepts/signals/metrics/)

3. Armbrust

M.

et al. (2010). "A view of cloud computing." Communications of the ACM

53(4)

50-58. This foundational academic paper on cloud computing discusses the importance of monitoring for elasticity and performance. It emphasizes the need to "monitor resource usage in real time to decide when to request and relinquish resources

" a task accomplished through metrics. (DOI: https://doi.org/10.1145/1721654.1721672

Section 4.1

"Measuring and Monitoring Utilization").

Automated builds are a core component of Continuous Integration (CI) that ensures every build is executed in a standardized and repeatable manner. By using a version-controlled script, the process of compiling source code, linking dependencies, and packaging the application is performed identically every time it is triggered. This eliminates inconsistencies and errors that arise from manual builds, where different developers might use slightly different environments, tool versions, or procedures. The primary benefit is this consistency, which creates a reliable foundation for subsequent testing and deployment stages, ensuring that any detected failures are due to code changes, not variations in the build process itself.

A. Automated builds often require dedicated infrastructure (build agents/servers), which can increase, not necessarily minimize, overall server costs, especially with high build frequency.

B. Automation helps detect compilation and test errors early, but it does not eliminate the possibility of developers writing flawed code in the first place.

D. Code redundancy is a code quality concern addressed by practices like code reviews and static analysis, not by the automated build process which simply compiles the existing code.

---

1. Humble

J.

& Farley

D. (2010). Continuous Delivery: Reliable Software Releases through Build

Test

and Deployment Automation. Addison-Wesley Professional.

Reference: Chapter 5

"Anatomy of the Build and Deployment Pipeline

" Section "The Commit Stage." The authors state

"The goal of the commit stage is to... provide fast feedback on any change. The first part of this is to ensure that the system builds and packages correctly... The build should be triggered by every check-in... This process must be automated." The chapter emphasizes that automation is key to creating a repeatable and reliable process.

2. University of California

Berkeley. (2015). CS 169: Software Engineering

Lecture 18: Continuous Deployment.

Reference: Slide 18

"Continuous Integration." The lecture notes describe a key benefit of CI as creating a "Repeatable

reliable process for deploying software." This directly supports the concept of consistency through automation. Available via Berkeley course archives.

3. GitLab Inc. (2023). Official GitLab Documentation: Continuous Integration.

Reference: Section "How CI works." The documentation states

"CI works by pushing small code chunks to your application’s code base hosted in a Git repository

and each push triggers a pipeline of scripts to build

test

and validate the code changes before merging them into the main branch... This practice provides you with a consistent and automated way to build

package

and test your applications." This explicitly identifies consistency as a primary outcome of automated CI processes.

A web portal acts as an abstraction layer, simplifying the developer experience by hiding the underlying complexities of Kubernetes. Instead of writing complex YAML manifests or using kubectl commands, developers can interact with a user-friendly graphical interface to deploy applications, view logs, and manage services. This approach, central to the concept of an Internal Developer Platform (IDP), reduces the cognitive load on developers, enabling them to self-serve capabilities efficiently without needing to be Kubernetes experts. This directly addresses the problem of complex configurations hindering access to necessary services.

A. Increasing configurations would add complexity, directly contradicting the goal of simplification and worsening the developer's struggle.

C. Limiting access to necessary services is a restrictive measure that impedes a developer's work, rather than simplifying the process of accessing them.

D. While helpful, documentation only explains the complexity; it does not reduce or abstract it. The developer must still manually handle the complex configurations.

1. CNCF Platforms Working Group

"Cloud Native Platforms White Paper": This paper defines a platform as a curated experience for a specific group of users (e.g.

developers) that abstracts away the complexity of the underlying infrastructure. Section "What is a Platform?" states

"A platform is a collection of tools and services

glued together to deliver a specific capability... It reduces the cognitive load on users." A web portal is a common implementation of this user-facing layer. (Source: CNCF Platforms WG

v1.0

2023).

2. Backstage.io Official Documentation: Backstage is a CNCF incubating project designed specifically to solve this problem. The documentation states

"Backstage is an open platform for building developer portals. ... it unifies all your infrastructure tooling

services

and documentation to create a streamlined development environment." This exemplifies the implementation of a web portal to abstract complexity. (Source: backstage.io

"What is Backstage?").

3. Kubernetes Official Documentation

"Introduction to Kubernetes": The documentation acknowledges the complexity of the system and the ecosystem of tools built on top of it to simplify interactions. While not prescribing a portal

it supports the idea of higher-level tools

stating

"Kubernetes is a platform for building platforms... This provides a layer of abstraction for developers." A portal is a prime example of such a higher-level platform. (Source: kubernetes.io/docs/concepts/overview/).

The build process is the most effective stage for generating a Software Bill of Materials (SBOM). During this phase, all source code, libraries, and third-party dependencies are definitively resolved and compiled into the final software artifact (e.g., a container image or executable). Generating the SBOM at this point ensures it is an exact, accurate inventory of every component and its specific version included in the deliverable. This provides the most valuable and actionable data for security scanning, license compliance, and vulnerability analysis before the artifact proceeds to testing and deployment, aligning with secure software development lifecycle principles.

A. During testing: Generating an SBOM during testing is suboptimal because the artifact has already been built. The goal is to analyze components as they are assembled, not after the fact.

B. Before committing code: An SBOM generated at this stage would be based on a developer's local environment, which may not accurately reflect the final dependencies resolved by the CI server.

D. After deployment: This is too late in the lifecycle. It negates the primary benefit of an SBOM, which is to proactively identify and mitigate risks before the software is released into a production environment.

1. The Linux Foundation

"Generating a Software Bill of Materials (SBOM)" (2023). This guide explicitly states: "The best place to generate an SBOM is as part of the build process in your continuous integration (CI) pipeline. This ensures that you have an accurate list of all the components that are included in your software

and that the SBOM is always up-to-date." (See section: "When to Generate an SBOM").

2. OpenSSF

"SLSA: Supply-chain Levels for Software Artifacts

" Version 1.0 (June 26

2023). The SLSA framework

which is a project of the Linux Foundation's OpenSSF

requires that the build process generates provenance. This provenance must list the dependencies that were available to the build steps. This directly ties the inventory of dependencies (a core part of an SBOM) to the build stage for ensuring artifact integrity. (See Section: "Requirements

" Subsection: "Build requirements

" SLSA 3).

3. NIST Special Publication 800-218

"Secure Software Development Framework (SSDF) Version 1.1" (February 2022). The SSDF recommends practices that align with generating SBOMs during the software production phase. Practice PW.5

"Govern and Harden the Build Process

" and its task PW.5.2

"Maintain a list of all third-party software components used in each software release

" imply that this inventory is created as part of the build process that produces the release. (See Section 4

"The SSDF's Practices").

Declarative resource management is a core principle of cloud-native systems. It involves defining the desired state of the system in configuration files (e.g., YAML manifests). A control plane, such as the Kubernetes controller manager, then continuously monitors the system's actual state and automatically takes action to reconcile any differences, ensuring it matches the declared state. This model effectively balances a predefined configuration with the need for dynamic, autonomous adjustments, such as self-healing by replacing failed pods or auto-scaling based on load. It provides a robust, predictable, and automated approach to managing complex, distributed environments.

A. Imperative Resource Management: This approach specifies the exact sequence of commands to execute, which lacks the automatic reconciliation and self-healing capabilities inherent in the declarative model.

B. Manual Resource Tracking: This is not a management approach but a reactive process that is unscalable, error-prone, and unsuitable for the dynamic nature of cloud-native applications.

D. Static Resource Allocation: This method is rigid and inefficient. It pre-allocates fixed resources, failing to leverage the elasticity and on-demand capabilities that are hallmarks of cloud-native computing.

1. Kubernetes Documentation

"Managing Kubernetes Objects Using Declarative Configuration": "When using the declarative approach

a user operates on Kubernetes object configuration files stored locally. [...] The kubectl apply command takes the user's intent and determines the changes required to make the live object configuration match the configuration file." This document explicitly contrasts this with the imperative approach and highlights its benefits for managing state.

2. The Cloud Native Trail Map

Cloud Native Computing Foundation (CNCF): The CNCF

which hosts Kubernetes

defines cloud-native principles. The trail map emphasizes "Declarative APIs" as a foundational step (Step 2: CI/CD

Step 4: Observability & Analysis). The concept underpins the automation and resilience of cloud-native architectures.

3. Burns

B.

Beda

J.

& Hightower

K. (2016). Borg

Omega

and Kubernetes: Lessons learned from three container-management systems over a decade. ACM Queue

14(1)

70-93. In Section "Kubernetes

" the authors state

"All state in a Kubernetes cluster is expressed in declarative configuration objects... The declarative

API-driven nature of Kubernetes enables a great deal of automation..." This peer-reviewed article from the creators of Kubernetes establishes the declarative model as a fundamental design principle. DOI: https://doi.org/10.1145/2898442.2898444

A centralized developer portal like Backstage acts as a "single pane of glass" for engineering teams. It unifies infrastructure tooling, service catalogs, software templates, and technical documentation into one consistent user interface. This centralization is critical for efficient cloud-native adoption as it reduces cognitive load on developers, who no longer need to hunt for disparate resources. By providing a single, discoverable access point for all platform services and knowledge, it streamlines onboarding, accelerates development workflows, and ensures that teams can easily find and use the tools and standards provided by the platform engineering team.

B. A developer portal's purpose is to support the organization's specific platform and technologies, not to provide general education on unrelated topics.

C. While knowledge sharing is a benefit, the portal is designed for official organizational software components and services, not informal sharing of personal projects.

D. The goal of a developer portal is to democratize access and empower all developers, not to create bottlenecks by restricting tools to senior staff.

1. Backstage Official Documentation

"What is Backstage?": The documentation states

"Powered by a centralized software catalog

Backstage restores order to your microservices and infrastructure... It's a single

consistent UI that sits on top of your whole infrastructure and developer tooling." This directly supports the concept of a single access point. (Source: backstage.io

"Introduction" section).

2. Backstage Official Documentation

"Core Features - Software Catalog": The Software Catalog is described as the core feature that allows you to "manage all your software... in one place." This reinforces the idea of a centralized system for all services. (Source: backstage.io/docs/features/software-catalog/

"Overview" section).

3. Backstage Official Documentation

"Core Features - TechDocs": This feature is described as a "docs-like-code solution for all your technical documentation

" which is integrated directly into the portal

centralizing documentation alongside the services it describes. (Source: backstage.io/docs/features/techdocs/

"Introduction" section).

4. Cloud Native Computing Foundation (CNCF)

"CNCF Project Page for Backstage": The CNCF

which hosts the Backstage project

describes it as an "open platform for building developer portals

" highlighting its role in creating a unified experience for cloud-native development. (Source: cncf.io/projects/backstage/

"Project Description" paragraph).

The core principle of GitOps is using a Git repository as the single source of truth for the desired state of an application. The promotion of an application from a staging to a production environment is managed through Git operations. Typically, a pull request is created to merge the validated configuration from a staging branch into the production branch. Once this merge is approved and completed, a GitOps operator (e.g., Argo CD, Flux) automatically detects the change in the production branch. It then pulls the new declarative configuration and applies it to the production cluster, reconciling its live state with the newly defined desired state in Git.

B. Creating a new production environment for each update is inefficient, costly, and not a standard GitOps practice, which focuses on updating a persistent environment's state.

C. Manually updating configuration files directly in the environment breaks the fundamental GitOps principle of using Git as the single source of truth, leading to configuration drift.

D. This describes a traditional push-based CI/CD model. GitOps primarily uses a pull-based model where an agent inside the cluster pulls changes from Git, rather than an external tool pushing them.

1. OpenGitOps Principles v1.0.0

The GitOps Working Group

CNCF:

Principle 1: "The desired state of a system must be: 1. Stored declaratively

2. Versioned and immutable

3. Pulled automatically

4. Continuously reconciled." The act of merging changes in Git updates the versioned

declarative state

which is then pulled automatically by the operator.

Reference: opengitops.dev

section "The GitOps Principles".

2. Argo CD - Official Documentation:

The documentation describes common GitOps patterns

including managing environments. The "Branch per environment" pattern explicitly states: "Promotion of changes across environments is done by merging changes from the development branch to the staging branch

and finally to the production branch. The GitOps tool automatically deploys the changes to the environment after the merge."

Reference: Argo CD Documentation

"User Guide"

section "Managing Environments".

3. Flux CD - Official Documentation:

The documentation on structuring repositories for GitOps workflows explains how to manage different environments. It details that "Promoting a new version of an application to an environment is a matter of updating the image tag in that environment’s Kustomization file and committing the change to Git." This commit is often the result of a merge from another branch.

Reference: Flux CD Documentation

"Guides"

section "Structuring your repositories".

Prometheus is a Cloud Native Computing Foundation (CNCF) graduated project specifically designed for monitoring and alerting in dynamic, microservices-based environments like Kubernetes. It operates on a pull-based model, actively scraping (collecting) time-series metrics from configured endpoints. Its powerful query language (PromQL) and integration with the Kubernetes service discovery mechanism make it the de facto standard for collecting and monitoring metrics within the cloud native ecosystem. It serves as the core data source for metrics-based observability.

A. Grafana is a visualization and analytics tool. It queries and displays data from sources like Prometheus but does not collect the metrics itself.

B. ELK Stack (Elasticsearch, Logstash, Kibana) is a solution primarily focused on collecting, storing, and analyzing log data, not time-series metrics.

C. OpenTelemetry is an instrumentation framework used to generate and export telemetry data (metrics, logs, traces), but it is not the backend system that stores and monitors the metrics.

1. Prometheus Documentation: "Prometheus is an open-source systems monitoring and alerting toolkit... It collects metrics from configured targets at given intervals

evaluates rule expressions

displays the results

and can trigger alerts if some condition is observed to be true."

Source: Prometheus Authors

Prometheus Documentation

"Overview"

Section 1. Retrieved from https://prometheus.io/docs/introduction/overview/

2. Kubernetes Documentation: "The CNCF's Prometheus project can natively monitor Kubernetes

nodes

and Prometheus... Prometheus is the most common monitoring tool used with Kubernetes by the community."

Source: Kubernetes Authors

Kubernetes Documentation

"Tools for Monitoring Resources"

Section: "Full metrics solutions". Retrieved from https://kubernetes.io/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/

3. Cloud Native Computing Foundation (CNCF): The CNCF

which hosts Kubernetes

lists Prometheus as a "Graduated" project

signifying its maturity and widespread adoption for monitoring.

Source: CNCF

Prometheus Project Journey. Retrieved from https://www.cncf.io/projects/prometheus/

4. University Courseware: Course materials on cloud computing frequently cite Prometheus as the standard for metrics collection in Kubernetes.

Source: University of California

Berkeley

CS 162: Operating Systems and System Programming

Lecture 22: "Cloud Computing"

Slide 53

"Monitoring: Prometheus". Retrieved from https://inst.eecs.berkeley.edu/~cs162/fa20/static/lectures/22-Cloud.pdf