Endpoint Compliance practice questions

NAC Agent Log (nac_agent.log)

Why it fails: The NAC Agent is legacy; the question specifies the AnyConnect Compliance Module.

Windows Event Viewer - Application Log

Why it fails: While some errors appear here, the detailed scanning logic is in the AnyConnect directory.

ISE Posture Log (ise_posture.log)

Why it fails: This log is on the ISE server, not the client endpoint.

Posture Type set to 'Continuos'

Why it fails: 'Continuous' re-evaluates posture periodically after the initial assessment; it does not force a scan when the endpoint already reports compliant. Forcing a scan regardless of status is achieved by enabling the posture policy's re-scan or 'Audit' enforcement action.

Policy Status set to 'Production'

Why it fails: Policy Status governs whether the posture policy is active or in a test state, not scan enforcement; a forced rescan comes from the Posture Requirement setting. It is tempting because Production sounds like the live, enforcing mode, and it would be the right choice when promoting a validated policy from Test to live deployment.

Process Kill Remediation

Why it fails: There is no 'Process Kill' remediation type; you would use a script or service remediation.

Network Remediation

Why it fails: This is not a built-in ISE remediation type.

User Prompt Remediation

Why it fails: There is no 'User Prompt' remediation type.

Network Access Device (NAD)

Why it fails: The NAD merely relays RADIUS requests and enforces the resulting authorisation; it does not initiate the posture assessment itself. It is tempting because the NAD is the first device the endpoint contacts, and it would be the correct answer if the question asked which component enforces the access decision.

AnyConnect Compliance Module

Why it fails: The Compliance Module supplies the individual posture checks the agent runs; it does not trigger the assessment. It is tempting because it is the component that actually performs scanning work, and it would be correct if the question asked which module provides the condition logic for a specific check.

RADIUS Server

Why it fails: The RADIUS server evaluates credentials and returns authorisation attributes; it does not trigger posture assessment on the endpoint. It is tempting because it sits centrally in the authentication flow, and it would be the correct answer if the question asked which component returns the posture status to the NAD.

Administration > Identity Management

Why it fails: This is for user/device management.

Policy > Posture > Reports

Why it fails: Reports are not located under the Policy menu.

The Client Provisioning policy is misconfigured

Why it fails: This would prevent the agent from even installing or launching.

The remediation action is disabled

Why it fails: This would lead to a 'Non-Compliant' status, not 'Unknown'.

The authorization rule is incorrect

Why it fails: While possible, the state 'Unknown' usually implies no posture data has reached the server.

By configuring a 'Mandatory' posture requirement

Why it fails: This only dictates the requirement, not the local service protection.

By setting the 'Posture Type' to 'System'

Why it fails: There is no such posture type.

By enabling 'Auto-Restart' in the ISE global settings

Why it fails: ISE global settings do not control the local AnyConnect service process state.

prrt-server.log

Why it fails: This is for RADIUS-related logs.

guest.log

Why it fails: This is for guest access flows.

admin.log

Why it fails: This is for administrative configuration changes.

User Identity Condition

Why it fails: Not a valid posture condition type.

Port Condition

Why it fails: Not a valid posture condition type.

VLAN Remediation

Why it fails: VLAN assignment is an auth result, not a posture remediation action.

ACL Remediation

Why it fails: ACLs are applied as auth results.

Device ID

Why it fails: Not a part of the posture requirement object.

Authorization Rule

Why it fails: This is in the policy, not the requirement.

Includes All

Why it fails: Not a valid operator.

Exists Only

Why it fails: Not a valid operator name.

The Compliance Module is not installed on the ISE server.

Why it fails: The compliance module is installed on the client endpoint, not the ISE server.

The Remediation Action is disabled.

Why it fails: Disabling a remediation action does not cause the status to be 'Unknown'; it simply prevents the user from fixing a non-compliant state.

The Posture Agent configuration is missing the server discovery URL.

Why it fails: While this could cause an issue, the most common administrative oversight in policy mapping is failing to associate the policy with the auth profile.

The ISE server certificate is not trusted by the client.

Why it fails: If the certificate were not trusted, the agent would typically fail to connect entirely rather than appearing as 'Unknown'.

Use 'ROOT:HKLM'.

Why it fails: 'ROOT:HKLM' is not valid registry path syntax for the posture check, so the key cannot be located. It is tempting because prefixing a hive with a scope-like token resembles other configuration path conventions, and would be correct if the platform defined ROOT as a recognised hive alias for HKLM.

The path must be relative to the user profile, so HKLM is invalid.

Why it fails: HKLM is a machine-wide hive, not tied to a user profile, so treating it as invalid is factually wrong and blocks a valid check. It is tempting because many posture settings are per-user and resolved relative to the profile, and would be correct if the key genuinely lived under HKCU rather than the local machine.

Use a backslash prefix like '\\HKLM'.

Why it fails: A leading backslash prefix like '\\HKLM' denotes a UNC network path, not a registry hive, so the check cannot resolve the key. It is tempting because backslashes are the standard separator inside registry paths, and would be correct if the requirement were to reference a remote share rather than a local hive.

Use the full string 'HKEY_LOCAL_MACHINE' at the start of the path.

Why it fails: Spelling out 'HKEY_LOCAL_MACHINE' is not the accepted hive token in the registry check path syntax, so the check fails to resolve. It is tempting because the full hive name is valid in many Windows APIs and .reg files, and would be correct in a context that expects complete registry hive names rather than the abbreviated form.

MAC Authentication Bypass

Why it fails: MAB is an authentication method, not a remediation action.

VLAN Change

Why it fails: VLAN change is an authorization result, not a remediation action used for posture fixing.

Downloadable ACL

Why it fails: DACLs are for access control, not for fixing endpoint compliance states.

The switch must be configured for WebAuth.

Why it fails: WebAuth is for guest portals; posture uses a different mechanism involving ACLs and redirection to the agent.

The endpoint must be joined to an Active Directory domain.

Why it fails: While often used for identity, it is not a technical requirement for posture assessment functionality.

The Windows Defender definitions are not included in the posture condition.

Why it fails: If the definitions were not included in the condition, the endpoint would likely be compliant because that check would not be evaluated. The issue is that the check is evaluated and fails, but no redirection occurs due to policy mode.

The remediation action is not configured to 'Auto Remediate'.

Why it fails: Auto Remediate would automatically fix the issue without user intervention, but its absence does not prevent redirection to a remediation portal. The redirection is controlled by the posture policy's enforcement mode, not by the remediation action type.

The AnyConnect posture agent is not configured to allow redirection.

Why it fails: The AnyConnect posture agent does not have a setting to allow or deny redirection; redirection is orchestrated by ISE based on the posture policy and authorization results. The agent simply reports posture status and can display remediation instructions.

Remediation policy

Why it fails: Remediation actions are part of posture policy configuration, not a separate policy type. The remediation is defined within the posture policy or as part of the posture requirement. There is no standalone remediation policy in ISE.

Profiling policy

Why it fails: Profiling policies are used to identify and classify endpoints, which can be helpful for assigning posture policies, but they are not strictly required for posture assessment. The posture configuration focuses on compliance checks and agent provisioning.

Authorization policy

Why it fails: While an authorization policy is needed to enforce network access based on posture status, it is not part of the posture configuration itself. The question asks for components required to complete the posture configuration, which are specifically posture policy and client provisioning policy.

The remediation action is not supported on Windows endpoints; it is only available for macOS and Linux.

Why it fails: WSUS remediation is specifically designed for Windows endpoints. It is not available for macOS or Linux. The engineer correctly chose a Windows-compatible remediation action. The failure is likely due to missing domain or WSUS client configuration, not platform support.

The posture policy is set to 'Audit' mode, which prevents remediation actions from executing.

Why it fails: Audit mode does not prevent remediation actions from executing; it only changes the enforcement to monitor-only, meaning remediation is not applied. In audit mode, the endpoint would be marked Non-Compliant but no remediation would occur. The scenario implies remediation is expected, so audit mode is not the cause unless explicitly set, which is not stated.

The remediation action requires the AnyConnect posture module to be installed and running, but it is not.

Why it fails: If the AnyConnect posture module were missing, the endpoint would not be assessed, and remediation would not be triggered. However, the scenario states that the endpoint fails a posture check, implying posture assessment is working. The issue is more likely with the remediation action configuration itself.

The service is set to start manually and is not currently running, so the posture check correctly reports it as not found.

Why it fails: The scenario states the service is actually running, so this option contradicts the given information. If the service were not running, the posture check would correctly fail, but that is not the case here. The administrator must focus on why the running service is not being detected.

The AnyConnect Posture module does not have sufficient permissions to query the service status.

Why it fails: The AnyConnect Posture module typically runs with sufficient privileges to query service status on Windows. If permissions were an issue, the module would likely fail to report any service information or would log an access denied error. The scenario indicates the check returned 'Not Found', suggesting the query executed but did not find the service as specified.

The posture condition is configured to check for a process instead of a service, causing a mismatch.

Why it fails: If the condition were mistakenly configured to check for a process, it would look for an executable name rather than a service name. The scenario specifies a service check, so this is unlikely unless the administrator misconfigured it. However, the DART output indicates a service check was performed, so the condition type is likely correct.