CCNA Network Security Questions

The protocol specifies the scheme, such as HTTPS, that governs how a client requests the resource, and it always precedes the host in a URL's syntax. This satisfies the stem's requirement for a URL component, since the scheme is a mandatory structural element rather than optional metadata.

The /sw-reporting/v1/flows endpoint belongs to the Reporting API, which exposes flow records collected by Secure Network Analytics. It satisfies the stem's requirement to query flow data specifically, unlike the configuration or management endpoints. Authentication uses a bearer token issued by Microsoft Entra ID, so automation scripts can retrieve flows programmatically.

After posting credentials, the FMC returns a token in the response header; the script must extract X-Auth-Access-Token and reuse it in subsequent request headers. This token-based mechanism replaces repeated credential exchange for each API call.

ERS batch endpoints accept multiple objects in a single HTTP request, so thousands of SGT updates are grouped rather than sent individually. This directly minimises API call volume and load on Cisco ISE compared with per-object requests.

API-driven policy automation removes manual CLI configuration drift, so every device receives identical access control lists and firewall rules. This directly satisfies the stem's consistency requirement, since human error during repetitive configuration is the main cause of divergent security postures across a fleet.

Ansible Vault encrypts sensitive data such as passwords and keys. You can store ASA credentials in an encrypted file and reference them in playbooks. This prevents hardcoding credentials in plaintext. Vault uses AES-256 encryption and requires a password to decrypt. This is the recommended method for securing secrets in Ansible.

HTTP 429 signals rate limiting, so the script must retry after a delay. Exponential backoff progressively increases the wait between attempts, reducing request volume until the FMC accepts calls again, avoiding further throttling or failed retrievals.

JSON is the native payload format for the Cisco ASA REST API, which accepts and returns JSON-encoded objects for access control entry operations. The API rejects XML and form-encoded bodies, so JSON satisfies the stem's requirement for the request body when pushing a new ACE.

The pxGrid API enables bidirectional, context-sharing integration with Cisco ISE, publishing session, identity and endpoint data to subscribers and allowing external systems to query or act on that context. This satisfies the stem's requirement for a programmatic interaction method, unlike GUI-only or non-API interfaces.

Firepower Management Center's REST API exposes bulk operations, letting you create, modify or delete many objects in a single request. This satisfies the efficiency constraint by avoiding thousands of individual calls when modifying large object sets.

FMC stores object changes in its configuration database; the FTD devices only receive them when a deployment job is triggered. POSTing to /deploy with the target device list pushes the pending configuration, satisfying the requirement that changes actually take effect on managed devices.

Bearer tokens carry the access credential itself, so the API validates the token's signature, issuer and expiry to authenticate the caller. This satisfies the stem's requirement for authenticating the request without requiring a separate session or cookie exchange.

cisco.fmcansible.fmc_configuration is the Ansible module built to create, update and delete FMC objects, abstracting the underlying REST calls. It directly satisfies the playbook's need to manage Firepower policies through FMC rather than generic HTTP modules.

HTTP 401 Unauthorised signals failed authentication, so the supplied credentials are incorrect or malformed. The ERS API rejects the request before authorisation checks, making invalid credentials the most likely cause rather than permissions or payload issues.

Automation scripts frequently fail because hard-coded URLs point at retired or incorrect endpoints, or because the API version in the path no longer matches the deployed platform. This mismatch between script and live API surface is a genuine, commonly encountered automation issue, satisfying the scenario's requirement.

Automated security scripts run unattended, so robust error handling and logging let failures be caught, diagnosed and retried without manual intervention. This satisfies the design requirement that scripts remain reliable and auditable when executing security tasks at scale.

GET is the HTTP method defined for safe, idempotent retrieval of a resource representation without modifying server state. Requesting interface status from the ASA REST API is a read operation, so GET satisfies the requirement to fetch current state without altering configuration.

GET retrieves a representation of the specified policy resource without altering server state, satisfying the read-only constraint. The other HTTP methods (POST, PUT, DELETE) modify or create resources, so they cannot fulfil a read-only request.

A successful bulk user creation via the ERS API returns 201 Created, confirming each resource was instantiated. This satisfies the stem's requirement for the expected success code on a creation request, distinguishing it from 200 OK, which signals retrieval rather than resource creation.

Query parameters appended to the URI narrow results server-side, for example limiting returned records by field value, count or time range. They satisfy the stem's requirement to filter data volume, unlike headers or the body, which carry authentication and payload content rather than selection criteria.

The ASA REST API exposes monitoring endpoints that return interface statistics such as packet and byte counters, enabling automated health checks. Reading these counters requires no configuration change, satisfying the monitoring action the question asks about.

HTTPS wraps HTTP in TLS, providing the encrypted transport that Cisco security APIs require for authentication tokens and configuration data in transit. Plain HTTP would expose credentials, so HTTPS is the portfolio's primary API transport protocol.

POST creates a new subordinate resource on the server, submitting a representation in the request body. It is one of the standard REST methods, alongside GET, PUT, PATCH and DELETE, and is commonly used when provisioning objects through Cisco security APIs.

Without an Accept header, the Cisco ISE ERS API cannot negotiate content type, so it falls back to a default representation rather than the format you intended. Specifying it guarantees the expected JSON or XML response.

The ETag identifies a specific resource version; clients resend it via If-Match so the server rejects updates based on stale data. This optimistic concurrency control satisfies the stem's question about the header's role in Firepower API responses.

The requests library provides a simple, widely adopted interface for issuing HTTP calls, handling headers, authentication, sessions and JSON parsing. This satisfies the requirement for an industry-standard Python tool when sending REST requests to Cisco security APIs.

Pre-configured API sandboxes let learners send live calls against Cisco platforms without building or hosting their own lab, satisfying the stem's requirement for a DevNet feature. They provide immediate, guided practise with real endpoints, authentication and sample payloads, which is central to DevNet's hands-on learning model.

The FMC REST API nests policy resources under the config version and domain UUID, so access control policies are addressed at /policy/accesspolicies within /api/fmc_config/v1/domain/{uuid}. This endpoint satisfies the stem's requirement to list Access Control Policies via the FMC API.

The API secret is the confidential half of the Umbrella key pair, supplied alongside the API key to authenticate requests. Without it, the management API rejects the client, so it is required to initiate a connection.

API rate limits cap how many requests a client may send within a defined time window, such as per minute or per second. Exceeding the threshold typically returns HTTP 429. This constrains automation scripts against Cisco security products, which enforce such quotas.

Authentication is performed via token generation endpoints.

Storing API credentials in environment variables or a vault keeps them out of source code and configuration files, satisfying the stem's demand for secure automation. Vaults add rotation, auditing and least-privilege retrieval, so compromised scripts cannot leak long-lived secrets.

The Cisco Umbrella Reporting API caps each GET request at 100 records by default. Larger result sets must be paginated using the limit and offset parameters, so this default governs how many records a single call returns.

The ASA REST API allows configuration changes, but they are not automatically saved to the startup configuration. You must explicitly save the configuration, often via a separate API call or command, to persist changes across reboots. Failing to save results in loss of changes after a reload.

Infrastructure as Code defines devices, policies and topologies in version-controlled declarative files, then applies them through automation tooling. This satisfies the stem's requirement to treat configurations as code, enabling peer review, repeatable deployment and rollback instead of manual CLI changes.

The Authorization header carries credentials used to authenticate the request, typically a bearer token, API key or Basic base64-encoded username and password. This lets the API verify the caller's identity and permissions, satisfying the scenario's requirement to identify what authentication material the header transports.

The Application Name labels the registered API client so SecureX logs and audit trails attribute each API call to a known application. This satisfies the stem by enabling accountability and traceability of requests originating from that client.

The Firepower API exposes policy management operations, allowing scripts to create, read, update and deploy access control, intrusion and related policies programmatically. This complements its object management and device inventory capabilities rather than being limited to read-only monitoring.

Cisco Umbrella delivers DNS-layer security, blocking malicious domains before connections establish, and extends protection to cloud applications and remote users. This satisfies the stem's requirement for visibility and control over cloud-based threats, since enforcement occurs at the DNS and secure web gateway layers regardless of user location or device.

In Cisco FMC, an access control policy must be associated with one or more managed devices before it can be deployed. The error explicitly indicates no device association. The engineer must update the policy's device assignments via the API or GUI. This is a common step often overlooked when automating policy creation.

The requests library offers a simple, human-readable API for HTTP verbs, automatic JSON decoding, session handling and persistent connections, which suits Cisco Security APIs' REST and token-based authentication models better than lower-level alternatives such as urllib.

The json module ships with Python's standard library and provides json.loads() to deserialise FMC's nested JSON responses into dictionaries and lists. No third-party installation is needed, and it handles arbitrary nesting depth, making it the standard choice for this parsing task.

OAuth 2.0 issues scoped, time-limited access tokens, letting Cisco SecureX call APIs without exposing user credentials. This satisfies the stem's requirement for the most commonly used API authentication method, as token-based delegation is the standard mechanism for secure, automated integrations across cloud services.

Cisco TID ingests threat intelligence feeds and publishes the resulting IoCs directly to integrated security devices, automating distribution across the stack. This satisfies the stem's requirement to automate IoC sharing rather than relying on manual feed configuration.

Stealthwatch's API authenticates via username and password credentials, or an API key, to obtain a token for subsequent calls. This satisfies the stem's question about the authentication type used, distinguishing it from certificate-based or OAuth-only schemes.

A 409 Conflict signals a duplicate-resource violation, so the guest account already exists in Cisco ISE. The ERS API rejects the create request because the username or guest record collides with an existing entry, satisfying the stem's constraint that provisioning failed due to a pre-existing account rather than authentication or syntax errors.

Cisco SecureX Orchestration provides workflow-based integration across multiple Cisco security APIs, centralising authentication, actions and data flows in one platform. This satisfies the requirement to manage disparate security APIs from a single orchestration layer rather than separate per-product tooling.

SecureX Threat Response represents indicators such as IPs, domains, file hashes and URLs as Observables, the atomic searchable units submitted to the inspect endpoint. Using Observable as the parameter satisfies the threat-hunting scenario by letting the API return verdicts and sightings for that indicator.

ERS exposes ISE's configuration objects through full CRUD semantics, letting automation create, read, update and delete endpoints, identity groups and network devices. This satisfies the stem's requirement for a management API capable of programmatic object lifecycle operations rather than read-only monitoring.

Updating an existing guest user is an idempotent modification of a known resource, so ERS expects PUT against the collection path plus the resource ID. The body carries the changed attributes, and the ID in the URI identifies which guestuser record to modify.

The FMC REST API uses PUT to replace or update an existing access control policy resource. The endpoint includes the domain UUID and the policy's objectId to identify the exact policy. The request body must contain the full policy representation with the modified default action. This is the correct method for updating an existing policy.

The ERS API supports retrieving a specific endpoint group by its ID using a GET request to /ers/config/endpointgroup/{id}. This returns the group's details, including its unique identifier. After creating a group, the response typically includes a Location header with the URL, but a GET to that URL confirms the resource and provides the ID. This is the standard REST pattern for reading a resource.

A sandbox provides an isolated environment where developers can safely call APIs, test code and experiment without affecting production systems or live data. This directly satisfies the stem's requirement for a safe development and testing space, which is the sandbox's primary function in Cisco DevNet.

Swagger/OpenAPI specifications are a documented API documentation type, publishing machine-readable endpoint schemas, parameters and response models. This satisfies the stem's requirement for a genuine Cisco Security API documentation category, since these specifications are formally maintained and distributed for Cisco security APIs.

Least Privilege limits each API consumer and service account to only the permissions its function requires, shrinking the blast radius if credentials leak. This directly satisfies the stem's demand for a core secure network design principle governing API authorisation scope.

Meta or pagination information accompanies the payload, carrying counts, page numbers and next/previous links so clients can iterate large result sets. Its presence satisfies the question's requirement for a field commonly found in JSON API response objects.

PUT replaces the entire resource representation, sending the complete object body so unspecified fields are overwritten. POST would create or invoke actions, and PATCH applies partial merges, so PUT is required for a full update of the existing FMC object.

The networkaddresses endpoint requires both name and value; type alone is insufficient. Omitting the mandatory value attribute causes FMC's schema validation to reject the payload with 400 Bad Request, so supplying the IP address or subnet in value resolves the error.

A service account exists independently of any employee, so scripts continue authenticating even when staff leave, change roles or have credentials rotated. This decoupling satisfies the requirement that automation remain stable and auditable rather than tied to individual employee identity.

A dedicated lab or sandbox provides an isolated Cisco environment where API calls can be exercised without affecting production devices. This satisfies the requirement to validate request formats, authentication and responses safely before any deployment to live infrastructure.

In Cisco Umbrella, you manage block lists via the /policies/{policyId}/blocklist endpoint. Adding a domain to the block list is done with a POST request. This action applies the block for that policy. The JSON body includes the domain. This is the correct method to enforce a block action.

The Cisco Threat Response API exposes the `/iroh/iroh-enrich/verdicts` endpoint, returning verdicts for a given observable such as an IP address. It satisfies the stem's requirement to retrieve verdicts programmatically, unlike the Cisco Security Management or Umbrella Enforcement APIs, which handle policy and blocklist actions rather than enrichment verdicts.

A GET to the accesspolicies resource under the specified domain UUID retrieves the collection of access control policies defined in that domain. It returns policy metadata and links, satisfying the scenario's need to enumerate existing policies rather than fetch a single policy or its rules.

Cisco ISE ERS API requires the API caller to have the appropriate admin role, such as ERS-Admin or ERS-Read-Only, assigned via the admin group. A 401 Unauthorized indicates authentication failure, often due to missing role or disabled account. Verifying and correcting the API user's role and status directly addresses the issue.

The X-Auth-Access-Token header carries the access token issued by Microsoft Entra ID, enabling the FMC API to authenticate each request without resending credentials. This satisfies the stem's authentication requirement by supplying the bearer credential the API validates before processing the call.

Regular rotation limits the window in which a leaked or stolen API key remains usable, containing exposure if credentials are compromised. This reduces the blast radius of credential theft and is a foundational practice for managing long-lived API keys securely.

Deploying to a sandbox or staging environment validates the ASA rule syntax and behaviour before production, catching errors that would otherwise disrupt live traffic. This satisfies the stem's requirement to confirm changes are correct prior to applying them.

Cisco Identity Services Engine publishes contextual identity and posture data over pxGrid, letting other platforms consume that information for policy decisions. This matches the stem's requirement for the product using pxGrid to share context with network devices.

The ISE ERS API returns HTTP 201 Created when a new resource is successfully created via POST. This status indicates that the request has been fulfilled and resulted in a new resource being created. The response typically includes a Location header with the URI of the new resource.

This endpoint returns a list of all network devices in Cisco ISE. It supports filtering, sorting, and pagination. The response includes device details such as name, IP address, and device type. This is the correct endpoint for retrieving network devices programmatically.

Python dominates Cisco security automation because Cisco exposes SDKs such as requests-based RESTCONF and YANG tooling, plus libraries for SecureX and Firepower. It satisfies the stem as the language with the broadest first-party Cisco automation support.

Sending a POST to /api/fmc_platform/v1/auth/generatetoken returns the authentication token required for subsequent FMC REST API calls, satisfying the stem's authentication requirement. The token is supplied via the X-auth-access-token header, and the call uses HTTP Basic credentials.

Notifications flow only through an established pxGrid connection, so the controller's status and the client's connection state must be verified first. If the controller is down or the session is not subscribed, no notifications will ever arrive.

Firepower objects use REST semantics: GET returns the object's current representation, including its version identifier, then PUT submits the modified body. Supplying the retrieved state prevents overwriting concurrent changes and satisfies the API's version-check requirement.

The ETag header carries a resource version identifier; clients return it via If-Match so the ASA rejects updates when the resource changed since retrieval, preventing lost updates. This satisfies the stem's concurrency control requirement by enforcing optimistic locking on conflicting simultaneous modifications.