— Cisco AppDynamics Associate Performance Analyst

Full question text, answer options, and explanations for this practice set — a spoiler-free alternative is the interactive quiz above for scored, shuffled practice.

1. . Which AppDynamics component serves as the central management server that stores configuration, metrics, and event data, and can be deployed as either a SaaS or on-premises installation?

   • A. App Server Agent
   • B. Machine Agent
   • C. Controller(correct)
   • D. Browser Real User Monitoring Agent

   Explanation: The Controller is the central management server in the AppDynamics architecture. It receives metrics and event data from all agents, stores configuration, provides the UI, and generates alerts. It is available as a SaaS offering (hosted by Cisco) or as an on-premises installation. App Server Agents run on application servers and instrument bytecode; Machine Agents collect host-level metrics; the Browser RUM agent is a JavaScript snippet injected into web pages.

2. . How does an AppDynamics App Server Agent communicate with the Controller, and what does this mean for firewall configuration?

   • A. Inbound TCP on port 8090; the firewall must allow inbound connections from the Controller to each agent
   • B. Outbound HTTPS on port 443 from the agent to the Controller; no inbound firewall rule changes are needed on the application server(correct)
   • C. Bidirectional UDP on port 4321; both inbound and outbound rules must be configured
   • D. Outbound TCP on port 8080; requires proxy authentication with the Controller

   Explanation: AppDynamics agents communicate with the Controller over outbound HTTPS (port 443). Agents initiate the connection to the Controller — the Controller never initiates connections to agents. This means no inbound firewall rules need to be opened on the application server hosts, simplifying deployment in secure environments. The agent establishes a persistent outbound connection through which the Controller can send configuration updates and receive metric data.

3. . An AppDynamics App Server Agent uses bytecode instrumentation to monitor application code. Which of the following language runtimes does the App Server Agent directly support?

   • A. Java, .NET, PHP, Node.js, and Python(correct)
   • B. Java and Go only
   • C. Java, .NET, Ruby, and Rust
   • D. Python, PHP, and C++ only

   Explanation: The AppDynamics App Server Agent supports bytecode injection for Java (JVM), .NET (CLR), PHP, Node.js, and Python. Bytecode instrumentation works by injecting monitoring code into the application's bytecode at runtime — for JVM languages this uses a Java agent; for .NET it uses a profiler API. This allows AppDynamics to capture transaction entry points, method-level timing, and error detection without requiring source code changes. Go is supported via a separate SDK, not bytecode injection.

4. . An organization wants to implement role-based access control in AppDynamics so that the operations team can view dashboards but cannot modify health rules or alert configurations. Which built-in role approach is most appropriate?

   • A. Assign all operations staff the Account Owner role and instruct them not to modify health rules
   • B. Create a custom role with view-only permissions on applications and dashboards, without configure or delete permissions on alert configurations(correct)
   • C. Assign the Administrator role to team leads only and have them export reports for the rest of the team
   • D. Use the default guest account shared by all operations staff

   Explanation: AppDynamics RBAC allows creation of custom roles with granular permissions. For a view-only operations team, a custom role should grant view (read) permissions on applications, dashboards, and metrics but withhold configure, create, and delete permissions on health rules, alert configurations, and policies. The Account Owner role has full access and should be restricted to administrators. Shared accounts violate audit trail requirements and are an RBAC anti-pattern.

5. . A multi-tier e-commerce application has a web tier (Tomcat), an application tier (JBoss), and a database tier (MySQL). When AppDynamics agents are deployed on all three tiers, what does the auto-discovered application topology in AppDynamics represent?

   • A. Only the web tier entry points as individual nodes; backend tiers are not represented
   • B. Each tier as a node with call edges showing how requests flow between tiers, including response time and call volume on each edge, assembled automatically without manual configuration(correct)
   • C. A static network diagram showing IP addresses and ports but no application-layer performance data
   • D. Only the database tier, since MySQL is the most common source of performance bottlenecks

   Explanation: AppDynamics automatically discovers multi-tier application topology through its distributed transaction tracing capability. Each instrumented tier appears as a node (Tier) in the flow map, and AppDynamics draws edges showing call relationships between tiers with real-time performance data — average response time, calls per minute, and error rate on each connection. This topology is assembled automatically from the agents' correlation headers injected into requests, requiring no manual configuration. The flow map provides immediate visibility into which tier is causing performance degradation.

6. . In AppDynamics, what is a Business Transaction (BT) and why is it the fundamental unit of measurement for application performance?

   • A. A database query executed by the application; used because database calls are the most common source of latency
   • B. A discrete unit of work triggered by an end-user or system entry point (e.g., HTTP request, message consumer) that flows through one or more tiers; used because it directly correlates application behavior to business outcomes(correct)
   • C. A JVM garbage collection event; used because GC pauses are the leading cause of Java application slowdowns
   • D. A network packet captured between tiers; used because network latency is the primary performance metric

   Explanation: A Business Transaction (BT) in AppDynamics is a discrete unit of work that is initiated at an entry point — such as an HTTP servlet, .NET MVC action, JMS message consumer, or EJB — and tracked as it flows through all downstream tiers. BTs are the fundamental performance unit because they represent complete user-facing operations (e.g., 'User Login', 'Product Search', 'Checkout') and can be correlated to business outcomes like conversion rates and user experience, unlike low-level metrics such as individual database calls or GC events.

7. . An AppDynamics administrator wants to configure a health rule that alerts when the average response time for the 'Checkout' Business Transaction exceeds 500ms for 5 consecutive minutes. What type of threshold is this, and how does it differ from a dynamic baseline threshold?

   • A. Dynamic threshold; it differs from static thresholds because it adjusts automatically based on historical performance patterns
   • B. Static threshold; it differs from dynamic baselines because the value (500ms) is fixed and does not adapt to learned normal behavior — a dynamic baseline would use a multiple of the learned average (e.g., >2× baseline)(correct)
   • C. Percentile threshold; it differs because it is based on the 95th percentile response time rather than the average
   • D. Anomaly detection threshold; it differs because it uses machine learning to detect statistical outliers

   Explanation: A fixed value like '500ms for 5 consecutive minutes' is a static threshold — the condition is compared against a constant that the administrator defines. Dynamic baseline thresholds, by contrast, use AppDynamics' learned baseline (computed from 1–4 weeks of historical data) and trigger when performance deviates by a specified multiple of the normal value (e.g., response time > 2× the 7-day learned average). Static thresholds are simpler to configure but require manual tuning; dynamic baselines automatically adapt to seasonal patterns and application growth.

8. . A developer reviewing an AppDynamics call graph for a slow Business Transaction notices that a downstream JDBC call to the orders database takes an average of 2,800ms and is called 47 times per BT invocation. What does this analysis indicate?

   • A. The database server has insufficient CPU; the recommended fix is to scale up the database VM
   • B. The application has an N+1 query problem — the BT is making 47 database calls where a single optimized query should suffice; the fix is SQL query consolidation or use of a JOIN(correct)
   • C. The network between the application tier and database tier has high latency; the fix is to co-locate the tiers in the same data center
   • D. The JDBC connection pool is exhausted; the fix is to increase the maximum pool size

   Explanation: When the AppDynamics call graph shows a large number of calls to a downstream service (47 JDBC calls per BT) combined with high cumulative response time, it strongly indicates an N+1 query problem — typically caused by loading a list of objects and then making individual database calls for each item rather than using a JOIN or batch query. The fix is to consolidate the queries at the application level. Connection pool exhaustion would manifest as queuing time rather than high call counts, and network latency would affect all calls uniformly.

9. . AppDynamics error detection is configured to flag HTTP response codes 400 and above as errors. A developer argues that 404 Not Found responses are expected behavior for the search feature and should not count as errors. How should this be addressed in AppDynamics?

   • A. Disable error detection entirely for the application to avoid false positives
   • B. Configure an error detection exclusion rule for HTTP status code 404 on the specific BT or tier, so 404s from the search feature are not counted as errors(correct)
   • C. Change the application code to return HTTP 200 instead of 404 for missing search results
   • D. Raise the error detection threshold to only flag responses above 499 (5xx errors only)

   Explanation: AppDynamics error detection configuration supports granular exclusion rules that allow specific HTTP status codes to be excluded from error counting on a per-BT or per-tier basis. Configuring an exclusion for HTTP 404 on the search BT prevents expected 'not found' responses from inflating the error rate metric and triggering false alerts. Disabling error detection entirely would create blind spots for genuine errors. Changing the HTTP response code in application code would break REST conventions and client behavior.

10. . A Node in AppDynamics reports the following JVM metrics: Heap Used = 3.8 GB, Heap Committed = 4.0 GB, GC Overhead = 22%, Thread Pool Active = 98/100. How should a performance analyst interpret this combination of metrics?

    • A. The JVM is healthy; heap usage below committed is normal and thread pool activity indicates good utilization
    • B. The JVM is under severe memory pressure — heap is nearly full (3.8/4.0 GB = 95%), GC overhead at 22% means the JVM is spending excessive time in garbage collection, and the thread pool is nearly saturated, all indicating an imminent OutOfMemoryError or performance collapse(correct)
    • C. The JVM needs a restart; high heap usage is always resolved by restarting the application server
    • D. The GC overhead at 22% is within normal range; JVM GC overhead only becomes problematic above 50%

    Explanation: This metric combination signals a critical health issue. Heap used at 95% of committed (3.8/4.0 GB) means the JVM is near its memory limit and the garbage collector is running aggressively. A GC overhead of 22% means the JVM is spending 22% of its total CPU time in garbage collection — the JVM specification throws an OutOfMemoryError when GC overhead consistently exceeds 98%, but performance degradation typically begins above 10%. Combined with a near-saturated thread pool (98/100), this JVM is approaching failure. Investigation should focus on heap dump analysis for memory leaks and BT call graphs for object allocation hotspots.

11. . A performance analyst uses AppDynamics Business Transaction naming rules to separate 'GET /api/products/{id}' requests by product category. The analyst wants to create a custom BT name based on a URI parameter. Which AppDynamics configuration approach achieves this?

    • A. Custom match rule using a URI parameter split — configure the BT naming to extract the product category query parameter and append it to the BT name(correct)
    • B. Rename the existing auto-detected BT in the UI to include the category name
    • C. Create separate application tiers for each product category
    • D. Use an AppDynamics dashboard widget to group BT metrics by category post-collection

    Explanation: AppDynamics Business Transaction naming rules support custom match rules that can extract values from HTTP URI segments, query parameters, request headers, or POST body fields to create dynamic BT names. By configuring a custom match rule that reads the category query parameter (e.g., `?category=electronics`) and appends it to the BT name, the analyst gets granular per-category performance data in separate BTs. Simply renaming a BT in the UI applies a static name and does not split by parameter value. Separate tiers would require infrastructure changes.

12. . What is the AppDynamics Analytics query language used to search transaction and event data, and what is an example of a valid query?

    • A. AppDynamics uses standard SQL with JOIN operations across application tiers
    • B. ADQL (AppDynamics Query Language); example: `SELECT transactionName, responseTime FROM transactions WHERE responseTime > 1000`(correct)
    • C. AppDynamics uses Lucene query syntax similar to Elasticsearch
    • D. AppDynamics uses a proprietary drag-and-drop interface only; no text query language is available

    Explanation: ADQL (AppDynamics Query Language) is the query language used to search and analyze transaction, event, and metric data within AppDynamics Analytics. It uses SQL-like syntax with SELECT, FROM, WHERE, GROUP BY, and ORDER BY clauses. The FROM clause specifies the data source (e.g., `transactions` for BT data, `logs` for log analytics). ADQL does not support JOIN operations between different data sources; each query operates on a single event source. Results can be visualized in dashboard widgets or used to define health rules.

13. . A product manager wants to use AppDynamics to understand what percentage of users successfully complete the checkout flow across four steps: Login, Product View, Add to Cart, and Checkout. Which AppDynamics Analytics feature is designed for this use case?

    • A. Metric Graph widget showing response times for each BT
    • B. Business Journey with a funnel visualization — configure a multi-step funnel showing conversion rate and drop-off percentage at each step(correct)
    • C. ADQL query returning the count of each BT individually with no correlation
    • D. AppDynamics SLA report showing Satisfactory/Fair/Poor breakdown per BT

    Explanation: Business Journeys in AppDynamics Analytics allow you to define multi-step user flows (funnels) by correlating sequential Business Transactions. Each step in the journey shows the number of users who reached it and the drop-off rate from the previous step, enabling conversion funnel analysis. This is a purpose-built feature for e-commerce and application flow analysis that goes beyond raw BT metrics. A Metric Graph shows time-series performance data, not conversion funnel analysis, and individual ADQL queries cannot correlate multi-step flows without a journey definition.

14. . AppDynamics Experience Level Management (ELM) allows classification of Business Transaction response times into performance tiers. What are the three ELM tiers and how does the overall experience score function?

    • A. Fast/Slow/Failed; the score is the percentage of Fast transactions
    • B. Satisfactory/Fair/Poor; the experience score (similar to Apdex) is calculated as: (Satisfactory + Fair×0.5) / Total, giving a 0–1 score(correct)
    • C. Green/Yellow/Red; the score is a color-coded status only with no numeric value
    • D. Optimal/Acceptable/Unacceptable; the score is the inverse of the error rate percentage

    Explanation: AppDynamics Experience Level Management uses three tiers: Satisfactory (response time within the target threshold), Fair (within a tolerance multiplier of the target), and Poor (exceeding the tolerance). The overall experience score is computed similarly to the Apdex (Application Performance Index) formula: (Satisfactory count + Fair count × 0.5) / Total count, yielding a score from 0 to 1 where 1.0 represents all transactions meeting the Satisfactory threshold. This provides a single numeric summary of user experience for dashboards and SLA reporting.

15. . An AppDynamics BIQTRANSACTION data collector is configured on a Java application to capture custom fields from HTTP request headers and include them in transaction snapshots. A data analyst queries: `SELECT userSegment, AVG(responseTime) FROM transactions WHERE userSegment = 'premium' AND transactionName = 'Checkout'`. What does this query enable and what AppDynamics license is required?

    • A. Standard APM metric trending; available with the base APM license
    • B. Business context correlation — correlating application performance with custom business dimensions (userSegment) to analyze whether premium users experience different checkout response times; requires the Business iQ (Analytics) license(correct)
    • C. Infrastructure metric filtering; available with the Infrastructure Visibility license
    • D. Real user monitoring session replay; requires the Browser RUM license

    Explanation: BIQTRANSACTION data collectors capture custom fields (business data) from HTTP headers, request parameters, or method return values and attach them to transaction snapshot data in AppDynamics Analytics. The ADQL query correlates the custom `userSegment` field with transaction performance metrics, enabling business context analysis — in this case, identifying whether premium users have different checkout performance than standard users. This capability requires the Business iQ (Analytics) license, which is separate from the base APM license and enables full use of AppDynamics Analytics and ADQL.

16. . What is the role of the AppDynamics Machine Agent, and at what interval does it collect host-level metrics by default?

    • A. It instruments application bytecode and collects JVM metrics; interval is 5 minutes
    • B. It collects host-level infrastructure metrics (CPU, memory, disk, network) via OS calls; default interval is 1 minute(correct)
    • C. It captures browser performance data via a JavaScript snippet; interval is per page load
    • D. It monitors database query performance via JDBC interception; interval is per query execution

    Explanation: The AppDynamics Machine Agent is a separate agent that runs as a daemon process on each host and collects infrastructure metrics — CPU utilization, memory (physical and swap), disk I/O and space, and network I/O — using OS-level calls (e.g., /proc filesystem on Linux, WMI on Windows). It reports these metrics to the Controller at a default interval of one minute. The Machine Agent is distinct from the App Server Agent (which instruments application bytecode) and is required for the Infrastructure Visibility feature and correlation of infrastructure metrics with application performance.

17. . An operations team wants to monitor a custom application metric (active worker thread count) that is not collected by default by the AppDynamics App Server Agent or Machine Agent. What is the recommended approach to surface this metric in AppDynamics?

    • A. Enable the 'All Metrics' option in the App Server Agent configuration file to automatically collect all available metrics
    • B. Develop an AppDynamics extension — a shell script or JMX query that collects the custom metric and uses the Machine Agent's extension framework to report it to the Controller(correct)
    • C. Use a third-party monitoring tool and manually copy the values into AppDynamics using the UI
    • D. Deploy an additional App Server Agent instance dedicated to custom metric collection

    Explanation: AppDynamics supports custom metric collection through the Machine Agent's extension framework. An extension can be a shell script (script-based extension), a Java class, or a JMX query that collects a custom metric value and reports it to the Controller using the Machine Agent's REST API or extension protocol. The extension output format uses a metric path that appears in the AppDynamics metrics browser, where it can be used in health rules, dashboards, and ADQL queries. This is the recommended path for metrics not natively collected by the built-in agents.

18. . An organization runs their AppDynamics-monitored application on Kubernetes. What does the AppDynamics Kubernetes Cluster Agent provide in addition to host-level metrics?

    • A. It replaces the App Server Agent for pod-level bytecode instrumentation
    • B. It collects Kubernetes-specific metrics — pod health, node resource utilization, namespace-level metrics, and container counts — and correlates them with APM tier performance data(correct)
    • C. It automatically scales Kubernetes pods based on AppDynamics health rule violations
    • D. It replaces kubectl for managing Kubernetes cluster configuration

    Explanation: The AppDynamics Kubernetes Cluster Agent is deployed as a DaemonSet or Deployment in the Kubernetes cluster and collects container orchestration metrics: pod status (Running/Pending/Failed), node CPU and memory utilization, namespace-level resource quotas, and deployment health. Critically, it correlates these infrastructure metrics with the APM data from App Server Agents running in pods — when a Kubernetes node runs out of memory and pods are evicted, the resulting APM tier performance degradation can be traced to the infrastructure event. It does not replace App Server Agents or manage Kubernetes configuration.

19. . An application running on AWS EC2 experiences periodic response time spikes. An AppDynamics performance analyst observes that the spikes correlate with CPU Steal Time increases on the EC2 instances. How does AppDynamics surface AWS EC2 metrics, and what does CPU Steal Time indicate in a cloud environment?

    • A. AppDynamics directly SSHs into EC2 instances to read /proc/stat; CPU Steal Time indicates disk I/O contention
    • B. AppDynamics uses a cloud connector that integrates with AWS CloudWatch to pull EC2 instance metrics; CPU Steal Time indicates the percentage of time the virtual CPU waits for the hypervisor to service other VMs on the same physical host — a sign of 'noisy neighbor' issues(correct)
    • C. AppDynamics cannot monitor AWS EC2 metrics; a separate AWS-native tool is required
    • D. AppDynamics uses the Machine Agent's OS calls to read CPU Steal Time; it indicates that the EC2 instance's security group is blocking network traffic

    Explanation: AppDynamics' cloud connector for AWS integrates with Amazon CloudWatch to pull EC2 instance-level metrics (CPU utilization, network I/O, disk I/O, CPU Steal Time) and correlates them with APM tier performance data. CPU Steal Time is a virtual machine metric that represents the percentage of CPU time that the guest VM's virtual CPU wanted to execute but was forced to wait because the hypervisor was servicing other virtual machines on the same physical host — a 'noisy neighbor' problem common in shared cloud infrastructure. High CPU Steal Time can cause application latency spikes without any changes in the application itself.

20. . During an AppDynamics root cause analysis, an analyst notices that a Machine Agent metric anomaly (disk I/O saturation on the database host) appears 90 seconds before the correlated APM 'Orders DB' tier response time spike. What does this temporal correlation suggest about the performance problem?

    • A. The APM data is more accurate than the Machine Agent data; the disk I/O metric should be ignored
    • B. The disk I/O saturation on the database host is likely the root cause of the APM tier slowdown — the infrastructure issue precedes and causes the application-layer performance degradation, which is visible only after the I/O queue grows(correct)
    • C. The two events are unrelated because they involve different monitoring agents
    • D. The AppDynamics Controller has a 90-second data collection delay; both events occurred simultaneously

    Explanation: When an infrastructure metric anomaly (disk I/O saturation) precedes an application-layer performance metric spike by a short interval (90 seconds), this temporal correlation strongly suggests a causal relationship — the infrastructure problem caused the application degradation. Disk I/O saturation on the database host would slow query execution, causing the I/O wait queue to grow, which then manifests as increased response times for the 'Orders DB' APM tier. AppDynamics' correlation between Machine Agent infrastructure metrics and App Server Agent APM data is a key diagnostic capability for distinguishing application bugs from infrastructure capacity issues.

21. . In AppDynamics, what is the relationship between a Health Rule, an Action, and a Policy?

    • A. A Policy defines the metric threshold; an Action defines the entity to monitor; a Health Rule sends the notification
    • B. A Health Rule defines the condition (metric threshold on an entity); a Policy connects a Health Rule Violation event to an Action; an Action defines what to do when the Policy is triggered (e.g., send email, call webhook)(correct)
    • C. An Action defines the threshold; a Health Rule runs the action; a Policy archives the event
    • D. Policies, Health Rules, and Actions are different names for the same object in AppDynamics

    Explanation: AppDynamics alerting uses three distinct components: (1) Health Rules define the monitoring condition — which entity (e.g., specific Business Transaction), which metric (e.g., average response time), and the threshold (e.g., Critical if > 2000ms for 10 minutes); (2) Actions define the notification or remediation to perform, such as sending an email, making an HTTP POST to a PagerDuty webhook, or running a diagnostic script; (3) Policies are the connectors — they listen for specific events (e.g., Health Rule Violation Started) and trigger the associated Action. This three-component model provides flexibility to reuse Actions across multiple Policies.

22. . An AppDynamics administrator needs to send alert notifications to PagerDuty when a Critical health rule is violated. Which Action type should be configured?

    • A. Run Script — executes a shell script on the Controller host
    • B. HTTP Request — sends an HTTP POST to the PagerDuty Events API endpoint with the alert payload(correct)
    • C. Send Email — sends an email to the PagerDuty email integration address
    • D. Create AppDynamics Jira Ticket — automatically creates a Jira issue

    Explanation: The HTTP Request Action in AppDynamics sends an HTTP POST (or GET) request to a specified URL with a configurable payload when triggered. PagerDuty provides an Events API endpoint that accepts JSON payloads via HTTP POST to create, acknowledge, and resolve incidents. Configuring an HTTP Request Action to POST to the PagerDuty Events API v2 URL with the appropriate routing key and event details is the recommended integration approach. Send Email also works for PagerDuty's email integration, but HTTP Request is more reliable and provides better control over the payload format and incident routing.

23. . An operations team performs a scheduled application deployment every Tuesday at 2:00 AM. During deployments, application restart causes transient health rule violations that trigger false alert floods. What AppDynamics feature prevents this?

    • A. Set all health rule thresholds to 'Informational' severity during deployments
    • B. Configure a Maintenance Window in AppDynamics to disable health rule evaluation during the scheduled deployment window, suppressing alerts(correct)
    • C. Delete the health rules before the deployment and recreate them afterward
    • D. Increase the health rule evaluation duration from 5 minutes to 4 hours to outlast the deployment window

    Explanation: AppDynamics Maintenance Windows allow administrators to schedule time periods during which health rule evaluation is suspended for specified applications, tiers, or nodes. This prevents expected transient anomalies during maintenance activities (deployments, restarts, database maintenance) from generating false-positive alerts that desensitize on-call teams. Maintenance Windows can be configured as one-time or recurring schedules (e.g., every Tuesday 2:00–3:00 AM). Deleting and recreating health rules would lose configuration history and is operationally impractical.

24. . An AppDynamics Runbook Automation Action is configured to call an HTTP POST endpoint that restarts a specific application service when a health rule critical violation occurs. What is the risk of this configuration and how should it be mitigated?

    • A. No risk; automated remediation always improves MTTR and should be fully automated without human review
    • B. Risk of remediation loops — if the restart does not fix the underlying issue, the health rule re-violates, triggering another restart, creating an infinite restart loop. Mitigate with a Policy trigger limit (maximum N actions per hour) and a confirmation step or minimum quiet period between executions(correct)
    • C. Risk of Controller overload — HTTP actions consume excessive Controller CPU. Mitigate by switching to email actions only
    • D. Risk of data loss — the HTTP POST may corrupt database records. Mitigate by backing up the database before each action execution

    Explanation: Automated remediation via Runbook Automation carries the risk of a remediation loop: if the root cause of the health rule violation is not fixed by the restart (e.g., a memory leak, an upstream dependency failure, or a configuration error), the application will continue to violate the health rule, triggering repeated restarts that may worsen the outage. AppDynamics mitigates this through Policy trigger limits (configurable maximum number of actions per time period) and minimum wait periods between action executions. Best practice also includes sending an alert notification alongside the automated action so the on-call engineer is aware of the automated response.

25. . A health rule is configured with: Entity = Business Transaction 'User Login'; Metric = Average Response Time; Warning = >1000ms for 10 minutes; Critical = >2000ms for 10 minutes. Over a 30-minute window, response time is: 0–10 min at 1,200ms, 10–20 min at 2,500ms, 20–30 min at 800ms. What sequence of AppDynamics events is generated?

    • A. Critical Violation Started at t=0 min; Critical Violation Ended at t=30 min
    • B. Warning Violation Started at t=10 min; Critical Violation Started at t=20 min; Critical Violation Ended at t=30 min; Warning Violation Ended at t=30 min(correct)
    • C. Warning Violation Started at t=10 min; Critical Violation Started at t=20 min; Critical Violation Ended at t=30 min; Warning Violation Ended at t=40 min
    • D. No events generated because the violation did not persist for the full 30-minute window

    Explanation: AppDynamics health rule evaluation requires the condition to be sustained for the specified duration before triggering: Warning (>1000ms) is met at t=0 but fires after 10 minutes of sustained breach, so Warning Violation Started fires at t=10 min. Critical (>2000ms) begins at t=10 min and sustains for 10 minutes, so Critical Violation Started fires at t=20 min. At t=20 min the response time drops to 800ms, which is below both thresholds, so Critical and Warning violations both end at t=30 min (after the evaluation window confirms the condition is no longer met). The exact timing of 'Ended' events follows the evaluation window logic.