Study guide
3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events
Dynatrace Certified Associate Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Overview, Deployment Models & Architecture
1.1 Dynatrace Platform Capabilities, Web UI Navigation & the Dynatrace Hub 1.2 SaaS vs. Dynatrace Managed Architecture & Security 1.3 Core Telemetry Components: OneAgent, ActiveGate & Grail Lakehouse 1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)
2 Chapter 2: ActiveGate Architecture & Network Topologies
2.1 ActiveGate Types: Environment vs. Cluster ActiveGates 2.2 ActiveGate Capabilities: Proxying, Private Synthetic, Cloud Integrations & Extensions 2.3 Network Zones, Multi-DC Routing & Firewall Traversal
3 Chapter 3: OneAgent Deployment, Configuration & Management
3.1 OneAgent Architecture, Components & Automatic Injection 3.2 Host Installation on Linux, Windows & Containerized Hosts 3.3 Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift 3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events
4 Chapter 4: Monitoring Modes, Process Groups & Infrastructure Observability
4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery 4.2 Process Groups, Process Instances & Custom Process Group Detection Rules 4.3 Host Groups, Host Naming Rules & Environmental Metadata Extraction 4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis 4.5 Database Observability: The Databases App, Connection Pools & Storage Latency
5 Chapter 5: Smartscape Topology & Service Flow
5.1 The 5-Layer Smartscape Topology: Datacenter to Application 5.2 Service Detection: Web Services, Background Tasks & Custom Services 5.3 Service Flow, Backtrace Analysis & Horizontal/Vertical Dependency Mapping
6 Chapter 6: PurePath Distributed Tracing & Code-Level Diagnostics
6.1 PurePath Architecture, Distributed Tracing & Request Context Propagation 6.2 Method Hotspots, CPU Profiling & Memory Allocation Thread Analysis 6.3 Database Service Diagnostics, Slow Queries & Exception Analysis
7 Chapter 7: Davis AI Engine, Baselining & Causation
7.1 Davis Deterministic Causation Engine vs. Pure Correlation 7.2 Automated Dynamic Baselining, Percentiles & Traffic Seasonality 7.3 Event Ingestion, Event Types & Event Hierarchy in Problem Evolution
8 Chapter 8: Problem Lifecycle, Root Cause Analysis & Alerting
8.1 Problem Lifecycle, Severity Categories & Root Cause Cards 8.2 Alerting Profiles, Delay Filters & Management Zone Routing 8.3 Problem Notification Integrations: Webhooks, Slack, ServiceNow & ITSM
9 Chapter 9: Digital Experience Monitoring: Synthetic Monitoring
9.1 Synthetic Monitors: HTTP, Single-Step Browser & Multi-Step Clickpaths 9.2 Private Synthetic Locations, ActiveGate Engines & Credential Vault 9.3 Outage Detection, Performance Baselining & Maintenance Suppression
10 Chapter 10: Digital Experience Monitoring: Real User Monitoring (RUM)
10.1 RUM Architecture, OneAgent Script Injection & Mobile/OpenKit Telemetry 10.2 User Actions: Load vs. XHR/Fetch Actions, Visually Complete & Speed Index 10.3 Apdex Performance Ratings, User Sessions & Session Replay Masking
11 Chapter 11: Log Management and Analytics on Grail with DQL
11.1 Log Management on Grail: Storage, Ingestion Pipelines & Log Masking 11.2 Dynatrace Query Language (DQL): Fetch, Filter, Fields & String Operations 11.3 DQL Aggregations: Summarize, MakeTimeseries, Sorting & Visualizations
12 Chapter 12: Platform Governance, OpenTelemetry & Automation
12.1 Management Zones: Scoping Observability, Dashboards & Access Control 12.2 Tagging Strategies: Automated Rule-Based Tags, Manual Tags & AWS/K8s Metadata 12.3 OpenTelemetry Ingestion, OpenPipeline & Dynatrace Workflows Automation
13 Chapter 13: Cloud Integrations & Agentless Infrastructure Ingestion
13.1 AWS, Azure & Google Cloud Integrations 13.2 VMware vSphere, Extensions & Other Agentless Ingestion Paths
14 Chapter 14: Business Analytics & Business Events
14.1 Business Events: Capture, Ingestion & the bizevents Grail Table 14.2 Business Analytics: Connecting Performance to Revenue, Conversion & KPIs
15 Chapter 15: Notebooks, Dashboards & Data Visualization
15.1 Notebooks: Section-Based Investigation & Shareable Analysis 15.2 Dashboards: Tiles, Variables, Segments & Continuous Monitoring 15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection
16 Chapter 16: Reporting, Metrics & User Behavior Analysis
16.1 Metrics on Grail: Built-in Metrics, Granularity & Retention 16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs 16.3 User Behavior Analysis: Bounce Rate, Landing & Exit Pages, Conversion Goals 16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis
17 Chapter 17: Security, Vulnerability Analytics & Application Protection
17.1 Platform Security: Data Privacy, Encryption & Access Control 17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor 17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection 17.4 Security Investigator, Notifications & the Remediation Workflow
3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events
Key Takeaways Explain This Topic AI
Kubernetes Infrastructure is a separately scored topic on the Associate exam score report, and it tests Kubernetes observability — not just Dynatrace Operator installation.
The Kubernetes app groups objects by type in its Explorer sidebar: clusters, nodes, namespaces, workloads, pods, services, and containers.
Kubernetes event monitoring must be enabled by turning on 'Monitor Kubernetes namespaces, services, workloads, and pods' in cluster monitoring settings; pod events then surface on cluster, namespace, workload, and pod pages.
The workload analysis page combines resource utilization, requests and limits, pod counts, inbound services, detected problems, and vulnerabilities in a single view.
Requests and limits analysis is the standard Dynatrace answer for capacity questions: OOMKilled pods point at memory limits, while CPU throttling points at CPU limits.
Last updated: September 2026
Section 3.3 covered how the Dynatrace Operator gets instrumentation into a cluster. That is only half of the exam's Kubernetes Infrastructure topic. The score report treats Kubernetes as its own scored area, and the questions that appear there are overwhelmingly about analysis : which object owns a metric, why a pod restarted, where an event is displayed, and how requests and limits relate to what you see. This section covers that half.
The Kubernetes Object Hierarchy in Dynatrace
The Kubernetes app presents an Explorer view whose sidebar groups every discovered object by type. Understanding the hierarchy is the prerequisite for every other question. Cluster
- └── Node (a machine; also a Dynatrace Host entity)
- └── Namespace (logical tenancy boundary)
- └── Workload (Deployment, StatefulSet, DaemonSet, Job, CronJob, ReplicaSet)
- └── Pod (scheduling unit)
- └── Container
- └── Service (stable network endpoint in front of pods)
Two modelling facts matter for the exam:
A Kubernetes node is also a Dynatrace host. The same machine appears in the Kubernetes app as a node and in Infrastructure & Operations as a host, with the same CPU, memory, disk, and network metrics. Questions that imply these are two separate monitored entities are wrong.
Workload is the unit you usually alert and report on , not the pod. Pods are ephemeral; a Deployment that restarts fifty pods per day is still a single workload entity with continuous history.
Cluster and Namespace Analysis
The cluster page answers capacity and health questions across the whole estate: node count and readiness, aggregate CPU and memory requests versus allocatable capacity, running versus pending pods, and cluster-level events.
The namespace unified analysis page is where multi-tenant governance happens. It exposes:
- Properties — labels, annotations, and cluster membership
- Problems — Davis problems scoped to workloads in this namespace
- Resource requests and limits — aggregate CPU and memory reservations
- Workload analysis — every workload in the namespace with its pod counts
- Quotas — Kubernetes ResourceQuota consumption
- Events — Kubernetes events for objects in the namespace
A typical exam scenario: a platform team must show a tenant that their namespace is requesting far more CPU than it uses. The namespace page's requests-versus-usage comparison is the intended answer, not a hand-built DQL query.
Workload Analysis
The workload unified analysis page is the densest screen in the Kubernetes app, and it deliberately fuses several data types:
- Panel What it tells you
- Resource utilization Actual CPU and memory consumption versus requests and limits
- Pods Number of pods in the workload, plus restart counts and readiness
- Services How many Kubernetes services send traffic to these pods
- Problems Davis problems affecting the workload
- Vulnerabilities Third-party vulnerabilities detected in the running containers
- Events Kubernetes events for all pods in the workload
That last row is the reason Dynatrace positions Kubernetes as more than infrastructure monitoring: the same page shows a CrashLoopBackOff event, the memory limit that caused it, and the vulnerable library running inside the image.
Kubernetes Event Monitoring
Kubernetes emits events — Scheduled , Pulled , Killing , BackOff , FailedScheduling , OOMKilling , Unhealthy — that explain why the cluster did something. Dynatrace ingests them, but not by default in every configuration .
To monitor Kubernetes events you must ensure Monitor Kubernetes namespaces, services, workloads, and pods is turned on in the cluster's monitoring settings. Once enabled, pod events are displayed on the cluster, namespace, workload, and pod detail pages — the same event appears at every level of the hierarchy that contains it.
This is high-yield exam material because it is counter-intuitive: candidates assume that installing the Operator automatically produces events. The correct sequence is Operator deployed → cluster connected → namespace/workload/pod monitoring enabled → events visible . You can additionally create event-driven alerting so that specific event reasons raise Dynatrace events.
Requests, Limits, and the Two Classic Failure Modes
Almost every Kubernetes performance question on the exam reduces to requests versus limits.
Requests are what the scheduler reserves. Too-high requests waste cluster capacity and cause FailedScheduling ("Insufficient cpu") even when nodes look idle.
Limits are hard ceilings enforced at runtime, and the two resources behave completely differently when a limit is hit:
Resource Behaviour at the limit Symptom in Dynatrace
Memory The container is terminated by the kernel OOMKilled event, pod restart count climbing, workload restarts
CPU The container is throttled , not killed Rising response time and CPU throttling metrics with no restarts
Worked scenario: a Java service shows response times climbing from 200 ms to 1.4 s every weekday afternoon, with zero pod restarts and node CPU at 40%. Because there are no restarts , memory is not the constraint; because node CPU is low, the node is not saturated. The answer is CPU throttling against the container's CPU limit — the workload page's utilization-versus-limit chart shows usage pinned at the limit. Raising the CPU limit, not adding nodes, is the fix.
Contrast that with a pod whose restart count increments every few hours and whose events include OOMKilling . That is a memory limit problem, and the fix is a higher memory limit or a genuine heap leak investigation via the PurePath memory diagnostics covered in Chapter 6.
Cloud-Managed Kubernetes
Dynatrace treats EKS, AKS, GKE, and OpenShift as clusters like any other, but on managed services the control plane is not a customer host . You will not see kube-apiserver as a monitored process on EKS. Questions that expect control-plane process metrics on a managed offering are testing whether you understand that boundary.