• Home
• Avaya Exams
• 71200X - Avaya Aura Core Components Integration

71200X Avaya Practice Test Questions and Exam Dumps

Question 1

You have set up Avaya Aura® Communication Manager (CM) as a Managed Element in Avaya Aura® System Manager (SMGR), but you notice that when changes are made using SAT, they are not reflected in the SMGR’s version of the CM database. 

Which checkbox on the Inventory screen likely hasn’t been selected for the CM element?

A. Send Updates To SMGR
B. Sync With SMGR
C. Inform SMGR Of SAT Changes
D. Enable Notifications

Correct answer: C

Explanation:

When Avaya Aura Communication Manager (CM) is configured as a Managed Element within Avaya Aura System Manager (SMGR), it is essential that any changes made through alternative interfaces—like the System Access Terminal (SAT)—are properly synchronized with the version of the CM database held by SMGR. If such updates are not reflected within SMGR, this means that SMGR is not being notified of the changes made outside its own configuration interface.

The SAT (System Access Terminal) is a command-line interface commonly used to make real-time changes in the Communication Manager. However, if System Manager is unaware of those SAT changes, it will retain outdated information. This disconnect leads to a lack of synchronization, which can potentially cause configuration conflicts or administrative confusion.

To ensure synchronization, there is a specific setting on the Inventory screen in SMGR under the CM Managed Element configuration. This setting is a checkbox labeled “Inform SMGR Of SAT Changes.” When this checkbox is not selected, System Manager will not receive notifications that changes were made through SAT. Consequently, the internal copy of the CM database that SMGR maintains will not reflect the real-time state of CM as modified through SAT.

Let’s go over the other options to see why they are not correct:

A. Send Updates To SMGR — This option might sound related, but it typically deals with pushing configuration data from CM or another source into SMGR in a general sense, not specifically to address SAT updates. It does not ensure real-time updates from SAT changes.

B. Sync With SMGR — This implies a broader synchronization capability but does not ensure that changes specifically made via SAT are automatically or explicitly sent to System Manager. This setting usually refers to scheduled sync tasks or initialization sync processes.

D. Enable Notifications — While enabling notifications may sound like it relates to informing SMGR, it is a general setting that covers alerts and traps, not the specific need to notify SMGR about manual configuration changes made via SAT.

Only Inform SMGR Of SAT Changes directly addresses the scenario where SAT changes must be made visible to System Manager. When this box is checked, any changes made through SAT are logged and sent back to SMGR, updating its internal database and ensuring consistent management and reporting.

Thus, the failure to update the SMGR copy of the CM database after making SAT changes is due to the omission of this specific setting. Checking it ensures real-time database integrity between CM and SMGR even when external configuration interfaces like SAT are used.

Question 2

How many servers are included in a High Availability Duplex setup for Avaya Aura® Communication Manager (CM)?

A. Three servers (2 Active + 1 Standby)
B. Four servers (2 Active + 2 Standby)
C. Two servers (2 Active + 0 Standby)
D. Two servers (1 Active + 1 Standby)

Correct Answer : D

Explanation:

The Avaya Aura Communication Manager (CM) in a High Availability (HA) Duplex configuration is designed to ensure continuous service availability by using a redundancy model. In such a configuration, the system utilizes two servers that are paired together to provide reliability in the event of a failure. One of these servers operates as the Active server, while the other remains in a Standby mode, ready to take over should the active server fail.

This duplex setup functions through real-time data synchronization. The active server processes all communication traffic, and the standby server mirrors its state by continuously receiving data updates. If the active server becomes unavailable due to hardware failure, software crash, or maintenance, the standby server can immediately become the active one with minimal service disruption.

This configuration is often referred to as 1+1 redundancy—one server is live and handling the workload, and one server is passively maintaining synchronization to take over if needed. This is a common approach in environments that require high availability but do not want the added complexity or cost of additional active nodes.

Option A suggests a configuration with three servers (2 active and 1 standby), which implies a more complex distributed or load-balanced setup that does not align with the traditional duplex high availability model used in Avaya Aura CM. Option B describes four servers with two active and two standby nodes, which again exceeds the typical architecture for standard HA duplex in this context. Option C implies both servers are active with no standby, which eliminates fault tolerance and doesn't fit the high availability duplex model, where having a standby unit is essential.

The correct answer, therefore, is D, as it accurately reflects the intended setup: one active server paired with one standby server in a two-server model that ensures seamless failover capability in case of system issues. This architecture balances high availability with manageable infrastructure complexity and cost, making it a widely adopted solution in enterprise voice systems.

Question 3

Which of the following statements correctly describes a necessary configuration step for setting up Avaya Aura Communication Manager (CM) to operate effectively as a feature server for CM SIP Endpoints (AST Endpoints)?

A. CM does not support SIP Endpoints in Avaya Aura® 8.x.
B. CM must be added as an Application and an Application Sequence.
C. Endpoints must register directly with CM.
D. CM must be added as an Application Sequence assigned to the CM Managed Element.

Answer: D

Explanation:
In Avaya Aura architecture, enabling Communication Manager (CM) to serve as a feature server for SIP-based AST (Avaya Session Termination) endpoints requires specific configuration steps in System Manager. One of the key parts of this process is correctly integrating CM into the Session Manager routing and feature-control framework.

To begin with, Communication Manager must be administered within System Manager as a Managed Element. This allows Session Manager to recognize and route requests appropriately to CM. However, simply adding CM as a Managed Element is not enough to ensure full integration for SIP endpoint support.

What makes CM act as a feature server for SIP endpoints is when it is also associated with an Application Sequence. Application Sequences define how Session Manager routes SIP signaling to and from various applications (such as CM) for processing. Once CM is added as an Application, it must also be part of an Application Sequence. Crucially, this Application Sequence must then be linked to the CM Managed Element in System Manager. This linkage is what binds the SIP signaling path through Session Manager to CM's feature server capabilities.

Option A is incorrect because CM does support SIP endpoints in Avaya Aura 8.x. In fact, Avaya continues to expand SIP support in newer versions. Option B is partially true but lacks precision. While it is true that CM must be added as both an Application and as part of an Application Sequence, the question specifically asks which statement is fully true about making CM work successfully as a feature server. This implies the need for CM to be associated with the Managed Element, which option D captures more completely. Option C is incorrect because SIP endpoints in an Avaya Aura environment do not register directly with CM. They register with Session Manager, which then interacts with CM for feature control and call processing.

Therefore, the most accurate and complete answer is D, as it reflects both the requirement of configuring CM within an Application Sequence and associating that sequence with the correct Managed Element for proper feature server operation.

Question 4

You are setting up an OPTIM trunk between Avaya Aura® Session Manager (SM) and Avaya Aura® Communication Manager (CM) in order to separate the SIP signaling used by your Advanced SIP Telephone (AST) users. If there is already a SIP trunk between SM and CM for regular SIP traffic, 

How can you create a second trunk for this purpose?

A. Create an additional SIP Entity, SIP Entity Link and CM Signaling/Trunk Group using an alternate TLS port (such as 5062).
B. Specify a new Entity Link on the existing CM SIP Entity but using UDP instead of TLS as the Transport Protocol.
C. Assign secondary IP addresses for both SM and CM to create a second SIP link between.
D. A second link should not be created as OPTIM traffic must be sent down the existing SIP link.

Correct answer: A

Explanation:
When deploying Advanced SIP Telephones (ASTs) in an Avaya Aura environment, it's a best practice to use a dedicated signaling path for OPTIM (Optimized Call Processing) traffic. This type of traffic is related to SIP signaling specific to the advanced features supported by these SIP phones, such as enterprise-level call handling, feature synchronization, and advanced media handling. To keep this signaling cleanly separated from general SIP traffic—such as that used by other applications or endpoints—it is necessary to set up a distinct SIP trunk between Session Manager and Communication Manager.

The correct approach to establishing a second SIP trunk between Session Manager and Communication Manager for this purpose involves creating a new SIP Entity and SIP Entity Link in Avaya Aura System Manager. This separation allows each SIP trunk to have its own transport configuration and unique listening ports. To make this new trunk operational without interfering with the existing one, an alternate transport layer port—typically another TLS port such as 5062—is used. This ensures that both trunks can coexist on the same IP address but respond to signaling on different ports.

Option A describes exactly this approach: creating an additional SIP Entity, a separate SIP Entity Link, and a corresponding Signaling Group and Trunk Group in Communication Manager. These will all point to the alternate TLS port, allowing traffic to be cleanly routed based on its type or intended endpoint.

Option B is incorrect because simply changing the transport protocol from TLS to UDP on an existing SIP Entity does not offer sufficient separation for secure and specialized traffic like AST-related signaling. Furthermore, Avaya strongly recommends using TLS for signaling security, especially in enterprise environments.

Option C involves assigning secondary IP addresses to both Session Manager and Communication Manager, which adds unnecessary complexity. While technically feasible, it is not the preferred or documented method for establishing a second SIP trunk for OPTIM or AST traffic. It also does not align with Avaya’s recommended design practices.

Option D is outright incorrect. Using the existing SIP link for OPTIM traffic defeats the purpose of separating signaling for manageability, security, and performance reasons. Avaya explicitly recommends creating a dedicated SIP trunk for AST/OPTIM traffic to ensure proper feature behavior and isolation of advanced SIP functions.

Therefore, the correct solution involves creating a separate SIP Entity, Entity Link, and associated signaling/trunking configuration using a different TLS port. This setup allows administrators to isolate traffic types, maintain secure signaling, and follow Avaya’s architectural guidelines.

Question 5
When logging into the SAT command line for the first time after setting up an Avaya Aura® Communication Manager (CM) Duplex Cluster, you find that the Add and Change commands are not available—even though a license file is already installed. 

What action must you take to enable future modifications through the SAT interface?

A. Reboot both Active and Standby servers.
B. Install the CM authentication file.
C. Install the CM license on WebLM and point CM to the WebLM IP address.
D. Use the command save translation followed by reset system 4.

Answer: B

Explanation:

After deploying a new Avaya Aura Communication Manager (CM) Duplex Cluster, one of the essential steps before gaining full administrative capabilities is installing both the license file and the authentication file. While the license enables feature entitlements and general functionality, it is the authentication file that governs user permissions—specifically, what a user can and cannot do on the system.

In this scenario, the license file has already been installed, which allows CM to operate. However, the absence of the "add" and "change" commands in the SAT (System Access Terminal) session is a clear indicator that the authentication file has not yet been installed. Without this file, the system does not grant full administrative rights, even if the user logs in using a privileged account.

The authentication file acts as a permission gatekeeper and is separate from the license. It must be uploaded to the system explicitly. Once installed, it activates the full set of commands within SAT, such as “add,” “change,” and others, which are necessary for configuring stations, trunks, system parameters, and various other features. Without it, the system places the administrator in a restricted mode that is mainly read-only.

Option A (rebooting both servers) will not resolve this issue because restarting the servers does not change the system's authentication status or permissions. If the authentication file is not present, reboots will have no effect on enabling those restricted commands.

Option C suggests installing the license on WebLM and pointing CM to it, but that only pertains to licensing functionality, not user command authorization. Since the license is already installed, this step has already been taken and is unrelated to the SAT command access issue.

Option D, using “save translation” followed by “reset system 4,” is a method typically used to commit changes and reset the system for those changes to take effect. However, it assumes that changes have already been made or that the system is in a state where the user can make changes—which is not the case here due to the absence of the “add” and “change” commands.

Therefore, the only correct and necessary action in this situation is to install the authentication file, which will authorize the use of the full range of administrative commands in SAT. Once this file is properly loaded into the system, the SAT interface will grant the expected access levels, and administrative work can proceed normally.

Question 6

In the Avaya Aura Communication Manager (CM) license file, which specific reference is used when configuring the CM Server Role page?

A. System ID (SID)
B. System Manager MAC address
C. Product ID (PID)
D. CM Serial Number

Answer: A

Explanation:
When setting up or validating the configuration of Avaya Aura Communication Manager (CM), licensing plays a central role in activating the proper features and associating the system with a legitimate entitlement. The CM license file contains several critical fields, but not all of them are used for the same purpose.

One of the key identifiers in the license file is the System ID (SID). This identifier is unique to each licensed CM system and is what ties the license to a specific server or virtual machine. When configuring the CM Server Role page, the system must be correctly linked to its license to ensure that all associated features, capacities, and permissions are activated. This linkage is achieved using the System ID (SID), which is why it is the value from the license file that must be entered on the CM Server Role page.

Option B, the System Manager MAC address, is not part of the CM license configuration. While MAC addresses may be relevant in some networking or virtual machine setups, they are not directly involved in CM licensing or server role assignment. Option C, Product ID (PID), may appear in documentation or for inventory purposes, but it does not serve as the reference for server role assignment. Similarly, Option D, CM Serial Number, can also be found in inventory records but is not the value used on the Server Role page in relation to licensing.

Thus, among all the listed options, the System ID (SID) is the only reference directly tied to both the license file and the CM Server Role configuration. Without correctly entering this value, the system may not properly activate its licensed capabilities, leading to restricted functionality or license errors. Therefore, option A provides the correct and most relevant answer.

Question 7

You have set up a TLS signaling link between Avaya Aura® Communication Manager (CM) and Avaya Aura® Session Manager (SM). Session Manager is using identity certificates signed by the Certificate Authority (CA) provided by Avaya Aura® System Manager (SMGR). 

Which three steps must be completed to bring the TLS signaling link between CM and SM into service? (Choose three.)

A. Export SM Identity certificate from SMGR and import it into CM using "Security/Trusted Certificates".
B. Add the CA certificate to CM using "Security/Trusted Certificates" from the CM SMI screen.
C. Replace the CM default Server Identity Certificate with one generated by your Certificate Authority.
D. Download "binary/to IE" from SMGR.
E. Upload the CA certificate to CM using "Miscellaneous/Download files" from the CM SMI screen.

Correct answer: B, C, E

Explanation:
To establish a secure TLS link between Avaya Aura Communication Manager (CM) and Session Manager (SM), both systems must trust each other's certificates. Since SM uses a certificate signed by the Certificate Authority (CA) hosted by System Manager (SMGR), CM must trust that CA to accept SM's identity certificate during the TLS handshake. This process ensures encrypted and authenticated communication between the two systems.

First, let’s discuss the role of the Certificate Authority (CA). When SM's identity certificate is signed by SMGR’s CA, any system wanting to trust SM’s identity must trust the CA that issued that certificate. Therefore, CM must have the SMGR CA certificate in its trusted store.

Option B is correct because it directly refers to importing the CA certificate into CM’s trusted certificate store through the "Security/Trusted Certificates" section in the CM SMI (System Management Interface). This allows CM to validate the SM identity certificate during TLS handshake.

Option C is also correct. While CM might come with a default identity certificate, using a certificate signed by your own CA (which can be the same CA used by SMGR) ensures mutual trust and compliance with internal security policies. This replacement is necessary for CM to present a valid, verifiable certificate to SM during TLS negotiation.

Option E is a valid method for uploading the CA certificate into CM. In some versions of CM’s SMI, administrators may use the "Miscellaneous/Download files" option as a practical way to move certificate files into the system. This step is particularly important if option B is not sufficient alone or if SMI requires the file to be staged via the download mechanism.

Option A is incorrect because CM does not need the actual identity certificate of SM to establish trust; it only needs the CA certificate that signed it. Trusting individual identity certificates is not scalable or maintainable. Trusting the CA that issued the certificate is the standard and supported method.

Option D refers to downloading the certificate in a format that is typically used for browser-based imports (e.g., into Internet Explorer). This has no relevance to configuring TLS links between CM and SM, as the process on CM requires uploading certificates through its specific management interface, not browser-based import tools.

In conclusion, to bring the TLS link into service, CM must trust the CA that signed SM’s identity certificate and present a valid certificate of its own, ideally signed by the same CA. These actions ensure mutual authentication and secure communication over the TLS signaling link.

Question 8

What are the minimum three required links or relationships that must be established to form the Avaya Aura® Core? (Choose three.)

A. An LDAP link from Avaya Aura® System Manager (SMGR) to the corporate Directory Server
B. A SIP Trunk between Avaya Aura® Communication Manager (CM) and Avaya Aura® System Manager (SMGR)
C. A SIP Trunk between Avaya Aura® Session Manager (SM) and Avaya Aura® Communication Manager (CM)
D. An Avaya Aura® Communication Manager (CM) managed element in Avaya Aura® System Manager (SMGR)
E. A trust relationship between Avaya Aura® System Manager (SMGR) and Avaya Aura® Session Manager (SM)

Answer: C, D, E

Explanation:

The Avaya Aura Core is the foundational infrastructure required for unified communications using Avaya products. To establish basic functionality within this core, certain key relationships or links must be configured between its components. These include trust relationships, management definitions, and SIP connectivity.

One of the essential links is a trust relationship between System Manager (SMGR) and Session Manager (SM), as shown in option E. This trust relationship is crucial because System Manager centrally manages the entire Avaya Aura environment, including provisioning, configuration, and maintenance of Session Manager. Without this trust link, System Manager would not be able to control or communicate securely with Session Manager, rendering the management functionality inoperative.

Another critical component is a SIP trunk between Session Manager and Communication Manager, as indicated in option C. Session Manager is responsible for SIP routing in the Avaya Aura architecture. It connects to various SIP entities, and Communication Manager—though originally a TDM/PBX-style system—is often included in SIP environments via a SIP trunk to Session Manager. This SIP trunk allows call routing between CM and the rest of the SIP world, managed by Session Manager.

The third essential configuration is defining Communication Manager as a managed element in System Manager, which is what option D refers to. By doing this, System Manager can recognize, monitor, and configure Communication Manager as part of the Avaya Aura system. This is a required step to enable unified control and to integrate CM into the overall Aura Core structure.

Option A, the LDAP link from System Manager to a corporate directory, is useful for user management and synchronization, but it is not required to build the Aura Core itself. It is more of an auxiliary integration that supports enterprise directory access, such as syncing users from Microsoft Active Directory, rather than a structural necessity.

Option B, which mentions a SIP trunk between Communication Manager and System Manager, is invalid because System Manager does not handle real-time SIP traffic. System Manager is a management tool, not a media or SIP session handler, so SIP trunks are not established between it and Communication Manager.

In conclusion, to establish the minimum working configuration of the Avaya Aura Core, you must set up:

• A trust relationship between System Manager and Session Manager (option E)

• A SIP trunk between Session Manager and Communication Manager (option C)

• A managed element entry in System Manager for Communication Manager (option D)

These three links create the necessary foundation for communications, control, and system integration within the Avaya Aura architecture.

Question 9

When setting up Avaya Aura Communication Manager (CM) to be managed through Avaya Aura System Manager (SMGR), what designation is used for CM during the addition process?

A. Managed Element
B. Application Server
C. Feature Server
D. Sequenced Application

Answer: A

Explanation:
In the Avaya Aura architecture, System Manager (SMGR) provides centralized administration for various Avaya components, including Communication Manager (CM). To enable management capabilities such as feature control, configuration synchronization, and licensing visibility, CM must be registered within System Manager. This integration requires a specific designation.

The correct term for CM when it is added to System Manager for administrative purposes is Managed Element. This designation allows System Manager to communicate with CM using standard protocols like SSH and SOAP, enabling it to perform tasks such as viewing and editing translations, managing users, and synchronizing data. The Managed Element role specifically represents a system component whose configuration and operational data can be managed centrally.

Option B, Application Server, is not the correct term in this context. While CM may function as a server that delivers application-level services, this is not the label used when registering it in SMGR. Option C, Feature Server, refers more to the functional role that CM plays in providing telephony features to SIP endpoints via Session Manager. However, this is a functional term, not the administrative label used within SMGR. Option D, Sequenced Application, is a term used when defining call processing logic in Session Manager, often involving advanced routing or treatment of calls. It refers to applications that are part of an Application Sequence, which is not the same as configuring a system for management in SMGR.

Therefore, to administer a CM via SMGR, it must be defined as a Managed Element. This allows SMGR to track the system’s status, apply configuration changes, and ensure proper integration within the broader Avaya Aura environment. Without being added as a Managed Element, CM would not be visible to System Manager for administrative control, which would severely limit centralized operations. Hence, the correct and most precise answer is A.

Question 10

Which of the following best describes how licensing works for Avaya Aura® System Manager (SMGR)?

A. The SMGR license must be installed on a separate WebLM Server.
B. It does not need a license, regardless of release.
C. It requires a license from Release 7.1 onwards.
D. It only requires a license when implementing in a dual server redundant topology.

Correct answer: C

Explanation:
Avaya Aura System Manager (SMGR) acts as the centralized management platform for a range of Avaya Aura applications, including Session Manager, Communication Manager, and others. It provides a web-based interface for administrators to configure, monitor, and maintain these applications across the Avaya Aura environment.

Historically, early versions of SMGR did not require a license to operate. This licensing approach changed with the introduction of newer releases, starting from version 7.1. From this point forward, Avaya implemented licensing requirements for System Manager to align with broader changes in the Aura suite’s licensing strategy.

Option C is correct because it accurately states that starting with Release 7.1, System Manager requires a license. This means that in earlier versions, such as 6.x or 7.0, the platform could be deployed and operated without any license, but from 7.1 onward, licensing compliance became mandatory. This change was part of Avaya’s broader effort to centralize and standardize licensing across its products using the Web License Manager (WebLM) infrastructure.

Let’s examine why the other options are incorrect:

Option A is incorrect because while licensing is handled through the WebLM system, it does not necessarily require a separate WebLM server. In many cases, WebLM is co-resident with System Manager or another Aura component. The key requirement is that the license must be accessible and valid within the deployment, not that it must be hosted on a standalone server.

Option B is incorrect because, although earlier versions of SMGR (prior to 7.1) did not require a license, this is no longer true for more recent versions. The blanket statement that SMGR never needs a license is outdated and not applicable in environments using current software.

Option D is incorrect because the need for a license is not dependent on the system being deployed in a redundant or high-availability (HA) configuration. Licensing requirements are version-based and apply regardless of whether the platform is deployed as a single instance or as part of a dual-server topology.

In summary, as of Avaya Aura System Manager Release 7.1 and later, the application does require a license. This shift ensures better management and monitoring of Avaya systems, allows for better feature control, and aligns with Avaya’s unified licensing model. Therefore, understanding the release version of System Manager is critical in determining whether a license is required in a given deployment.