Topic 17 Practice Test 3 covers ACLs, CoPP, REST API Security, and Infrastructure Protection 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
An ACL relies on its implicit deny, but security operations now need log records for traffic that reaches the end of the policy. Which change preserves denial while adding visibility? Choose ONE.
- Replace the final deny with permit ip any any
- Rely only on the implicit deny
- Add an explicit deny ip any any log entry at the end
- Add a remark after the implicit deny
Correct Answer(s)
C
Rationale
- A final permit-all would defeat the deny-by-default requirement by allowing traffic that should remain blocked. That does not satisfy unmatched traffic must still be denied and the denial must become explicitly loggable; it changes a different behavior and leaves the decisive condition unresolved.
- The implicit deny enforces a drop at the end of an ACL, but it is not an explicit ACE that can be configured with the requested logging behavior. Although useful in another context, it cannot ensure that unmatched traffic must still be denied and the denial must become explicitly loggable, so the original failure would remain.
- An explicit final deny can preserve the default-deny policy while adding logging for traffic that would otherwise disappear at the implicit deny without a dedicated log ACE. That directly satisfies unmatched traffic must still be denied and the denial must become explicitly loggable, so it changes the exact condition responsible for the observed behavior without broadening the policy.
- A remark documents intent but performs no packet action and cannot cause packets discarded by the implicit deny to generate ACL match logs. This choice misses the controlling requirement that unmatched traffic must still be denied and the denial must become explicitly loggable; changing it would not correct the mechanism responsible for the issue.
Question 2
An ACL rule is technically correct, but reviewers cannot tell why it exists. The team wants inline documentation without changing packet handling. What should be added? Choose ONE.
- Add a remark entry describing the business purpose
- Rename the interface to describe the ACL
- Use a time range as the description
- Add a duplicate permit ACE with descriptive text
Correct Answer(s)
A
Rationale
- An ACL remark is nonmatching documentation that can explain why neighboring ACEs exist without changing permit, deny, or packet-selection behavior. Because the ACL needs nonmatching documentation adjacent to the policy entries, this option targets the mechanism that actually governs the result and avoids an unrelated workaround.
- An interface description can document the attachment point, but it does not annotate the individual ACL rule whose purpose needs to be clear. The requested outcome depends on the ACL needs nonmatching documentation adjacent to the policy entries. This alternative does not act on that condition and would leave the policy ineffective.
- A time range controls when an ACE is active and has operational meaning; it is not free-form documentation for explaining a rule. Using this would address a different layer or purpose while the requirement that the ACL needs nonmatching documentation adjacent to the policy entries remains unsatisfied.
- A duplicate permit still participates in packet matching and can change counters or maintenance complexity; it is not the documentation-only mechanism requested. The feature can be valid for other designs, yet it does not enforce or verify that the ACL needs nonmatching documentation adjacent to the policy entries in this scenario.
Question 3
A named ACL contains one obsolete ACE at sequence 40. All other entries are still valid and must remain untouched. What is the most surgical change? Choose ONE.
- Insert a deny above the unwanted ACE
- Delete the entire named ACL
- Convert the ACL to a numbered list first
- Remove the specific ACE by its sequence number
Correct Answer(s)
D
Rationale
- Adding another deny changes policy semantics and leaves the obsolete ACE in place; it does not perform the requested surgical removal. This option would not achieve the required state that one sequenced ACE must be removed without rebuilding the rest of the named ACL; its function is outside the path that determines the answer.
- Removing the whole ACL destroys unrelated entries and creates needless outage risk when only one sequenced ACE needs to be removed. The key constraint is one sequenced ACE must be removed without rebuilding the rest of the named ACL. This alternative neither changes nor verifies that condition, so it is not the appropriate fix.
- Changing the ACL identifier is unnecessary and can complicate maintenance; named ACLs already support sequence-based entry deletion. Here the engineer must ensure that one sequenced ACE must be removed without rebuilding the rest of the named ACL. This choice solves a different problem and would not meet the stated security objective.
- Named ACL sequence numbers allow a single entry to be deleted in ACL configuration mode, preserving the remaining policy rather than rebuilding the whole list. The decisive requirement is that one sequenced ACE must be removed without rebuilding the rest of the named ACL. This choice fulfills it at the correct control point while preserving the rest of the design.
Question 4
A standard IPv4 ACL must block one source network from reaching a particular server segment, but that source still needs access to other destinations. Where should the ACL generally be placed? Choose ONE.
- Apply the standard ACL to every interface
- Place the standard ACL close to the destination
- Place the standard ACL only on the control-plane interface
- Place the standard ACL as close to the source as possible
Correct Answer(s)
B
Rationale
- Duplicating a source-only policy across all interfaces broadens its effect and creates unnecessary operational complexity. Even if configured correctly, it would not guarantee that the source-only filter should avoid unintentionally blocking the source from unrelated destinations; the relevant decision is made by another mechanism.
- Because a standard IPv4 ACL primarily matches the source, placing it near the destination reduces the chance of blocking that source from unrelated destinations. Here, the source-only filter should avoid unintentionally blocking the source from unrelated destinations; this action addresses that requirement precisely and keeps unrelated forwarding or management behavior unchanged.
- The control-plane interface is not a general placement point for standard ACLs protecting arbitrary routed destinations. This approach leaves the central requirement—the source-only filter should avoid unintentionally blocking the source from unrelated destinations—unresolved and instead modifies a secondary or unrelated part of the system.
- Near-source placement is commonly preferred for extended ACLs, but a source-only standard ACL there can unintentionally block the source from many destinations. The problem is specifically about whether the source-only filter should avoid unintentionally blocking the source from unrelated destinations. This option has no direct effect on that condition and would not resolve the symptom.
Question 5
An ACL has accumulated thousands of historical hits. An engineer wants a controlled test to show only new matches generated during the next minute. What should be done first? Choose ONE.
- Clear the ACL match counters immediately before the controlled test
- Clear the routing table before testing
- Reload the device before testing
- Delete and recreate the ACL before testing
Correct Answer(s)
A
Rationale
- Clearing existing ACL counters creates a fresh measurement baseline, making it easier to attribute subsequent counter increments to the controlled test traffic. The scenario turns on one condition: the test needs a clean ACL-counter baseline without altering the policy. This option handles that condition directly instead of changing a different subsystem.
- Removing routes changes forwarding behavior and can invalidate the test; it is unrelated to resetting accumulated ACL hit counts. The scenario requires a mechanism that ensures the test needs a clean ACL-counter baseline without altering the policy. This alternative lacks that capability, even though it may be useful elsewhere.
- A reload is highly disruptive and unnecessary for obtaining a fresh view of ACL match counters. The required behavior is that the test needs a clean ACL-counter baseline without altering the policy. This choice does not implement that behavior and could distract from the actual corrective action.
- Rebuilding the policy would reset more than counters and introduces avoidable configuration risk when only a clean measurement baseline is needed. Because success depends on the test needs a clean ACL-counter baseline without altering the policy, this option is insufficient; it leaves the governing condition unchanged.
Question 6
A design review proposes using the ACL established keyword as proof that every returning TCP packet belongs to a valid session. Which assessment is correct? Choose ONE.
- Use established to validate UDP return flows
- Assume established performs full TCP state tracking
- Treat established as a limited flag check, not a stateful firewall
- Use established as a substitute for application inspection
Correct Answer(s)
C
Rationale
- UDP has no TCP ACK or RST flags, so the TCP-specific established match cannot provide return-flow validation for UDP traffic. That does not satisfy the team must not mistake TCP flag matching for full stateful session tracking; it changes a different behavior and leaves the decisive condition unresolved.
- An ACL with the established keyword does not keep the session state expected from a stateful firewall, so this assumption overstates the control. Although useful in another context, it cannot ensure that the team must not mistake TCP flag matching for full stateful session tracking, so the original failure would remain.
- The ACL established keyword checks TCP ACK or RST indicators; it does not maintain a connection table or validate that a flow belongs to a legitimately created session. With the team must not mistake TCP flag matching for full stateful session tracking, the control must operate where that decision is made. This option does so and therefore fits the stated constraint.
- TCP flag matching does not understand application protocol state or payload behavior, so it cannot replace application-layer inspection. This choice misses the controlling requirement that the team must not mistake TCP flag matching for full stateful session tracking; changing it would not correct the mechanism responsible for the issue.
Question 7
A VLAN access map has valid match and action sequences, yet test traffic in VLAN 120 is unaffected. Review shows the map was never associated with any VLAN. What is missing? Choose ONE.
- Enable spanning-tree portfast
- Activate the VLAN access map with vlan filter for the intended VLAN list
- Apply ip access-group outbound on the SVI
- Configure a switchport port-security maximum
Correct Answer(s)
B
Rationale
- PortFast changes spanning-tree convergence behavior on edge ports and has no role in activating a VACL policy. It may provide related information or configuration, but it does not make certain that the defined VLAN access map must be activated for the target VLAN, which is the deciding constraint.
- Defining a VLAN access map alone is not enough; the vlan filter command associates the map with one or more VLANs so the policy actually processes VLAN traffic. The requested outcome depends on the fact that the defined VLAN access map must be activated for the target VLAN. This choice implements the necessary behavior rather than merely masking the symptom.
- An SVI routed ACL filters Layer 3 traffic at that interface, but it does not activate an existing VLAN access map for bridged traffic within the VLAN. Using this would address a different layer or purpose while the requirement that the defined VLAN access map must be activated for the target VLAN remains unsatisfied.
- Port security limits learned Layer 2 source addresses on a switchport; it is unrelated to attaching a VLAN access map to a VLAN. The feature can be valid for other designs, yet it does not enforce or verify that the defined VLAN access map must be activated for the target VLAN in this scenario.
Question 8
A CoPP class intended for a management protocol shows zero packets even while that protocol is actively reaching the device. What should be checked first? Choose ONE.
- Clear the routing table
- Disable the control-plane service policy
- Increase the policer rate immediately
- Inspect the CoPP class-map and match criteria because zero counters mean the class is not matching
Correct Answer(s)
D
Rationale
- Removing routes can disrupt forwarding and does not explain why a control-plane class has no matches. This option would not achieve the required state that zero class counters indicate a classification problem before a policer-capacity problem; its function is outside the path that determines the answer.
- Detaching the policy eliminates the visibility and protection being diagnosed instead of correcting the class that is failing to match. The key constraint is zero class counters indicate a classification problem before a policer-capacity problem. This alternative neither changes nor verifies that condition, so it is not the appropriate fix.
- A higher rate cannot fix a class that is not matching any packets; zero counters point to classification before capacity. Here the engineer must ensure that zero class counters indicate a classification problem before a policer-capacity problem. This choice solves a different problem and would not meet the stated security objective.
- If a control-plane class remains at zero while relevant traffic is present, the first diagnostic step is to verify its class-map and underlying match criteria rather than alter policing rates. Since zero class counters indicate a classification problem before a policer-capacity problem, this is the option that aligns the configuration with the required processing model and keeps the correction narrowly scoped.
Question 9
A CoPP class drops legitimate control traffic continuously for several minutes, and measurements show the normal sustained rate is above the configured policer. Which adjustment best fits the evidence? Choose ONE.
- Increase only the burst allowance
- Move the class to a faster data-plane queue
- Disable the policer permanently
- Increase the sustained policer rate to a measured legitimate level
Correct Answer(s)
D
Rationale
- A larger burst helps short spikes, but it does not solve a legitimate rate that remains above the policer continuously over time. Even if configured correctly, it would not guarantee that the policer average must accommodate a measured legitimate sustained rate while retaining protection; the relevant decision is made by another mechanism.
- A data-plane queue does not change the sustained rate enforced by the control-plane policer on CPU-bound traffic. The design requirement is that the policer average must accommodate a measured legitimate sustained rate while retaining protection. This alternative cannot satisfy it without an additional change, so it is not the best answer.
- Removing the policer eliminates CPU protection and is unnecessary when the problem is a mis-sized sustained rate that can be tuned. This approach leaves the central requirement—the policer average must accommodate a measured legitimate sustained rate while retaining protection—unresolved and instead modifies a secondary or unrelated part of the system.
- When legitimate control traffic continuously exceeds the configured average, a measured increase to the sustained rate addresses the persistent mismatch while retaining an upper bound. The evidence points to a requirement that the policer average must accommodate a measured legitimate sustained rate while retaining protection. This selection acts on that requirement itself, which makes it the most appropriate response.
Question 10
A team is preparing CoPP for a production core device and has not yet selected class rates. What should it do before choosing the policer values? Choose ONE.
- Copy policer values from an unrelated device
- Measure normal and peak control-plane traffic before setting policing rates
- Wait for a production outage to tune CoPP
- Set every class to the same very low rate
Correct Answer(s)
B
Rationale
- Control-plane loads vary by platform, role, peers, and services, so another device’s values may be too strict or too permissive. Selecting this would not establish that policer rates should be based on observed legitimate control-plane behavior; it addresses a different operational concern and is therefore a poor fit.
- A baseline of legitimate protocol behavior provides evidence for class rates and bursts, reducing the chance that CoPP blocks expected routing or management activity. The policy must ensure that policer rates should be based on observed legitimate control-plane behavior. This choice provides that behavior directly and avoids introducing a broader exception than necessary.
- Reactive tuning after failure provides poor protection and increases operational risk compared with establishing a legitimate-traffic baseline first. The required behavior is that policer rates should be based on observed legitimate control-plane behavior. This choice does not implement that behavior and could distract from the actual corrective action.
- Different control-plane protocols have different traffic profiles; one arbitrarily low rate can cause avoidable drops and adjacency failures. Because success depends on policer rates should be based on observed legitimate control-plane behavior, this option is insufficient; it leaves the governing condition unchanged.
Question 11
A new CoPP policy drops valid routing hellos and updates in one class, causing neighbor resets. Other control-plane classes behave normally. What is the best targeted remediation? Choose ONE.
- Add a static default route
- Disable neighbor authentication
- Raise the routing-protocol class allowance enough for legitimate adjacency traffic
- Increase the data-plane interface bandwidth
Correct Answer(s)
C
Rationale
- A static route does not correct loss of protocol hellos or updates caused by CoPP and may mask rather than solve the adjacency problem. That does not satisfy the affected routing class needs enough measured capacity for legitimate protocol traffic; it changes a different behavior and leaves the decisive condition unresolved.
- Removing routing authentication weakens security and does not address policer drops that are preventing valid control packets from reaching the routing process. Although useful in another context, it cannot ensure that the affected routing class needs enough measured capacity for legitimate protocol traffic, so the original failure would remain.
- If overpolicing drops valid routing hellos or updates, adjusting the affected class within a measured safe envelope can restore adjacency stability while keeping other CoPP protections. Operationally, the key requirement is that the affected routing class needs enough measured capacity for legitimate protocol traffic. This option gives the engineer the needed control or evidence at the relevant layer.
- More egress bandwidth does not recover routing protocol packets that are being dropped by a CPU-bound control-plane policer before protocol processing. This choice misses the controlling requirement that the affected routing class needs enough measured capacity for legitimate protocol traffic; changing it would not correct the mechanism responsible for the issue.
Question 12
Operators see intermittent management and routing symptoms and suspect CoPP, but they need evidence before changing the policy. Which troubleshooting approach gives the strongest correlation? Choose ONE.
- Correlate class-specific drop counters with CPU load and protocol symptoms
- Inspect only switchport duplex
- Use only an endpoint ping test
- Use only the device uptime
Correct Answer(s)
A
Rationale
- Comparing CoPP class statistics with processor utilization and control-protocol behavior helps distinguish deliberate policing from a generic CPU or network fault. The security objective requires that the diagnosis should tie class-level policer behavior to processor and protocol symptoms. This selection meets that objective without weakening protections that are not part of the problem.
- Duplex settings can cause link problems, but they do not explain class-specific control-plane policer drops on a routed device. The requested outcome depends on the diagnosis should tie class-level policer behavior to processor and protocol symptoms. This alternative does not act on that condition and would leave the policy ineffective.
- A ping can reveal reachability but does not identify which control-plane class is dropping traffic or whether CPU load coincides with the event. Using this would address a different layer or purpose while the requirement that the diagnosis should tie class-level policer behavior to processor and protocol symptoms remains unsatisfied.
- Uptime can show whether a device rebooted, but it cannot attribute protocol symptoms to a specific CoPP class or policer action. The feature can be valid for other designs, yet it does not enforce or verify that the diagnosis should tie class-level policer behavior to processor and protocol symptoms in this scenario.
Question 13
A network automation platform uses bearer tokens. Security wants a stolen token to stop working automatically after a limited period. Which control best provides that property? Choose ONE.
- Create a token with no expiration
- Issue short-lived API tokens with an enforced expiration
- Disable TLS to simplify renewal
- Store the token in a URL parameter
Correct Answer(s)
B
Rationale
- A nonexpiring token remains valid until manually revoked, increasing the exposure window if the credential is copied or leaked. This option would not achieve the required state that the credential must become unusable automatically after a defined lifetime; its function is outside the path that determines the answer.
- A token with a limited lifetime reduces the period in which a stolen credential remains useful and forces periodic renewal through the approved authentication process. The troubleshooting result only makes sense if the credential must become unusable automatically after a defined lifetime. This option tests or corrects exactly that point and therefore resolves the stated issue.
- TLS protects the token while it crosses the network; removing encryption creates a new credential-exposure risk and has nothing to do with expiration. Here the engineer must ensure that the credential must become unusable automatically after a defined lifetime. This choice solves a different problem and would not meet the stated security objective.
- Placing a token in a query string can expose it through logs and history, and it does not limit how long the credential remains valid. The evidence calls for a control that makes the credential must become unusable automatically after a defined lifetime true. This option does not provide that control and therefore fails the requirement.
Question 14
A token used by an automation client is confirmed to have been copied into an unauthorized location. The API still accepts it. What should happen first? Choose ONE.
- Hide the token in a different source file
- Change only the API endpoint hostname
- Wait for the token to be used again
- Revoke the compromised token and issue a replacement
Correct Answer(s)
D
Rationale
- Moving the same compromised credential to another file does not revoke it at the server and cannot prevent replay by someone who already has the token. Even if configured correctly, it would not guarantee that the known-compromised credential must be invalidated at the service; the relevant decision is made by another mechanism.
- Changing a hostname does not invalidate a bearer credential that remains accepted by the service, so the compromised secret could still be replayed. The design requirement is that the known-compromised credential must be invalidated at the service. This alternative cannot satisfy it without an additional change, so it is not the best answer.
- Delaying action leaves a confirmed exposed credential active and gives an attacker more opportunity to use it. This approach leaves the central requirement—the known-compromised credential must be invalidated at the service—unresolved and instead modifies a secondary or unrelated part of the system.
- Revocation invalidates the known-bad credential immediately; creating a new token then restores authorized automation without leaving the exposed token usable. To satisfy the design, the known-compromised credential must be invalidated at the service. This choice implements that requirement explicitly rather than relying on side effects from another feature.
Question 15
A telemetry collector calls the API only to retrieve operational data. Which token scope best follows least privilege? Choose ONE.
- Scope the monitoring token to read-only operations
- Give the token full administrator rights
- Grant configuration-write access for convenience
- Use one unrestricted token for all API consumers
Correct Answer(s)
A
Rationale
- A monitoring client that only reads state should receive a token limited to read operations, minimizing the changes possible if that credential is abused. The implementation must guarantee that the credential should authorize reads without configuration-write capability. This option is built for that purpose and leaves unrelated controls available to do their own jobs.
- Administrator scope is unnecessary for telemetry reads and creates the largest avoidable privilege escalation if the credential is stolen. The scenario requires a mechanism that ensures the credential should authorize reads without configuration-write capability. This alternative lacks that capability, even though it may be useful elsewhere.
- Write permission exceeds a read-only monitoring requirement and expands the damage possible from a compromised client or token. The required behavior is that the credential should authorize reads without configuration-write capability. This choice does not implement that behavior and could distract from the actual corrective action.
- A broad shared token removes least-privilege boundaries and makes attribution and revocation harder across clients with different functions. Because success depends on the credential should authorize reads without configuration-write capability, this option is insufficient; it leaves the governing condition unchanged.
Question 16
An API client currently contacts an HTTP URL and follows a server redirect to HTTPS while sending authentication headers on its requests. What is the safer configuration? Choose ONE.
- Use an IP address with certificate checks disabled
- Disable redirects but keep using HTTP
- Configure the client to use the HTTPS API URL directly
- Send credentials over HTTP and follow the redirect
Correct Answer(s)
C
Rationale
- Bypassing certificate validation sacrifices server identity assurance and does not address the requirement to protect the first request with TLS. That does not satisfy TLS must protect the authenticated request from its first network transmission; it changes a different behavior and leaves the decisive condition unresolved.
- Preventing redirects does not encrypt the initial request and leaves API credentials vulnerable on the network. Although useful in another context, it cannot ensure that TLS must protect the authenticated request from its first network transmission, so the original failure would remain.
- Starting at the TLS-protected endpoint ensures credentials and request content are encrypted from the first request instead of depending on a server redirect. The important constraint is that TLS must protect the authenticated request from its first network transmission. This action respects that constraint and addresses the specific behavior the engineer needs to change.
- The initial HTTP request can expose headers or body content before any redirect occurs, so it is unsafe for authenticated management calls. This choice misses the controlling requirement that TLS must protect the authenticated request from its first network transmission; changing it would not correct the mechanism responsible for the issue.
Question 17
A misbehaving automation client can generate thousands of REST API calls and exhaust management-plane resources. Which control most directly limits that client’s impact? Choose ONE.
- Disable authentication during high load
- Send API traffic through the data-plane QoS queue only
- Apply per-client API rate limits and preserve capacity for legitimate management
- Increase every client’s request rate
Correct Answer(s)
C
Rationale
- Removing authentication lowers security exactly when the service is under stress and does not control request volume from clients. It may provide related information or configuration, but it does not make certain that one client must be prevented from consuming unbounded API request capacity, which is the deciding constraint.
- Data-plane queueing can affect transport priority, but it does not enforce request-level limits on the management API service. The requested outcome depends on one client must be prevented from consuming unbounded API request capacity. This alternative does not act on that condition and would leave the policy ineffective.
- Rate limiting constrains abusive or runaway request volume so one client is less likely to exhaust management-plane resources needed by administrators and automation. Because the environment requires that one client must be prevented from consuming unbounded API request capacity, this option is the focused correction and does not depend on an unsupported assumption.
- Higher limits amplify rather than contain a runaway caller and can worsen management-plane exhaustion. The feature can be valid for other designs, yet it does not enforce or verify that one client must be prevented from consuming unbounded API request capacity in this scenario.
Question 18
An audit requirement calls for evidence of attempted API abuse and administrative changes. Which logging design best supports that requirement? Choose ONE.
- Store audit logs only on the managed device with no protection
- Disable logging to reduce management CPU use
- Log only successful read requests
- Record API authentication failures and configuration changes in protected audit logs
Correct Answer(s)
D
Rationale
- A local-only unprotected log is easier for an attacker with device access to alter or erase, weakening its forensic value. This option would not achieve the required state that audit records must cover failed authentication and configuration-changing activity; its function is outside the path that determines the answer.
- Eliminating audit records removes visibility into authentication attacks and configuration changes instead of meeting the accountability requirement. The key constraint is audit records must cover failed authentication and configuration-changing activity. This alternative neither changes nor verifies that condition, so it is not the appropriate fix.
- Read-success logs can be useful, but omitting failed logins and configuration changes misses the events most relevant to access abuse and administrative accountability. Here the engineer must ensure that audit records must cover failed authentication and configuration-changing activity. This choice solves a different problem and would not meet the stated security objective.
- Authentication failures and change events provide accountability and incident evidence; protecting those logs helps prevent a compromised account from erasing the activity trail. The intended security posture depends on ensuring that audit records must cover failed authentication and configuration-changing activity. This choice enforces or verifies that condition at the right place.
Question 19
A router exposes several management API services, but only one is used by approved automation. What is the best hardening action for the unused services? Choose ONE.
- Expose the API on every routed interface
- Disable unused API services and endpoints
- Leave every API enabled for future convenience
- Allow anonymous access to unused endpoints
Correct Answer(s)
B
Rationale
- Broad exposure gives more networks a path to the management service and conflicts with reducing attack surface. Even if configured correctly, it would not guarantee that unneeded management interfaces should not remain reachable without an operational reason; the relevant decision is made by another mechanism.
- Turning off management interfaces that are not required reduces reachable attack surface and removes code paths that provide no operational value. The engineering goal is to make certain that unneeded management interfaces should not remain reachable without an operational reason. This option accomplishes that goal with the smallest relevant change.
- Unused services still expose listeners and functionality that can be scanned or attacked, increasing risk without a current business need. This approach leaves the central requirement—unneeded management interfaces should not remain reachable without an operational reason—unresolved and instead modifies a secondary or unrelated part of the system.
- Anonymous access weakens controls and creates exposure rather than safely retiring functionality that no client needs. The problem is specifically about whether unneeded management interfaces should not remain reachable without an operational reason. This option has no direct effect on that condition and would not resolve the symptom.
Question 20
A device REST API already uses HTTPS and authenticated accounts, but policy says only hosts on the management network may initiate API sessions. What additional control best enforces that boundary? Choose ONE.
- Restrict API access to the management network with an infrastructure ACL
- Place the API on the public Internet with a strong password
- Rely only on DNS to hide the management address
- Allow the API from any source if TLS is enabled
Correct Answer(s)
A
Rationale
- A source-restricting infrastructure ACL can limit which networks reach the management API, adding network-layer exposure control alongside authentication and TLS. Given that network-layer reachability to the management API must be limited to approved source networks, this approach matches the feature’s actual operating model and directly produces the required security outcome.
- A strong password helps authentication, yet broad Internet exposure still increases scanning, attack attempts, and exploit surface compared with management-network restriction. The scenario requires a mechanism that ensures network-layer reachability to the management API must be limited to approved source networks. This alternative lacks that capability, even though it may be useful elsewhere.
- DNS naming is not an access-control boundary; a reachable management IP can still be discovered and contacted without knowing its friendly name. The required behavior is that network-layer reachability to the management API must be limited to approved source networks. This choice does not implement that behavior and could distract from the actual corrective action.
- TLS protects confidentiality and server identity but does not by itself restrict which source networks can attempt to reach the service. Because success depends on network-layer reachability to the management API must be limited to approved source networks, this option is insufficient; it leaves the governing condition unchanged.