Cisco CCNP 350-401 ENCOR EEM and Agent-Based vs Agentless Orchestration Practice Test 2

 

Topic 20 Practice Test 2 covers EEM and Agent-Based vs Agentless Orchestration for Cisco 350-401 ENCOR. For broader exam preparation, review the Cisco 350-401 ENCOR Exam Dumps. Every option includes focused technical reasoning explaining both the Cisco enterprise networking concept and its fit to the scenario.

Question 1

A regulated network allows configuration through NETCONF but prohibits adding packages to production switches. The automation team needs repeatable configuration management. Which model introduces the least target-side change?

1. Install a resident orchestration agent on each switch
2. Replace NETCONF with an EEM watchdog on every device
3. Require administrators to make each change manually because NETCONF is not usable by automation
4. Use agentless orchestration over the existing NETCONF management interface

Correct Answer(s)

 

D

Rationale

1. A resident agent directly violates the prohibition on adding packages to the production software baseline. The environment already exposes a supported API but forbids installing extra software. It would also introduce a recurring compatibility and patching obligation on every regulated switch. For “regulated network allows configuration”, agentless orchestration over the existing NETCONF management interface is the relevant mechanism instead.
2. The environment already exposes a supported API but forbids installing extra software. EEM is local event automation, not a substitute for centralized configuration management, inventory, rollout control, and reporting across the fleet. Here “regulated network allows configuration” calls for agentless orchestration over the existing NETCONF management interface, not this alternative.
3. NETCONF is specifically a programmatic management interface and can be used by agentless automation; manual operation is unnecessary. The environment already exposes a supported API but forbids installing extra software. The existing NETCONF endpoint is exactly the kind of remote interface an agentless controller can consume.
4. The environment already exposes a supported API but forbids installing extra software. Agentless orchestration can operate through a supported remote API without installing a resident automation package. That keeps the target software baseline unchanged while still enabling centralized repeatable changes. Because of “regulated network allows configuration”, agentless orchestration over the existing NETCONF management interface is the appropriate design choice.

 

Question 2

A workload-security platform needs continuous process-level telemetry even when the central controller is briefly unreachable. Which characteristic can justify an agent-based approach?

1. Agent-based tools are automatically more secure than agentless tools
2. A resident agent can collect rich local telemetry on the workload and maintain local context
3. Agent-based tools eliminate the need for central policy or reporting
4. Agent-based tools require no lifecycle management

Correct Answer(s)

 

B

Rationale

1. The differentiator is deep, continuously available local observation rather than simple remote configuration. Security depends on implementation, privilege, communications, and lifecycle controls. Merely installing an agent does not guarantee a stronger security posture. For “workload security platform needs”, A resident agent can collect rich local telemetry on the workload is the relevant mechanism instead.
2. Because the software runs on the workload, an agent can observe process/package activity at a depth that network-only remote polling may not provide and can buffer or maintain local context during short controller disruptions. The differentiator is deep, continuously available local observation rather than simple remote configuration.
3. The differentiator is deep, continuously available local observation rather than simple remote configuration. A resident agent can enforce or collect locally, but enterprise orchestration still commonly depends on central policy, analytics, or coordination. Under “workload security platform needs”, A resident agent can collect rich local telemetry on the workload is required here; this alternative is not.
4. The resident component must be deployed, updated, secured, and kept compatible. That overhead is a trade-off, not an advantage. The differentiator is deep, continuously available local observation rather than simple remote configuration. Because of “workload security platform needs”, A resident agent can collect rich local telemetry on the workload better fits the design requirement.

 

Question 3

A network team is moving from scripts stored on routers to an agentless control platform. It wants faster credential rotation without editing every target. Which design supports that goal?

1. Use the same unchanging password in all inventory entries
2. Embed the password in every EEM applet
3. Reference centrally managed credentials or a secrets system from the orchestration platform
4. Disable authentication on the management API

Correct Answer(s)

 

C

Rationale

1. Central storage alone does not justify a shared permanent secret. The requirement emphasizes rotation and controlled credential management. The objective is to move secret lifecycle management away from thousands of device-local copies. For “network team moving scripts”, Reference centrally managed credentials or a secrets system from the orchestration platform is the relevant mechanism instead.
2. The objective is to move secret lifecycle management away from thousands of device-local copies. That spreads the secret across the fleet and makes rotation a device-by-device configuration change, exactly the problem the team wants to eliminate. Here “network team moving scripts” calls for Reference centrally managed credentials or a secrets system from the orchestration platform, not this alternative.
3. Agentless workflows can keep authentication material under central control and use it when opening supported management sessions. Rotating the secret there avoids distributing static credentials inside device-local scripts. The objective is to move secret lifecycle management away from thousands of device-local copies.
4. The objective is to move secret lifecycle management away from thousands of device-local copies. Removing authentication trades an operational inconvenience for a serious management-plane vulnerability and is unnecessary for automated credential use. Because of “network team moving scripts”, Reference centrally managed credentials or a secrets system from the orchestration platform better fits the design requirement.

 

Question 4

A configuration job may be rerun after a timeout, and the team wants a second successful run to leave the device in the same desired state rather than duplicate configuration. Which orchestration behavior is most valuable?

1. Use idempotent/declarative tasks that converge the device on the desired state
2. Use only raw CLI commands that append configuration every time
3. Install an agent solely so every command is executed twice
4. Run an EEM watchdog every second until the configuration appears

Correct Answer(s)

 

A

Rationale

1. The failure mode is an uncertain retry, so repeatability without duplicate side effects is the deciding property. Idempotent automation checks or models the target state so rerunning the workflow does not blindly repeat side effects. That is important when the control node cannot be certain whether the first attempt completed before the connection failed.
2. Blind append behavior can create duplicates or repeated side effects after a retry. It does not satisfy the convergence requirement. The failure mode is an uncertain retry, so repeatability without duplicate side effects is the deciding property. Here “configuration job may rerun” calls for idempotent/declarative tasks that converge the device on the desired state, not this alternative.
3. The failure mode is an uncertain retry, so repeatability without duplicate side effects is the deciding property. Agent presence does not make repeated operations safe. The key property is how the automation models and applies state. Under “configuration job may rerun”, idempotent/declarative tasks that converge the device on the desired state is required here; this alternative is not.
4. Continuous local retries can amplify mistakes and do not provide the declarative convergence semantics requested for the centralized workflow. The failure mode is an uncertain retry, so repeatability without duplicate side effects is the deciding property. Because of “configuration job may rerun”, idempotent/declarative tasks that converge the device on the desired state better fits the design requirement.

 

Question 5

An EEM applet has ten actions and must guarantee that initialization runs before validation and remediation. Which labeling practice avoids lexical surprises as the list grows?

1. Give every action the same label
2. Use consistently zero-padded action labels such as 01.0 through 10.0
3. Order the lines visually in the configuration and ignore labels
4. Use labels 1, 2, 3, …, 10 without padding

Correct Answer(s)

 

B

Rationale

1. Action labels identify and order actions; duplicates do not create a deterministic sequence and defeat the purpose of explicit ordering. The applet is growing beyond single-digit labels, so lexical ordering must be accounted for deliberately. For “eem applet has ten”, consistently zero-padded action labels such as 01.0 through 10.0 is the relevant mechanism instead.
2. The applet is growing beyond single-digit labels, so lexical ordering must be accounted for deliberately. EEM sorts action labels lexicographically. A fixed-width scheme preserves the intended order when action numbers reach two digits, preventing `10.0` from sorting between `1.0` and `2.0`.
3. EEM execution follows the action-label sort, not simply the textual order in which lines happen to be displayed. The applet is growing beyond single-digit labels, so lexical ordering must be accounted for deliberately. Under “eem applet has ten”, consistently zero-padded action labels such as 01.0 through 10.0 is required here; this alternative is not.
4. The applet is growing beyond single-digit labels, so lexical ordering must be accounted for deliberately. Once the list reaches two digits, lexical sorting can place label 10 before label 2. That can reorder dependent actions. Because of “eem applet has ten”, consistently zero-padded action labels such as 01.0 through 10.0 better fits the design requirement.

 

Question 6

A security review requires every automated configuration command to appear under a dedicated service identity in TACACS+ logs. Which EEM design best supports that?

1. Put the service account name only in a syslog action
2. Use authorization bypass so the commands cannot be rejected
3. Configure an EEM CLI session username with appropriate privilege and keep AAA authorization enabled
4. Run the applet with no associated username

Correct Answer(s)

 

C

Rationale

1. The requirement is attributable, centrally authorized automation rather than merely successful command execution. A log string is not the AAA identity used for CLI authorization. It can supplement audit records but does not bind the command session to the account.
2. Bypass undermines the explicit requirement that TACACS+ authorize and attribute the commands. It should not be the default for an auditable service identity. The requirement is attributable, centrally authorized automation rather than merely successful command execution. Here “security review requires every” calls for an EEM CLI session username with appropriate privilege, not this alternative.
3. The requirement is attributable, centrally authorized automation rather than merely successful command execution. Binding EEM CLI actions to a dedicated identity lets TACACS+ evaluate and record the automated session. Least-privilege authorization can then distinguish the applet from human administrators. Under “security review requires every”, an EEM CLI session username with appropriate privilege supplies the needed behavior.
4. Without a defined EEM CLI identity, the authorization and accounting records cannot reliably meet the service-account attribution requirement. The requirement is attributable, centrally authorized automation rather than merely successful command execution. Because of “security review requires every”, an EEM CLI session username with appropriate privilege better fits the design requirement.

 

Question 7

An EEM environment variable currently contains a highly sensitive reusable password. Why is this a poor design even though variables are convenient?

1. EEM variables cannot contain strings
2. EEM variables can be referenced only by SNMP detectors
3. Passwords become harmless when the variable name begins with an underscore
4. Treat EEM environment variables as configuration values, not as a substitute for a dedicated secrets-protection mechanism

Correct Answer(s)

 

D

Rationale

1. They can hold string values, so data type is not the problem. The issue is the security lifecycle of sensitive material. The concern is protection and rotation of a credential, not reuse of ordinary policy configuration. For “eem environment variable currently”, Treat EEM environment variables as configuration values, not as a substitute for a is the relevant mechanism instead.
2. The concern is protection and rotation of a credential, not reuse of ordinary policy configuration. Variables can be used by policy actions and logic; their utility is broader than SNMP. That does not make them a secure secret store. Here “eem environment variable currently” calls for Treat EEM environment variables as configuration values, not as a substitute for a, not this alternative.
3. A naming convention does not encrypt or protect the value. In fact, leading underscores are normally reserved for EEM-provided variables. The concern is protection and rotation of a credential, not reuse of ordinary policy configuration. Under “eem environment variable currently”, Treat EEM environment variables as configuration values, not as a substitute for a is required here; this alternative is not.
4. The concern is protection and rotation of a credential, not reuse of ordinary policy configuration. Environment variables improve reuse but do not inherently provide a vault, rotation workflow, or least-privilege secret retrieval. Highly sensitive credentials should be handled by an appropriate authentication or secrets design instead of plain reusable policy variables.

 

Question 8

A junior engineer puts `action syslog` in the applet and expects that syslog line to be the condition that starts the policy. What is the conceptual error?

1. Every action implicitly becomes an event detector
2. The applet should use an environment variable instead of any event
3. Syslog can be used only as an event and never as an action
4. An action runs after an event; the applet still needs an event detector such as event syslog to register the trigger

Correct Answer(s)

 

D

Rationale

1. The configuration confuses the condition that starts a policy with an operation performed after it starts. Actions are not automatically registered as triggers. Conflating the two phases makes the policy unregistered or behave differently from the engineer’s intent. For “junior engineer puts action”, An action runs after an event is the relevant mechanism instead.
2. A variable is data, not a trigger. An explicit event detector remains required for autonomous execution. The configuration confuses the condition that starts a policy with an operation performed after it starts. Here “junior engineer puts action” calls for An action runs after an event, not this alternative.
3. The configuration confuses the condition that starts a policy with an operation performed after it starts. EEM supports both a syslog event detector and a syslog action, so the technology can play either role depending on configuration context. Under “junior engineer puts action”, An action runs after an event is required here; this alternative is not.
4. EEM separates event registration from post-trigger actions. `action syslog` writes a message after execution begins, whereas `event syslog pattern …` watches for a matching log line and causes the policy to start. The configuration confuses the condition that starts a policy with an operation performed after it starts.

 

Question 9

An EEM remediation can shut an interface. The trigger might flap repeatedly, so operations wants to reduce the chance of repeated disruptive execution. Which design principle is best?

1. Shorten the action labels
2. Add explicit state checks or guard conditions so the action runs only when the intended preconditions still hold
3. Make the syslog pattern broader so more messages trigger the applet
4. Use authorization bypass to ensure the action never fails

Correct Answer(s)

 

B

Rationale

1. Label length does not validate current state or suppress repeated triggers. Ordering is separate from guard logic. The risk comes from repeated or stale events causing a destructive action after conditions have changed. For “eem remediation shut interface”, Add explicit state checks or guard conditions so the action runs only when is the relevant mechanism instead.
2. The risk comes from repeated or stale events causing a destructive action after conditions have changed. Event-driven automation should verify that the corrective action remains appropriate at execution time. A guard that checks current state prevents a stale or repeated trigger from applying the same disruptive change blindly.
3. Broader matching increases the chance of unnecessary execution and works against the safety goal. The risk comes from repeated or stale events causing a destructive action after conditions have changed. More matches would increase false-positive executions instead of validating that the interface condition is still actionable.
4. The risk comes from repeated or stale events causing a destructive action after conditions have changed. Bypass addresses AAA, not whether the action is operationally safe. It can also expand privilege without preventing repeated shutdowns. Because of “eem remediation shut interface”, Add explicit state checks or guard conditions so the action runs only when better fits the design requirement.

 

Question 10

A team wants peer review, version history, and rollback of multi-device configuration logic before it reaches production. What is the strongest reason to keep the orchestration workflow off-box in a repository?

1. Off-box storage means device authentication is no longer necessary
2. Version control guarantees every network change is correct
3. Centralized playbooks and roles can be version-controlled and reviewed as code before execution
4. Local EEM policies cannot be backed up

Correct Answer(s)

 

C

Rationale

1. The requirement concerns governance of the automation artifact across a fleet, not only device-local execution. The control system still must authenticate and be authorized to change targets. Source control governs the workflow; it does not replace AAA. For “team wants peer review”, Centralized playbooks and roles can be version-controlled and reviewed as code before execution is the relevant mechanism instead.
2. Review and history reduce risk but do not prove technical correctness. Validation, testing, and controlled deployment are still required. The requirement concerns governance of the automation artifact across a fleet, not only device-local execution. Here “team wants peer review” calls for Centralized playbooks and roles can be version-controlled and reviewed as code before execution, not this alternative.
3. The requirement concerns governance of the automation artifact across a fleet, not only device-local execution. Keeping the workflow in source control gives the team a change history, code review process, and reproducible automation artifact. That is easier to govern than independently editing equivalent local scripts on many devices.
4. They can be captured as configuration, but duplicating and coordinating fleet logic on individual devices is less suitable for a centrally reviewed multi-device workflow. The requirement concerns governance of the automation artifact across a fleet, not only device-local execution. Because of “team wants peer review”, Centralized playbooks and roles can be version-controlled and reviewed as code before execution better fits the design requirement.

 

Question 11

A security zone permits outbound connections from devices but blocks inbound management sessions from the automation controller. Which architectural trade-off becomes relevant?

1. EEM environment variables automatically open the firewall
2. Install an agent and ignore authentication because the session is outbound
3. Agentless automation always works without any network path
4. A resident agent that initiates an outbound control channel may fit where controller-initiated agentless sessions are prohibited

Correct Answer(s)

 

D

Rationale

1. Local configuration variables cannot alter an upstream security policy unless a separate authorized action changes it. The key architectural constraint is which side is permitted to initiate the management connection. Firewall policy must be changed through its own authorized control path rather than by naming a local variable.
2. The key architectural constraint is which side is permitted to initiate the management connection. Connection direction does not remove the need for secure mutual authentication, authorization, and protected transport. The outbound session still needs a trusted identity and permissions appropriate to the actions the agent can perform.
3. Agentless removes resident software; it does not eliminate the need for a communication channel between controller and target. The key architectural constraint is which side is permitted to initiate the management connection. Under “security zone permits outbound”, A resident agent that initiates an outbound control channel may fit where controller-initiated is required here; this alternative is not.
4. The key architectural constraint is which side is permitted to initiate the management connection. Agentless tools commonly need the controller to reach a device management interface. If policy forbids that direction, an agent model that establishes its own allowed outbound session can change the connectivity requirement, at the cost of deploying and maintaining the agent.

 

Question 12

An agentless platform must update 5,000 devices. There is no target agent to schedule work locally. What should capacity planning emphasize?

1. Disable API rate limits to maximize speed
2. Only the amount of flash memory on each switch
3. Control-node concurrency, management-path capacity, rate limits, and staged batching
4. Install an agent on every device after the first run

Correct Answer(s)

 

C

Rationale

1. The execution model concentrates scheduling and remote-session pressure on the control side. Removing protective limits can overload controllers or devices. Capacity should be managed with concurrency and staged execution, not by eliminating safety controls. For “agentless platform update 000”, Control-node concurrency, management-path capacity, rate limits is the relevant mechanism instead.
2. Target storage may matter for some operations, but it does not address the central bottleneck created by thousands of controller-initiated management sessions. The execution model concentrates scheduling and remote-session pressure on the control side. Here “agentless platform update 000” calls for Control-node concurrency, management-path capacity, rate limits, not this alternative.
3. The execution model concentrates scheduling and remote-session pressure on the control side. With agentless execution, the controller initiates and coordinates many remote sessions. Scaling therefore depends heavily on control-plane concurrency, network/API limits, and batching rather than on distributing all scheduling to resident agents.
4. That changes the architecture instead of sizing the chosen agentless model and may violate the original operational constraints. The execution model concentrates scheduling and remote-session pressure on the control side. The original design specifically chose controller-initiated sessions, so adding resident software is not a scaling calculation.

 

Question 13

A single router must sample a local counter every 30 seconds and take a local action with sub-minute latency. A central scheduler would add WAN dependency. Which mechanism is the better fit?

1. Use an on-device EEM timer/event policy for the narrow local task
2. Run a daily agentless playbook from the controller
3. Install a fleet agent solely to sample this one router
4. Use event none

Correct Answer(s)

 

A

Rationale

1. A local EEM policy can evaluate and act on the device without waiting for a WAN round trip or a central job queue. For a narrowly scoped, high-frequency local check, that reduces external dependencies. The task is local, frequent, and must remain independent of WAN/controller availability.
2. The task is local, frequent, and must remain independent of WAN/controller availability. A daily schedule cannot meet the 30-second requirement and also depends on the WAN path the design is trying to avoid. Here “single router sample local” calls for an on-device EEM timer/event policy for the narrow local task, not this alternative.
3. A resident third-party agent adds lifecycle overhead when the platform already provides a local event framework suited to the specific task. The task is local, frequent, and must remain independent of WAN/controller availability. Under “single router sample local”, an on-device EEM timer/event policy for the narrow local task is required here; this alternative is not.
4. The task is local, frequent, and must remain independent of WAN/controller availability. Manual execution provides no periodic sampling and would require an operator every 30 seconds. It therefore cannot satisfy the recurring sampling interval without an external operator repeatedly launching the policy. Because of “single router sample local”, an on-device EEM timer/event policy for the narrow local task better fits the design requirement.

 

Question 14

An EEM applet intended for one interface-down condition fires on many unrelated interface messages. What is the most direct remediation?

1. Change all action labels to letters
2. Switch to authorization bypass
3. Tighten the syslog regular-expression pattern so it matches the intended signature only
4. Add more CLI actions after every trigger

Correct Answer(s)

 

C

Rationale

1. The applet’s logic is correct after launch; the defect is excessive event matching. Action labels affect execution order after a trigger. They do not determine which syslog messages match. Only the event regular expression controls which incoming log lines qualify as triggers.
2. AAA behavior is unrelated to the overly broad trigger and would weaken a separate control without fixing false matches. The applet’s logic is correct after launch; the defect is excessive event matching. Here “eem applet intended interface” calls for Tighten the syslog regular-expression pattern so it matches the intended signature only, not this alternative.
3. The applet’s logic is correct after launch; the defect is excessive event matching. The syslog detector triggers on pattern matches. Making the expression more specific reduces false activations without changing the corrective actions themselves. Under “eem applet intended interface”, Tighten the syslog regular-expression pattern so it matches the intended signature only supplies the needed behavior.
4. Extra actions do not improve event selectivity and could make false activations more disruptive. The applet’s logic is correct after launch; the defect is excessive event matching. Once the false trigger occurs, more actions merely add side effects to an already incorrect launch.

 

Question 15

An EEM action waits forever after issuing `clear counters` because the command prompts for confirmation. Why does an incorrect prompt pattern cause this behavior?

1. The CLI action waits for the configured expected prompt, so a pattern that never matches leaves the interaction pending until the policy times out
2. The syslog facility must be changed to local7
3. EEM ignores all regular expressions in CLI actions
4. The command becomes an event detector when it prompts

Correct Answer(s)

 

A

Rationale

1. Interactive EEM CLI automation depends on matching the device prompt before supplying the next response. If the regular expression is wrong, the policy has no signal that it can continue. The policy is blocked waiting for an input cue that its configured regular expression never recognizes.
2. The policy is blocked waiting for an input cue that its configured regular expression never recognizes. Syslog facility settings do not govern interactive command prompts or EEM’s wait condition. Changing where logs are categorized cannot make EEM recognize the confirmation prompt returned by the CLI.
3. Cisco EEM supports a pattern option specifically for commands that solicit input, so regex matching is part of the interaction mechanism. The policy is blocked waiting for an input cue that its configured regular expression never recognizes. Under “eem action waits forever”, The CLI action waits for the configured expected prompt, so a pattern that is required here; this alternative is not.
4. The policy is blocked waiting for an input cue that its configured regular expression never recognizes. A prompt does not change an action into an event. The applet is already executing and is blocked in its CLI exchange. Because of “eem action waits forever”, The CLI action waits for the configured expected prompt, so a pattern that better fits the design requirement.

 

Question 16

An Ansible control node has valid credentials, but a new router has neither SSH nor any supported API enabled. What must happen before agentless automation can manage it?

1. Install the Ansible agent even though the design is agentless
2. Add the router to inventory and no other preparation is needed
3. Create an EEM applet that waits for Ansible to appear
4. Establish at least one supported and reachable management interface for the control node

Correct Answer(s)

 

D

Rationale

1. The missing prerequisite is a remote management channel, not target-side orchestration software. That abandons the selected architecture and is not required when the router can expose a supported management interface. The correct prerequisite is to enable and permit a supported remote protocol, not change deployment models.
2. Inventory tells the controller that the target exists, but it does not create network reachability or enable a management protocol on the router. The missing prerequisite is a remote management channel, not target-side orchestration software. Here “ansible control node has” calls for Establish at least one supported, not this alternative.
3. The missing prerequisite is a remote management channel, not target-side orchestration software. EEM cannot make an external controller reach a device when no usable management protocol is enabled. A local applet cannot create the controller-to-device TCP path or enable a disabled management service on its own.
4. Agentless automation still requires a transport and management endpoint. Valid credentials cannot be presented until the controller can establish a supported session to the device. The missing prerequisite is a remote management channel, not target-side orchestration software. Because of “ansible control node has”, Establish at least one supported is the appropriate design choice.

 

Question 17

A controller can change every campus router at once, but the team wants to limit blast radius during a new automation rollout. Which execution strategy is best?

1. Use the same untested EEM applet on every router at the same time
2. Use staged batches/canaries with validation gates before expanding the rollout
3. Disable validation because retries will fix any problem
4. Increase parallelism to the maximum supported value

Correct Answer(s)

 

B

Rationale

1. Distributed local execution does not provide the requested canary progression and can make a faulty policy harder to halt centrally. The organization is explicitly trading speed for controlled exposure during first deployment. For “controller change every campus”, staged batches/canaries with validation gates before expanding the rollout is the relevant mechanism instead.
2. The organization is explicitly trading speed for controlled exposure during first deployment. A phased workflow limits simultaneous exposure and creates checkpoints to detect bad assumptions before they affect the entire fleet. Central orchestration makes this controlled sequencing practical. Here “controller change every campus” directly calls for staged batches/canaries with validation gates before expanding the rollout.
3. Retries can repeat a harmful action and cannot substitute for checking correctness before wider deployment. The organization is explicitly trading speed for controlled exposure during first deployment. A retry mechanism has no knowledge that the underlying command or state transition was safe in the first place.
4. The organization is explicitly trading speed for controlled exposure during first deployment. Maximum concurrency increases blast radius and reduces the opportunity to stop after early failures, which is the opposite of the stated risk objective. Because of “controller change every campus”, staged batches/canaries with validation gates before expanding the rollout better fits the design requirement.

 

Question 18

A WAN edge should immediately write a syslog warning when a tracked local state changes, but no configuration change is needed. What is the lightest EEM design?

1. Use authorization bypass because the applet does not modify configuration
2. Use the appropriate local event detector and a syslog action only
3. Add a privileged CLI configuration action even though no state change is required
4. Use a fleet orchestration workflow that polls every device each second

Correct Answer(s)

 

B

Rationale

1. The requested response is informational only, so the policy should avoid unnecessary privileged actions. Bypass is unnecessary for a simple logging action and weakens the security posture without solving a requirement. For “wan edge immediately write”, the appropriate local event detector is the relevant mechanism instead.
2. EEM can monitor a local event and emit an informational message without invoking configuration commands. Keeping the policy to one trigger and one logging action reduces privilege and side effects. The requested response is informational only, so the policy should avoid unnecessary privileged actions.
3. The requested response is informational only, so the policy should avoid unnecessary privileged actions. Unnecessary configuration commands increase risk and AAA requirements without contributing to the warning objective. Avoiding the configuration action also reduces the AAA privilege required by this informational policy.
4. Central polling adds scale and WAN dependencies for a condition that the device can detect locally and report immediately. The requested response is informational only, so the policy should avoid unnecessary privileged actions. Because of “wan edge immediately write”, the appropriate local event detector better fits the design requirement.

 

Question 19

A team uses EEM for emergency local remediation and a centralized controller for normal configuration. Which boundary is the most defensible?

1. Keep narrowly scoped event-response logic local and keep fleet intent, inventory, and broad configuration changes centralized
2. Put all fleet configuration into EEM so the controller is unnecessary
3. Move every local fault response to the controller even when WAN loss is part of the failure mode
4. Install a resident agent solely to replace both EEM and the controller

Correct Answer(s)

 

A

Rationale

1. This division uses each mechanism for its strength: EEM reacts to device-local events even during controller outages, while the orchestration platform governs multi-device desired state and workflow history. The architecture intentionally separates immediate local resilience from coordinated enterprise configuration.
2. The architecture intentionally separates immediate local resilience from coordinated enterprise configuration. EEM lacks the natural central inventory, coordinated rollout, and source-controlled fleet workflow expected from orchestration. Coordinated desired state and per-device results are controller responsibilities that EEM does not naturally aggregate.
3. If controller reachability can disappear during the event, off-box-only remediation cannot satisfy the resilience requirement. The architecture intentionally separates immediate local resilience from coordinated enterprise configuration. The outage removes the very transport the controller would need to issue the corrective command.
4. The architecture intentionally separates immediate local resilience from coordinated enterprise configuration. One deployment model does not automatically subsume the distinct needs for local event handling and centrally governed fleet changes. It also creates another software lifecycle without defining whether local or central logic owns the remediation.

 

Question 20

A network engineer rejects Ansible because the switch does not provide a general-purpose Python runtime for Ansible code. What is the better interpretation?

1. Agentless network automation can execute from the control node and use supported device interfaces without requiring a persistent on-box Ansible/Python agent
2. The switch must run an EEM Tcl policy for every Ansible task
3. No target-side capability is needed at all, including any management protocol
4. Ansible always copies and permanently runs its controller on the switch

Correct Answer(s)

 

A

Rationale

1. The concern confuses where orchestration logic runs with whether the target exposes a usable management interface. For network platforms, Ansible commonly drives modules from the controller and communicates through SSH or APIs. The absence of a resident automation runtime on the switch does not by itself prevent agentless management.
2. EEM and Ansible are independent automation mechanisms; EEM is not a mandatory execution host for Ansible playbooks. The concern confuses where orchestration logic runs with whether the target exposes a usable management interface. Here “network engineer rejects ansible” calls for Agentless network automation can execute from the control node, not this alternative.
3. The concern confuses where orchestration logic runs with whether the target exposes a usable management interface. The target still needs a supported reachable interface and the required device features; agentless does not mean communication-free. Under “network engineer rejects ansible”, Agentless network automation can execute from the control node is required here; this alternative is not.
4. That is inconsistent with an agentless architecture and with Cisco examples that use remote management interfaces. The concern confuses where orchestration logic runs with whether the target exposes a usable management interface. Because of “network engineer rejects ansible”, Agentless network automation can execute from the control node better fits the design requirement.

• < Cisco CCNP 350-401 ENCOR EEM and Agent-Based vs Agentless Orchestration Practice Test 1