CompTIA CloudNetX (CNX-001) Practice Tests

Explanation

Application Load Balancer is the correct choice because it operates at Layer 7 and provides the complete set of required capabilities: path-based routing rules that direct /products/*, /cart/*, and /checkout/* to different target groups behind a single DNS endpoint; native AWS WAF association for OWASP Top 10 protection including SQL injection and cross-site scripting; and WebSocket support for persistent real-time connections. ALB inspects HTTP content and routes based on URI path, host headers, query strings, and custom headers — features that require Layer 7 awareness. Network Load Balancer operates at Layer 4 and while it does support TLS termination, it lacks the content-inspection capabilities needed for path-based routing and does not integrate with AWS WAF since it cannot parse HTTP request content. Gateway Load Balancer is designed for transparent inline deployment of third-party network appliances using GENEVE encapsulation — it is not intended for application traffic distribution. Classic Load Balancer is a legacy service superseded by ALB and NLB; it lacks path-based routing and has lower performance limits.

Explanation

Istio's mutual TLS behavior is controlled by PeerAuthentication policies. By default, Istio operates in PERMISSIVE mode, which means that sidecar proxies accept both plaintext and mTLS traffic. This default allows gradual adoption but results in the behavior described: pods with Istio sidecars injected will use mTLS when communicating with other sidecar-equipped pods, but plaintext connections from pods without sidecars or from external sources are still accepted. Applying a PeerAuthentication policy with mtls.mode set to STRICT configures all sidecar proxies in the policy scope to reject plaintext connections and require valid mutual TLS authentication for all traffic. This is the configuration step required to enforce universal encryption without modifying application code, as the Istio sidecar proxy handles the TLS handshake transparently at the infrastructure layer. Kubernetes NetworkPolicy resources control which pods can communicate at the network level based on selectors and ports, but they do not implement or enforce TLS encryption. NetworkPolicy allows or denies connections but cannot inspect or enforce the encryption state of allowed connections. The Istio ingress gateway configuration controls how external traffic enters the cluster and is separate from inter-service mTLS within the mesh. A missing ingress TLS certificate would affect inbound external traffic, not internal pod-to-pod communication. Application containers do not need TLS library modifications because the entire value proposition of a service mesh is transparent encryption at the infrastructure layer without application changes.

Explanation

ZTNA fundamentally changes the access model in two key ways that address the primary weaknesses of traditional VPN. Traditional SSL VPN grants network-level access — once authenticated, users receive an IP address on the corporate network and can attempt to reach any resource within the accessible network segment. ZTNA replaces this with per-application access control through a Policy Enforcement Point: users are granted access only to the specific applications they are authorized for, and each application access decision is evaluated independently. A user authorized for the HR portal cannot reach financial systems because those require a separate authorization decision — the user's network location does not grant implicit access to adjacent systems. ZTNA also implements continuous verification throughout a session. Traditional VPNs authenticate at connection establishment and then trust the session indefinitely, meaning a compromised device or stolen session token provides persistent access. ZTNA's Policy Engine continuously evaluates trust signals including user identity assertions, device health and compliance posture, location, and behavioral patterns, and can revoke access mid-session if trust conditions change. Zero Trust does not eliminate network-layer controls — microsegmentation, security groups, and firewalls remain part of a defense-in-depth strategy; Zero Trust supplements rather than replaces them. ZTNA solutions often use clientless browser-based access or lightweight agents, not traditional thick VPN clients. ZTNA reduces lateral movement risk by restricting reachable network surfaces, not increases it.

Explanation

A GitOps workflow implemented with IaC in a Git repository satisfies all three compliance requirements with minimal ongoing manual effort. Traceability is inherent in Git — every change is a commit with author, timestamp, message, and linked to a pull request that references the change request. Peer review is enforced by requiring pull request approvals before merge, providing a documented second-person review. Automated testing is handled by CI/CD pipelines that trigger on pull requests, running terraform plan, security policy checks, and integration tests against non-production environments automatically without human intervention. Once established, this workflow reduces manual effort because the process is enforced by tooling rather than procedural compliance. Manual ticketing before console access relies entirely on human discipline and does not prevent undocumented console changes — a determined engineer can still bypass the process. CMDB updates after changes are reactive documentation, not preventive controls — they record what happened but do not enforce review or testing before changes occur. Weekly change review boards introduce significant latency (changes must wait up to a week) and meetings are manual overhead with no automated enforcement of the approved plan.

Explanation

CIS Benchmark Level 1 provides basic security hardening with minimal performance or functionality impact, recommended for all systems. CIS Level 2 includes defense-in-depth measures that may reduce functionality or performance, recommended for high-security environments. The optimal approach is to apply Level 1 as the universal baseline, then selectively implement Level 2 controls where they align with security requirements without compromising the 99.95% availability target. PCI-DSS does not explicitly require CIS Level 2, but does require compensating controls which can be met through risk-based implementation. Applying only Level 1 may miss important security controls, while blanket Level 2 may impact application availability.