Questions for the 500-430 were updated on : Dec 01 ,2025
What are the correct steps to install a .NET Agent patch?
C
Explanation:
To install a .NET Agent patch, which is a minor update to the existing .NET Agent version, you do not
need to uninstall the old agent or restart the machine. You only need to follow these steps:
Download the .NET Agent patch from the AppDynamics Download Center.
Launch an elevated command prompt with full administrator privileges.
Execute the Installer.bat file from the patch archive. The batch file installs the patch and starts the
AppDynamics Agent Coordinator service.
Restart the instrumented applications, such as IIS, Windows services, or standalone applications.
Reference:
.NET Agent
and
How do I deploy a .NET Agent?
in the AppDynamics documentation and
community.
The Database Agent collects hardware metrics from a Windows database server using_________ .
(Choose the correct option to complete the sentence.)
B
Explanation:
The Database Agent collects hardware metrics from a Windows database server
using PowerShell1
.
PowerShell is a scripting language and a command-line shell that allows the
Database Agent to execute commands and access Windows Performance Counters on the target
host12
.
The Database Agent uses PowerShell to collect metrics such as CPU, memory, disk, and
network utilization from the Windows database server1
.
To enable hardware monitoring for a
Windows database server, the Database Agent requires the following permissions1
:
The user that runs the Database Agent must have permission to execute PowerShell scripts on the
local machine.
The user that runs the Database Agent or the Collector Service user (if using Windows
Authentication) must have permission to establish a WMI connection to the target host and collect
Windows Performance Counters. Reference:
Required Monitored Host Permissions
,
PowerShell
Overview
The application server was restarted after an upgrade. What are two valid ways to confirm that the
upgraded Java Agent is running successfully? (Choose two.)
BC
Explanation:
According to the Cisco AppDynamics Professional Implementer (CAPI) documents, the two valid ways
to confirm that the upgraded Java Agent is running successfully are:
Verify that the node within the Controller UI indicates the app agent is reporting. (B) This is a valid
way because the Controller UI is a web-based application that allows users to monitor and manage
the performance of the applications, tiers, nodes, and other entities that are instrumented by the
AppDynamics agents. The Controller UI displays the status of the nodes within each tier, and
indicates whether the app agent is reporting or not. If the app agent is reporting, the node icon is
green and shows the agent version. If the app agent is not reporting, the node icon is gray and shows
the last time the agent reported. The user can also hover over the node icon to see more details,
such as the agent type, the agent version, the agent runtime directory, and the agent properties
file.
The user can verify that the upgraded Java Agent is running successfully by checking that the
node icon is green and shows the latest agent version12
.
Verify the Java Agent Version metric for that node in the Metric Browser. © This is a valid way
because the Metric Browser is a feature of the Controller UI that allows users to view and analyze the
metrics collected by the AppDynamics agents. The Metric Browser displays the metrics in a
hierarchical tree structure, where each node represents a metric category, a metric name, or a metric
value. The user can expand or collapse the nodes, and select or deselect the metrics to view them in
a chart. The user can also apply filters, time ranges, baselines, and other options to customize the
chart. The user can verify that the upgraded Java Agent is running successfully by navigating to the
Java Agent Version metric for that node in the Metric Browser. The Java Agent Version metric shows
the version number of the Java Agent that is running on the node.
The user can compare the metric
value with the expected agent version, and check that the metric is updated after the upgrade34
.
The incorrect options are:
Verify that the application log contains a message indicating success. (A) This is not a valid way
because the application log does not contain any message indicating the success of the Java Agent
upgrade. The application log is a file that records the events and messages that occur in the
application server, such as the startup, shutdown, errors, warnings, and debug information. The
application log does not record the events and messages that occur in the Java Agent, such as the
installation, upgrade, configuration, or reporting. The Java Agent has its own log file, which is located
in the <agent_home>/logs directory, and which contains the messages indicating the success or
failure of the Java Agent upgrade .
Verify that the Java Agent log contains a message indicating the agent started successfully. (D) This is
not a valid way because the Java Agent log does not contain any message indicating the agent started
successfully after the upgrade. The Java Agent log is a file that records the events and messages that
occur in the Java Agent, such as the installation, upgrade, configuration, or reporting. The Java Agent
log contains a message indicating the agent started successfully when the application server is
started, not when the Java Agent is upgraded. The Java Agent log does not contain any message
indicating the success or failure of the Java Agent upgrade. The Java Agent log is located in the
<agent_home>/logs directory, and the message indicating the agent started successfully is “Agent
Startup Complete” .
Reference:
: Tiers and Nodes - AppDynamics
: Tier Dashboard - AppDynamics
: Metric Browser - AppDynamics
: Java Agent Metrics - AppDynamics
[5]: Java Agent Logs - AppDynamics
[6]: Troubleshoot the Java Agent - AppDynamics
What are three reasons you would create custom events using the Machine Agent REST API? (Choose
three.)
ADE
Explanation:
The Machine Agent REST API allows you to create custom events that can be used for various
purposes in AppDynamics.
Some of the reasons you would create custom events using this API
are12
:
To create an event to track application deployment. You can use the API to send a custom event that
marks the start and end of an application deployment process. This can help you monitor the impact
of the deployment on the application performance and availability, as well as correlate any issues or
anomalies with the deployment event.
To create an event to be displayed along with Time Series data in a custom dashboard. You can use
the API to send a custom event that contains any relevant information or context that you want to
display in a custom dashboard. For example, you can send a custom event that contains the details of
a configuration change, a maintenance window, a business transaction, or a user action. You can then
use the custom dashboard to visualize the custom event data along with the Time Series data for the
metrics you are interested in.
To create an event to be used to trigger a health rule violation. You can use the API to send a custom
event that contains a metric value that you want to use as a condition for a health rule. For example,
you can send a custom event that contains the CPU utilization of a machine, and then create a health
rule that evaluates the CPU utilization metric and triggers a violation if it exceeds a certain threshold.
You can then use the health rule violation to generate alerts, notifications, or remediation
actions. Reference:
Machine Agent HTTP Listener
,
Create Custom Events
Why would a load balancer be deployed in production for a single-node events cluster?
C
Explanation:
A load balancer is a network device that distributes incoming traffic among a group of servers or
nodes. A load balancer can improve the performance, availability, and scalability of a service by
balancing the load and providing failover mechanisms. In the context of AppDynamics, a load
balancer can be used to route the traffic from the Controller and other Events Service clients to the
Events Service nodes. The Events Service is the on-premises data storage facility for unstructured
data generated by Application Analytics, Database Visibility, and End User Monitoring deployments.
One of the reasons why a load balancer would be deployed in production for a single-node Events
Service cluster is to allow for deployment growth in the future. A single-node Events Service cluster is
suitable for test environments or small-scale deployments, but it does not offer data replication or
scalability. If the data volume or availability requirements increase, the Events Service cluster needs
to be expanded to a multi-node cluster, which consists of three or more nodes. Deploying a load
balancer in front of a single-node Events Service cluster makes it easier to add more nodes later,
without having to modify the configuration of the Controller and other Events Service clients.
The
load balancer can also provide a single endpoint for the clients and enable load balancing and
failover among the nodes1
.
The other options are not valid reasons for deploying a load balancer for a single-node Events Service
cluster. Option A is incorrect, because the embedded Events Service is not meant to be used along
with the single-node cluster, as it runs on the same machine as the Controller and does not offer data
replication or scalability.
The embedded Events Service is only used by the Database Visibility
product by default, and it is not recommended for production Application Analytics or EUM
installations1
. Option B is incorrect, because hiding the Events Service server’s real name is not a
security or performance benefit, and it can be achieved by other means, such as DNS or firewall
rules. Option D is incorrect, because a load balancer cannot provide redundancy for a single-node, as
there is no other node to fail over to in case of a node failure.
A load balancer can only provide
redundancy
for
a
multi-node
cluster,
which
has
data
replication
and
fault
tolerance1
. Reference:
Events Service Deployment
in the AppDynamics documentation.
What are two ways in which large and extra large performance profiles differ from other profile
types? (Choose two.)
DE
Explanation:
AppDynamics performance profiles are predefined sets of system requirements and configuration
settings that are designed to support different levels of load and scalability for the AppDynamics
platform. The performance profiles range from small to extra large, depending on the number of
agents, metrics, and events that the platform needs to handle. The large and extra large
performance profiles differ from other profile types in the following ways:
They require an enterprise-grade database: The large and extra large performance profiles require an
external MySQL database that is enterprise-grade, meaning that it has high availability, scalability,
performance, and security features. The database should also have enough disk space, memory, and
CPU resources to handle the expected load and growth.
The AppDynamics platform uses the
database to store configuration data, metric data, event data, and analytics data12
.
An alert is generated when disk space falls below 2 GB: The large and extra large performance
profiles have a built-in alert mechanism that notifies the administrator when the disk space on the
Controller host falls below 2 GB. This is because the Controller needs enough disk space to store
temporary files, logs, backups, and snapshots. If the disk space is insufficient, the Controller may
experience performance degradation, data loss, or corruption.
The administrator should monitor the
disk space usage and free up space or add more disk capacity as needed34
.
The other statements are false because:
A) They do not need to be installed on a bare metal server. The large and extra large performance
profiles can be installed on any supported operating system, such as Linux or Windows, and on any
supported platform, such as physical, virtual, or cloud.
However, the host machine should have
enough CPU, memory, and network resources to meet the performance profile requirements12
.
B) They do not need to be run with the High Availability Toolkit. The High Availability Toolkit is an
optional tool that can be used to configure and manage a high availability deployment of the
AppDynamics platform, where multiple Controllers are clustered together to provide redundancy
and failover. The High Availability Toolkit can be used with any performance profile, not just the large
and extra large ones. However, the High Availability Toolkit requires a license and additional
hardware and software resources .
C) They are supported on Windows. The large and extra large performance profiles can be installed
on Windows Server 2012, 2012 R2, 2016, or 2019, as long as the host machine meets the
performance profile requirements.
However, some features or configurations may not be available or
supported on Windows, such as the High Availability Toolkit, the Enterprise Console, or the Events
Service12
.
Reference:
Platform Requirements
,
Controller System Requirements
,
Controller Disk Space
Requirements
,
Controller Disk Space Alert
, [High Availability], [High Availability Toolkit]
Instead of using the Enterprise Console Ul, how can an administrator import an existing keypair to
manage the Controller SSL certificate?
A
Explanation:
According to the Cisco AppDynamics Professional Implementer (CAPI) documents, the method to
import an existing keypair to manage the Controller SSL certificate without using the Enterprise
Console UI is to add the keypair to the keystore.jks using a third-party tool (A). The keystore.jks file is
the default keystore for the Controller that contains the private keys and certificates for the secure
communication on port 8181. If the administrator already has a custom keypair that is signed by a
third-party Certificate Authority (CA) or an internal CA, they can use a third-party tool, such as
KeyStore Explorer or OpenSSL, to import the keypair into the keystore.jks file. The administrator
should also import the root or intermediate certificates of the CA into the cacerts.jks file, which is the
default truststore for the Controller. The administrator should use the keytool utility, which is
bundled with the Controller installation, to import the certificates into the cacerts.jks file.
The
administrator should also update the password for the keystore.jks and cacerts.jks files, and restart
the Controller to apply the changes12
.
The incorrect options are:
Re-run the Controller installer and specify the new keypair. (B) This is not a valid method because the
Controller installer does not allow the administrator to specify a custom keypair for the Controller
SSL certificate. The Controller installer only allows the administrator to specify the Controller host
name, port, account name, access key, and database settings.
The Controller installer does not
modify the keystore.jks or cacerts.jks files, and does not import any custom keypair or certificate into
the Controller keystore or truststore3
.
Upload a new keystore.jks file through the Controller UI. © This is not a valid method because the
Controller UI does not provide any feature to upload a new keystore.jks file for the Controller SSL
certificate. The Controller UI only allows the administrator to view and edit the Controller settings,
such as the license, the security, the email, the analytics, and the EUM.
The Controller UI does not
access or modify the keystore.jks or cacerts.jks files, and does not import any custom keypair or
certificate into the Controller keystore or truststore4
.
Upload the keypair from within the Controller UI. (D) This is not a valid method because the
Controller UI does not provide any feature to upload a custom keypair for the Controller SSL
certificate. The Controller UI only allows the administrator to view and edit the Controller settings,
such as the license, the security, the email, the analytics, and the EUM.
The Controller UI does not
access or modify the keystore.jks or cacerts.jks files, and does not import any custom keypair or
certificate into the Controller keystore or truststore4
.
Reference:
: Controller SSL and Certificates - AppDynamics
: How do I resolve SSL certificate validation errors in the .NET Agent? - AppDynamics
: Install the Controller - AppDynamics
: Controller Settings - AppDynamics
Which three AppDynamics Controller properties govern how long metric data is retained in the
database? (Choose three.)
ACD
Explanation:
The AppDynamics Controller properties that govern how long metric data is retained in the database
are1
:
metrics.ten.min.retention.period: This property specifies the number of days to retain metric data at
10-minute granularity. The default value is 32 days.
metrics.retention.period: This property specifies the number of days to retain metric data at 1-hour
granularity. The default value is 365 days.
metrics.min.retention.period: This property specifies the number of hours to retain metric data at 1-
minute granularity. The default value is 4 hours.
The other options are incorrect because1
:
metrics.ten.sec.retention.period: This property does not exist in the AppDynamics Controller. The
finest granularity for metric data is 1 minute.
metrics.day.retention.period: This property does not exist in the AppDynamics Controller. The
coarsest granularity for metric data is 1 hour.
metrics.week.retention.period: This property does not exist in the AppDynamics Controller. The
metric data retention is based on days, not weeks. Reference:
Database Size and Data Retention
Which data is unavailable in a hybrid deployment of AppDynamics where the AppDynamics
Controller and Events Service are installed on-premises and the EUM Server is hosted in
AppDynamics' SaaS cloud?
A
Explanation:
In a hybrid deployment of AppDynamics, where the AppDynamics Controller and Events Service are
installed on-premises and the EUM Server is hosted in AppDynamics’ SaaS cloud, the data that is
unavailable is the analytics metrics for End-User Monitoring data sets. This is because the analytics
metrics require the Events Service to store and process the unstructured data generated by the EUM
agents. However, in a hybrid deployment, the EUM Server and the Events Service are not connected,
and the EUM Server does not send the EUM data to the Events Service.
Therefore, the analytics
metrics for EUM data sets, such as browser records, mobile snapshots, network requests, and
custom events, are not available in the Controller UI or the Analytics UI1
.
The other data, such as
resource loading times, session information, and browser snapshots, are available in the EUM Server
UI, as they are stored and displayed by the EUM Server itself2
. Reference:
Hybrid
Deployment
and
EUM Data Sets
in the AppDynamics documentation.
The user under which the JVM runs must have write privileges to the_________ directories in the
Java Agent home. (Choose the correct option to complete the sentence.)
A
Explanation:
The user under which the JVM runs must have write privileges to the conf and logs directories in the
Java Agent home. This is because the conf directory contains the agent configuration files, such as
controller-info.xml and agent-config.xml, which may need to be modified or updated by the user. The
logs directory contains the agent log files, such as agent.log and agent-errors.log, which are
generated by the agent and may need to be accessed or rotated by the user. The user can install the
agent as the same user that owns the JVM or as an administrator on the host machine.
The user can
restrict the remaining contents of the agent directory, such as the lib and bin directories, to read-only
access12
. Reference:
Install the Java Agent
,
Java Agent fails to start
A Java-based web application was instrumented. The browser snapshots provide a detailed look at
an individual page request, however the correlated server-side snapshots are missing for
all requests. What are two reasons for this missing correlated server-side snapshots? (Choose two.)
AE
Explanation:
According to the Cisco AppDynamics Professional Implementer (CAPI) documents, the two reasons
for the missing correlated server-side snapshots are:
Server has set the HttpOnly flag on all cookies. (A) This is a valid reason because the HttpOnly flag is a
security feature that prevents client-side scripts from accessing the cookies. However, the
AppDynamics JavaScript Agent relies on the cookies to correlate the browser snapshots with the
server-side snapshots. The JavaScript Agent injects a cookie named _appdyn_browser into the
browser requests, which contains the correlation information. If the server sets the HttpOnly flag on
all cookies, including the _appdyn_browser cookie, the JavaScript Agent cannot read or modify the
cookie, and the correlation fails.
To enable the correlation, the server should not set the HttpOnly
flag on the _appdyn_browser cookie12
.
Server-side application is not instrumented with server agent. (E) This is a valid reason because the
server-side snapshots are collected by the AppDynamics app agents that instrument the application
servers. The app agents monitor the business transactions that are executed by the server-side
application, and capture the execution context, call graphs, errors, and metrics. If the server-side
application is not instrumented with the app agent, the server-side snapshots are not available, and
the correlation fails.
To enable the correlation, the server-side application should be instrumented
with the app agent that is compatible with the application server and the Controller34
.
The incorrect options are:
Correlated server-side snapshots work only for .NET Applications. (B) This is not a valid reason
because the correlated server-side snapshots work for any application server that is instrumented
with the AppDynamics app agent, not only for .NET applications. The AppDynamics platform
supports various application servers, such as Java, .NET, PHP, Node.js, Python, and C/C++.
The app
agents collect the server-side snapshots for the business transactions that are executed by the
application server, regardless of the programming language or framework34
.
Correlated snapshots are visible only if the injection mechanism is Automatic. © This is not a valid
reason because the correlated snapshots are visible regardless of the injection mechanism. The
injection mechanism refers to the way the AppDynamics JavaScript Agent is inserted into the web
pages. There are two injection mechanisms: Automatic and Manual. The Automatic injection
mechanism uses the app agent to inject the JavaScript Agent into the web pages that are served by
the application server. The Manual injection mechanism requires the user to manually insert the
JavaScript Agent into the web pages. Both injection mechanisms support the correlation of the
browser snapshots and the server-side snapshots, as long as the JavaScript Agent and the app agent
are configured correctly .
Correlated snapshots are visible only if browser is Chrome. (D) This is not a valid reason because the
correlated snapshots are visible regardless of the browser. The AppDynamics JavaScript Agent
supports various browsers, such as Chrome, Firefox, Safari, Edge, and Internet Explorer. The
JavaScript Agent collects the browser snapshots for the web pages that are loaded by the browser,
and correlates them with the server-side snapshots, regardless of the browser type or version .
Correlated server-side snapshots are visible only if Java version is 1.7+. (F) This is not a valid reason
because the correlated server-side snapshots are visible regardless of the Java version. The
AppDynamics Java Agent supports various Java versions, such as 1.5, 1.6, 1.7, 1.8, and 11. The Java
Agent collects the server-side snapshots for the business transactions that are executed by the Java
application server, and correlates them with the browser snapshots, regardless of the Java version or
vendor .
Reference:
: Browser Snapshots - AppDynamics
: Troubleshoot Browser RUM - AppDynamics
: Transaction Snapshots - AppDynamics
: Supported Environments and Versions - AppDynamics
[5]: Browser Real User Monitoring - AppDynamics
[6]: Set Up and Configure Web EUM - AppDynamics
[7]: Browser Support - AppDynamics
[8]: Java Agent - AppDynamics
[9]: Java Supported Environments - AppDynamics
What describes the EUM agent?
D
Explanation:
The EUM agent is a special agent that runs in web, mobile, or IoT applications and collects metrics on
the end user experience.
The EUM agent communicates with the EUM Collector, which is a
component that verifies, aggregates, and packages the raw metrics sent by the EUM agent12
.
The
EUM Collector can be either a SaaS service provided by AppDynamics or an on-premises server
installed by the customer12
.
The EUM Collector then sends the processed metrics to the
AppDynamics
Controller
and
the
Events
Service
for
storage,
analysis,
and
visualization12
. Reference:
Overview of End User Monitoring
,
EUM Data
What are two actions that an administrator should take to upgrade an EUM Server that is currently in
production? (Choose two.)
DE
Explanation:
To upgrade an EUM Server that is currently in production, the administrator should follow these
steps:
Stop the EUM Server before the upgrade. This ensures that the EUM Server does not process any
incoming data from the EUM agents during the upgrade process.
The administrator can use
the eum.sh or eum.bat script to stop the EUM Server gracefully1
.
Run the new installer on the EUM host machine. The installer will detect the existing EUM Server
installation and prompt the administrator to upgrade it to the latest version. The installer will also
migrate the EUM data from the old version to the new version, if needed.
The administrator should
follow the instructions on the installer wizard to complete the upgrade2
.
The other options are not necessary or correct for upgrading the EUM Server. The administrator does
not need to stop or upgrade the EUM agents, as they are compatible with the new version of the
EUM Server. The administrator does not need to update the EUM Server access key, as it remains the
same after the upgrade.
The administrator does not need to install MySQL, as it is bundled with the
EUM Server installation package2
. Reference:
Upgrade the Production EUM Server
and
Start and
Stop the EUM Server
in the AppDynamics documentation.
What are two capabilities of the standalone Machine Agent running on Linux? (Choose two.)
AE
Explanation:
The AppDynamics standalone Machine Agent is a Java program that runs on a host machine and
collects hardware and infrastructure metrics, such as CPU, memory, disk, and network usage. The
Machine Agent can also perform additional functions, such as:
Acting as a forwarder for analytics events: The Machine Agent can be configured to forward business
transaction, log, browser, mobile, and synthetic events from the application agents to the
AppDynamics Events Service, which is a distributed, scalable data store for analytics data. The
Machine Agent can also forward custom events from the SDK or API to the Events Service.
This
allows you to use the AppDynamics Analytics features, such as dashboards, queries, funnels, and
metrics, to analyze the performance and behavior of your applications and users12
.
Starting an HTTP listener for custom metrics: The Machine Agent can be configured to start an HTTP
listener that can receive custom metrics from external sources, such as scripts, tools, or other
applications. The Machine Agent can then report these custom metrics to the AppDynamics
Controller, where you can view them in the Metric Browser or use them in health rules, policies, or
dashboards.
This allows you to monitor any aspect of your system that is not covered by the default
Machine Agent metrics34
.
The other statements are false because:
B) The Machine Agent cannot send SNMP alerts. The Machine Agent can only receive SNMP traps
from external sources and report them as events to the AppDynamics Controller.
The AppDynamics
Controller can send SNMP alerts to external systems based on health rule violations or events, but
this is not a function of the Machine Agent5
.
C) The Machine Agent cannot communicate with multiple AppDynamics Controllers. The Machine
Agent can only communicate with one Controller at a time, which is specified in the controller-
info.xml file in the agent configuration directory. If you want to monitor the same host machine with
multiple Controllers, you need to install multiple Machine Agents on the same machine, each with a
different Controller configuration and port number .
D) The Machine Agent cannot restart itself if it goes down. The Machine Agent does not have a built-
in mechanism to automatically restart itself in case of a failure or a crash. You need to use an external
tool or script to monitor the Machine Agent process and restart it if necessary. Alternatively, you can
use the AppDynamics Agent Installer to deploy the Machine Agent as a service, which can be
configured to restart automatically on failure .
Reference:
Analytics Agent
,
Analytics Data
,
HTTP Listener
,
Custom Metrics
,
SNMP Trap Alerting
Integration
, [SNMP Integration], [Machine Agent Configuration Properties], [Install the Machine
Agent], [Agent Installer], [Start and Stop the Machine Agent]
What is the minimum recommended number of nodes for a redundant Events Service?
C
Explanation:
According to the Cisco AppDynamics Professional Implementer (CAPI) documents, the minimum
recommended number of nodes for a redundant Events Service is three ©. The Events Service is a
distributed database that stores and processes the analytics data collected by the AppDynamics
platform. The Events Service cluster consists of multiple nodes that share the data load and provide
fault tolerance and high availability. The minimum number of nodes for a functional Events Service
cluster is one, but this is not recommended for production environments, as it does not provide any
redundancy or resilience. The minimum number of nodes for a redundant Events Service cluster is
three, as this allows the cluster to tolerate the failure of one node without losing any data or
availability.
The recommended number of nodes for a redundant Events Service cluster is five or
more, as this provides better performance and scalability12
.
The incorrect options are:
1 (A): This is not a valid option because a single-node Events Service cluster does not provide any
redundancy or resilience. If the node fails, the cluster becomes unavailable and the data is lost.
A
single-node Events Service cluster is only suitable for testing or development purposes, not for
production environments12
.
2 (B): This is not a valid option because a two-node Events Service cluster does not provide sufficient
redundancy or resilience. If one node fails, the cluster becomes unstable and may lose data or
availability.
A two-node Events Service cluster is not recommended for production environments12
.
4 (D): This is not a valid option because a four-node Events Service cluster is not optimal for
redundancy or resilience. A four-node Events Service cluster has an even number of nodes, which
may cause a split-brain scenario, where the cluster is divided into two equal partitions that cannot
communicate with each other. This may result in data inconsistency or unavailability.
A four-node
Events Service cluster can be improved by adding a fifth node to avoid the split-brain scenario12
.
Reference:
: Events Service Deployment - AppDynamics
: Events Service Requirements - AppDynamics