Cisco 500-430 Cisco AppDynamics Professional Implementer CAPI Exam Practice Test

Page: 1 / 14
Total 50 questions
Question 1

Which three AppDynamics Controller properties govern how long metric data is retained in the database? (Choose three.)



Answer : A, C, D

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


Question 2
Question 3
Question 4

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.)



Answer : A, E

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 .


1: Browser Snapshots - AppDynamics

2: Troubleshoot Browser RUM - AppDynamics

3: Transaction Snapshots - AppDynamics

4: 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

Question 5

Which REST query could be used to verify the availability of an AppDynarmics Controller?



Question 6

What are two valid reasons for using the REST API to retrieve health rule violations? (Choose two.)



Answer : B, C

According to the Cisco AppDynamics Professional Implementer (CAPI) documents, the REST API for health rule violations allows you to retrieve information about the health rule violations that occurred in a specified time range for a given application1. You can use the REST API for health rule violations for the following valid reasons:

For determining which actions have been executed (B): The REST API response includes the details of the actions that were triggered by the health rule violation, such as email, SMS, HTTP request, or custom action1. You can use this information to verify if the actions were executed successfully, or to troubleshoot any issues with the action execution.

When searching for historical events : The REST API allows you to specify a custom time range for retrieving the health rule violations, such as BEFORE_TIME, AFTER_TIME, BETWEEN_TIMES, or BEFORE_NOW1. You can use this feature to search for historical events that occurred in the past, or to analyze the trends and patterns of the health rule violations over time.

The incorrect options are:

For updating an AppDynamics dashboard (A): This is not a valid reason for using the REST API for health rule violations, because the AppDynamics dashboards already display the health rule violations that occurred in the selected time frame, along with the severity, status, affected entities, and actions2. You do not need to use the REST API to update the dashboard, as the dashboard is automatically refreshed with the latest data from the Controller.

For sending emails (D): This is not a valid reason for using the REST API for health rule violations, because the REST API does not send emails directly. The REST API only returns the information about the health rule violations, and the actions that were triggered by them.If you want to send emails based on the health rule violations, you need to configure an email action in the health rule configuration, or use a custom action that invokes an external email service3.

When pushing events to the Event Management System is NOT possible (E): This is not a valid reason for using the REST API for health rule violations, because the REST API does not push events to the Event Management System. The REST API only returns the information about the health rule violations, and the actions that were triggered by them.If you want to push events to the Event Management System, you need to configure an HTTP request action in the health rule configuration, or use a custom action that invokes an external API3.


1: Health Rule Violations API - AppDynamics

2: Health Rule Violations - AppDynamics

3: Actions - AppDynamics

Question 7
Page:    1 / 14   
Total 50 questions