Dynatrace Professional study plan

Map the Dynatrace threat observability data model: distinguish attack, vulnerability, and threat events and trace where each originates (OneAgent, runtime vulnerability analytics, cloud security posture).

Configure a trial tenant with Application Security enabled and generate controlled attack traffic against a deliberately vulnerable demo app to observe detection behavior.

Enumerate the attack types Dynatrace detects out of the box (e.g., SQL injection, command injection, SSRF, deserialization) and note which require specific instrumentation.

List the built-in security notification and workflow integrations (problem notifications, Workflows, SIEM forwarding) and identify what each delivers.

Draft a one-page comparison of Application Security vs. Threat Observability responsibilities within the platform.

Create custom attack rules and security settings that reduce noise, then validate them against the traffic generator from week 1.

Build a management zone or segment that scopes security findings to a single application and verify the scoping in the UI.

Configure a workflow that routes a critical attack event to a ticket and a chat channel, and confirm end-to-end delivery.

Explain how Davis AI correlates a security problem with a deployment or configuration change, and demonstrate one correlated example.

Document the difference between a vulnerability finding and an active attack, including how each appears in the problem feed.

Define the three pillars of AI observability in Dynatrace (LLM/agent tracing, model and prompt telemetry, and AI-driven platform capabilities such as Davis CoPilot) and give one concrete use case for each.

Ingest and inspect at least one AI/LLM trace (spans, prompt/response metadata, token counts) using OpenTelemetry or the Dynatrace AI observability tooling.

Query ingested logs with DQL: filter by service, time range, and severity, and aggregate counts by a field.

Create a log processing rule (parsing or attribute extraction) and prove it changes query results.

Explain how log data feeds Davis AI problem detection and where log-based events can trigger workflows.

Instrument a multi-service demo application and verify end-to-end distributed tracing, including service flow and backtrace.

Configure a service-level objective or key request threshold and confirm it appears in the application health view.

Set up a browser (RUM) and mobile monitoring configuration, then capture real user sessions and analyze Core Web Vitals or mobile crash data.

Build a synthetic browser monitor with a multi-step clickpath and a synthetic HTTP monitor, and confirm alerting on failure.

Correlate a front-end user action with a back-end service call using the distributed trace view.

Deploy OneAgent (or the operator) on a host and verify host, process, and network telemetry appear in the platform.

Configure a cloud integration (e.g., AWS, Azure, or Kubernetes) and validate that cloud and container metrics are visible and attributable.

Define a business event capture (e.g., order placed or checkout completed) and confirm it is queryable with DQL.

Create a business flow or funnel from captured events and identify where drop-off occurs.

Build a dashboard or notebook that combines infrastructure health with at least one business metric.

Trace a build-to-deploy pipeline: connect a CI/CD tool or use the platform's release/site reliability guardian features to validate a deployment.

Configure a release validation check (e.g., Site Reliability Guardian) with objectives and run it against a simulated bad deployment.

Use log analytics to compare error rates before and after a deployment and attribute the change to a release.

Explain how Davis AI separates a deployment-caused regression from unrelated noise, and demonstrate one example.

Document rollback or gating criteria that a team could adopt from the validation results.

Revisit the week 1 attack scenarios and confirm which application-layer signals (service, endpoint, request attribute) the security events depend on.

Tune a detection rule to remove a known false positive while keeping true positives, and record the before/after counts.

Integrate a vulnerability scan result (or the built-in runtime vulnerability analytics) and prioritize findings by exposure and severity.

Explain how application observability data (traces, request attributes) enriches a security finding, with one concrete example.

Write an incident response outline that starts from a security problem and ends at the responsible service and owner.

Run a timed 60-question mixed practice set weighted by domain percentage and review every miss against source material.

Re-derive the heaviest domains (Threat Observability, AI Observability) from memory using a blank whiteboard, then check against notes.

Close the three weakest objectives identified by practice results with targeted hands-on re-runs.

Summarize each domain in five bullet points that a colleague could use as a refresher.

Confirm exam logistics (format, duration, environment) from official sources and plan test-day timing.