Study guide
17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection
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
17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection
Key Takeaways Explain This Topic AI
Code-level vulnerabilities arise when Dynatrace detects a vulnerability in your own code by evaluating the requests passing through your applications.
Runtime Application Protection leverages code-level insights and transaction analysis to detect and block attacks automatically and in real time.
The Attacks view categorizes attack attempts as exploited, blocked, or allowlisted, and the security overview surfaces the total over the last 30 days.
Code-level vulnerability detection requires the global detection control set to Monitor for the technology, OneAgent monitoring enabled, no excluding monitoring rules, and a process restart after configuration changes.
Detection and blocking are separate capabilities: Runtime Vulnerability Analytics finds weaknesses while Runtime Application Protection stops exploitation attempts.
Last updated: September 2026
Section 17.2 covered vulnerabilities you inherited — a flawed library someone else wrote. This section covers vulnerabilities in your own code , and what happens when someone tries to exploit either kind.
Code-Level Vulnerabilities
Code-level vulnerabilities arise when Dynatrace Application Security detects a vulnerability in your code by evaluating the requests passing through your applications. They stem from coding errors, insecure libraries, or poor security practices, and addressing them helps prevent data breaches, system crashes, and unauthorized access.
The detection mechanism is the part that matters for the exam. This is not static analysis of source code. OneAgent already sits inside the running process observing method execution and data flow for PurePath purposes (Chapter 6); Application Security reuses that vantage point to trace untrusted input from where it enters the request to where it reaches a dangerous sink — a database driver, a command interpreter, a file API.
The consequences:
- Property Effect
- Detection uses real request data flows Findings are reachable in production, not theoretical
- No source code access is required Works on running applications without a build integration
- The finding carries exact context Which service, which process group, which entry point
- Detection is continuous A newly deployed defect is found on the next request that exercises it
Typical detected classes include injection flaws (SQL, command, LDAP) and other input-handling weaknesses reachable through live traffic.
Configuration prerequisites
Code-level vulnerability detection is gated by several settings, and the exam does ask about the chain. A process is able to report code-level vulnerabilities when:
- Code-level Vulnerability Analytics is globally enabled
- OneAgent monitoring is enabled
- The global code-level vulnerability detection control is set to Monitor for that process's technology
- No monitoring rules exclude the process group from monitoring
- The process is restarted after a configuration change
Step 5 is the one that catches people out in practice and in scenarios: enabling detection does not retroactively instrument an already-running process. If a scenario says "we enabled it an hour ago and still see nothing," the missing step is the restart. Note also the asymmetry in how quickly coverage changes are reflected: an increase in coverage takes up to 10 minutes to display, while a decrease can take up to 70 minutes .
Runtime Application Protection
Detection tells you a door is unlocked. Protection stops someone walking through it.
Dynatrace Runtime Application Protection leverages code-level insights and transaction analysis to detect and block attacks on your applications automatically and in real time.
Because the enforcement point is inside the process , it has information a network-perimeter device cannot have:
A WAF inspects a request and guesses whether a string looks malicious, which produces false positives on legitimate input and false negatives on obfuscated payloads.
Runtime Application Protection observes whether the untrusted input actually reaches a dangerous sink and alters its semantics — whether the string genuinely changes the structure of the SQL statement being executed.
That is why in-process protection can block with high precision and low false-positive risk, and it is the comparison exam questions most often draw.
Attack states
The Attacks view classifies each attempt, and the security overview shows the total number of attacks — exploited, blocked, and allowlisted — that occurred over the last 30 days :
- State Meaning
- Exploited The attack succeeded — protection was not enabled or not enforcing for this path
- Blocked Protection stopped it in real time
- Allowlisted Matched an explicit allowlist rule and was permitted
Allowlisting exists because legitimate traffic occasionally resembles an attack — a security research tool, a penetration test, or an application that legitimately accepts SQL-like input. The trade-off is real, and the exam expects you to know that allowlisting is a deliberate exception, not a way to silence noise.
Detection and Protection Are Separate
A clean separation worth memorizing:
Runtime Vulnerability Analytics — finds third-party and code-level weaknesses. Passive.
Runtime Application Protection — blocks exploitation attempts in real time. Active.
An environment can run RVA without Protection, in which case attacks are visible only through their effects rather than being stopped. The security overview does not display attack counts at all if Application Protection is not activated and enabled — so an empty Attacks view can mean either "no attacks" or "protection is off," and confirming which is a legitimate exam answer.
The Combined Picture
The reason both capabilities live on the same platform as observability data is the correlation:
A critical code-level SQL injection exists in the payments service. It is internet-facing, its DSS is 9.4, it processes 40,000 requests per hour, and there have been 312 blocked attack attempts against it in the last 30 days.
Every element of that sentence comes from a different subsystem — Application Security, the Davis Security Score, service metrics from OneAgent, and the Attacks view — and together they justify an emergency change window in a way a scanner report never could. That combination of security findings plus live production context is the argument the Associate exam wants you to be able to make.