CCIE Security common mistakes

Before answering any VPN scenario, extract the constraints explicitly: number of peers, whether identities must be hidden, whether PKI exists, whether NAT traversal or HA is required. Then justify the chosen IKE version, authentication method, and mode against each constraint in one sentence. Practice writing the trade-off table (IKEv1 main vs aggressive, PSK vs certificates, IKEv2 benefits) from memory.

For every firewall scenario, draw the zone diagram and annotate each zone pair with its policy-map, class-map match criteria, and default action. State explicitly which inspection (stateful, application-layer) applies and where return traffic is permitted. Rehearse reading a policy top-down and predicting the verdict for a specific 5-tuple before writing the answer.

Build a one-page map per major cloud of: identity controls (IAM policy, roles, service accounts), network controls (security groups vs NACLs vs firewall appliances), data controls (KMS, key policies), and logging (flow logs, audit trails). For each scenario, name which layer the risk lives in and which control owns it, and explicitly state what the provider is responsible for versus the customer.

For each cloud egress design, state the traffic path hop by hop, where symmetric return is guaranteed, how the appliance scales, and how failure degrades (fail-open vs fail-closed). Then explicitly choose TLS inspection, SNI-based filtering, or CASB API integration and justify against the scenario's compliance and performance constraints.

Write content policies as default-deny with explicit allow lists per user group and per destination category, and state the enforcement action (block, quarantine, allow with logging) for each. Name the bypass risks you are closing: file-type spoofing, archive recursion depth, encrypted archives, and direct-to-IP or alternate-port evasion. Verify by describing what happens to a renamed executable.

For each decryption scenario, list: which categories are decrypted, which are bypassed and why (pinning, legal, mTLS), how the internal CA is distributed and protected, and how failures are detected and logged. Practice explaining the handshake from the client's perspective when a proxy re-signs the connection.

Maintain a capability matrix: prevention (signatures, exploit mitigation, application allow-listing), detection (behavioral, EDR), response (isolation, kill process, rollback), and management (tamper protection, offline policy caching, health attestation). For any endpoint scenario, name the capability that addresses the specific attack stage rather than the product.

For every posture design, describe the full state machine: unknown, compliant, noncompliant, remediating, and the access each state has (including the remediation VLAN or portal). State the identity source, the posture checks, the enforcement device, and the re-assessment trigger. Mention phased rollout and monitoring-only mode as the deployment path.

For each IAM scenario, write the policy as subject, action, resource, and condition, then test it against a privileged user, a contractor, and a compromised-credential case. Include joiner/mover/leaver lifecycle, access recertification, and break-glass accounts with monitoring. State where authorization is enforced (PEP) and where the decision is made (PDP).

Build a decision table: protocol by client type and use case, with the token or assertion format, signing and encryption, audience and issuer validation, and session/logout behavior. For each scenario, name the identity provider, the relying party, the trust anchor, and the failure mode if the audience or signature check is misconfigured.