Security Architecture practice questions

Reverse proxy mode

Why it fails: Reverse proxy sits in front of cloud apps but may require changes to DNS or routing.

Inline mode

Why it fails: Inline mode requires traffic to pass through the CASB, often needing proxy configuration.

Forward proxy mode

Why it fails: Forward proxy requires explicit configuration on end-user devices.

Secrets management

Why it fails: Secrets management handles sensitive data, not pod authorization.

Network policies

Why it fails: Network policies control traffic flow, not pod authorization.

RBAC

Why it fails: RBAC controls user and service account permissions, not container execution.

Network policies

Why it fails: Network policies control traffic, not image provenance.

Container runtime security (e.g., seccomp)

Why it fails: Seccomp restricts system calls, not image signing.

Admission controllers

Why it fails: Admission controllers validate pod specifications against policies, but they do not themselves verify image signatures; that requires a verifier such as Sigstore or Notary integrated with the controller. They are tempting because admission control is the correct enforcement point for policy decisions at deploy time.

Single sign-on (SSO) without MFA

Why it fails: SSO alone is not a defense layer; MFA is needed.

Physical security of the data center

Why it fails: While important, physical security is typically not considered an application defense layer.

Inline proxy

Why it fails: Inline proxies require traffic interception and may not decrypt without client certificates.

Forward proxy

Why it fails: Requires client configuration and traffic redirection.

Reverse proxy

Why it fails: Requires DNS changes and traffic routing.

Client VPN

Why it fails: A client VPN tunnels a single remote device to a private network, giving neither dedicated high bandwidth nor a private path to the cloud provider. It is tempting for remote access, but dedicated interconnection is required to bypass the public internet.

Site-to-site VPN

Why it fails: A site-to-site VPN still traverses the public internet, so it cannot guarantee low latency, high bandwidth or avoidance of public routing. It is tempting because it links sites privately via encryption, but encryption does not remove internet transit.

SD-WAN

Why it fails: SD-WAN steers traffic across multiple WAN links, including broadband internet, so it does not provide a private dedicated path to the cloud provider. It is tempting for optimising branch connectivity, but dedicated interconnection is needed here.

ZTNA

Why it fails: ZTNA provides access control, not full traffic inspection.

CASB

Why it fails: CASB focuses on cloud service security, not all traffic.

SD-WAN

Why it fails: SD-WAN is a networking component, not a security inspection component.

Reverse proxy

Why it fails: A reverse proxy sits in front of the cloud app, so it only sees traffic routed through that app's infrastructure and cannot inspect unsanctioned SaaS use from unmanaged devices. It is the right choice when protecting a self-hosted service and hiding origin servers.

Forward proxy

Why it fails: A forward proxy requires device or browser configuration, such as a PAC file or agent, to direct user traffic through it, contradicting the no-device-modification requirement. It is correct when managed endpoints can be configured to route outbound web requests.

Inline gateway

Why it fails: An inline gateway is a network-integrated deployment requiring traffic to traverse it, typically via network changes or agents on the device, which the scenario excludes. It is correct when the organisation controls the network path and can steer traffic through the gateway.

PodSecurityPolicy

Why it fails: PodSecurityPolicy is a Kubernetes resource for controlling pod security settings, but it is not a Linux security feature and does not directly drop capabilities at the kernel level.

Seccomp

Why it fails: Seccomp is a Linux feature that restricts system calls, not capabilities. It can indirectly limit capability-related syscalls, but it is not the primary mechanism for dropping capabilities.

SELinux

Why it fails: SELinux enforces mandatory access controls through security contexts and policies on files, processes, and sockets, but it does not provide a mechanism to drop kernel capabilities from a container’s process. The scenario requires reducing the set of permitted Linux capabilities (e.g., `CAP_NET_RAW`), which is achieved by configuring `securityContext.capabilities.drop` in the Kubernetes pod spec, not by SELinux policy. It is tempting because SELinux is a prominent Linux security module used to confine container workloads in production, and it would be the correct choice if the requirement were to restrict a container’s access to specific filesystem objects or network resources via type enforcement, rather than to drop capabilities.

Falcon

Why it fails: Falcon is a NIST-selected post-quantum signature scheme, but it was standardised as FN-DSA (FIPS 206), still in draft, rather than the finalised FIPS 204 ML-DSA. Falcon suits constrained environments needing small signatures; the stem asks for the standardised algorithm, which is ML-DSA.

RSA-4096

Why it fails: RSA-4096 relies on integer factorisation, which Shor's algorithm breaks on a sufficiently large quantum computer, so it offers no quantum resistance. It is tempting because larger keys extend classical security, and RSA-4096 would be correct for resisting conventional attacks under current standards.

CRYSTALS-Kyber

Why it fails: CRYSTALS-Kyber is standardised for key encapsulation, not digital signatures, so it cannot sign certificates in a PKI. It is tempting because it is a genuine NIST post-quantum standard, and Kyber would be correct for establishing shared symmetric keys between parties.

Using RBAC to restrict service account permissions

Why it fails: RBAC governs which Kubernetes API operations an identity may perform; it does not constrain a process already running inside a container, so a compromised workload retains its filesystem, network and syscall reach. RBAC is the right control for limiting who can create pods, read secrets or exec into workloads.

Performing regular container image scanning for vulnerabilities

Why it fails: Image scanning detects known CVEs in layers before deployment; it cannot contain a container already exploited at runtime, so lateral movement and host access remain unrestricted. Scanning is the correct choice when the requirement is gating vulnerable images in a CI/CD pipeline or registry admission stage.

Hybrid cloud

Why it fails: FedRAMP authorises cloud service offerings, not deployment models; a hybrid split adds on-premises components outside any FedRAMP authorisation boundary, so the sensitive workloads cannot inherit a FedRAMP package. Hybrid suits gradual migration while retaining legacy systems that cannot move.

Private cloud

Why it fails: FedRAMP authorisation applies to a cloud service offering assessed against NIST SP 800-53, not to a deployment model; a private cloud built in-house carries no FedRAMP package, so the company must still pursue its own authorisation. Private cloud suits organisations needing dedicated hardware for regulatory or latency reasons.

Public cloud

Why it fails: FedRAMP authorisation attaches to a specific cloud service offering, not to the public deployment model itself; choosing public cloud without selecting a FedRAMP-authorised offering leaves the compliance requirement unmet. Public cloud suits workloads needing elastic scale where an authorised offering is available.

Seccomp profiles

Why it fails: Seccomp profiles restrict the syscalls a container may make; they do not address the other hardening areas the question requires, such as network policy or admission control. It is tempting because syscall filtering genuinely reduces kernel attack surface, and would be correct for limiting container privilege escalation.

Service mesh

Why it fails: A service mesh manages service-to-service traffic, mTLS and observability; it does not harden the cluster's own control plane or node configuration. It is tempting because meshes do enforce encrypted east-west traffic, and would be correct for securing communication between microservices.

Network segmentation

Why it fails: Segmentation is part of zero trust but not identity-centric specifically.

Virtual private network (VPN)

Why it fails: VPN is not a required component for zero trust.

SD-WAN

Why it fails: SD-WAN steers and optimises traffic across WAN links by application policy; it does not perform identity-based policy enforcement or deep traffic inspection. It is the correct SASE component when the requirement is resilient, policy-driven branch connectivity over mixed transports, not securing remote user access.

Cloud Access Security Broker

Why it fails: A CASB governs sanctioned cloud service usage, discovering shadow IT and applying data and threat policies to SaaS traffic; it does not enforce identity-based access for all remote user traffic. It is correct when the requirement centres on cloud application visibility and control, not general remote-access enforcement.

Next-Generation Firewall

Why it fails: A next-generation firewall inspects packets and applies network-layer rules, but identity-based policy enforcement for remote users across cloud and on-premises destinations requires a cloud-delivered secure web gateway with identity integration. NGFWs are correct for perimeter and data-centre segmentation, not SASE remote-user policy enforcement.

OAuth 2.0 authorization code

Why it fails: OAuth 2.0 authorisation code grants delegated access via bearer tokens; it conveys authorisation, not payload integrity, so a modified body still passes. It is tempting because it authenticates the calling client, and it would be correct when the requirement is scoped third-party access to a user's resources rather than tamper detection.

API key in query parameter

Why it fails: An API key identifies the calling project but travels in cleartext and signs nothing, so any altered request body or parameter is accepted unchanged. It is tempting as lightweight caller identification, and it would be correct for simple server-to-server authentication where message integrity is not required.

Rate limiting

Why it fails: Rate limiting caps request volume per client to blunt abuse and denial-of-service, but it inspects no payload, so tampered content passes through untouched. It is tempting because it hardens public endpoints, and it would be correct when the requirement is throttling or quota enforcement rather than verifying request integrity and origin.

Falcon

Why it fails: Falcon is a NIST-selected PQC signature algorithm, but it is not the primary standardised recommendation the question targets. It is tempting because Falcon is genuinely quantum-resistant, and it would be correct if the question asked for any lattice-based signature scheme rather than the NIST-recommended one.

CRYSTALS-Kyber

Why it fails: CRYSTALS-Kyber is a NIST standard for key encapsulation, not digital signatures, so it cannot sign. It is tempting because it shares the ML-KEM family name and is widely cited alongside Dilithium, and it would be correct if the question asked which algorithm establishes a shared quantum-resistant key.

RSA-4096

Why it fails: RSA-4096 relies on integer factorisation, which Shor's algorithm breaks on a sufficiently large quantum computer, so it offers no quantum resistance. It is tempting because larger key sizes feel stronger, and it would be correct if the question asked which classical algorithm remains secure against today's conventional attackers.

Elliptic Curve Diffie-Hellman (ECDH)

Why it fails: ECDH relies on the elliptic-curve discrete-logarithm problem, which Shor's algorithm solves on a sufficiently large quantum computer, so it cannot resist quantum attack. It is tempting because ECDH is a proven classical key-agreement method, and it would be the right choice for conventional TLS key exchange where quantum resistance is not required.

RSA-4096

Why it fails: RSA-4096's security rests on integer factorisation, which Shor's algorithm defeats on a quantum computer, so larger key sizes do not deliver quantum resistance. It is tempting because RSA-4096 is a widely deployed, strong classical asymmetric algorithm, and it would be correct where only classical attackers are in scope.

AWS VPN (site-to-site)

Why it fails: Site-to-site VPN tunnels traffic over the public internet, encrypted but still traversing it, which the stem forbids. It is tempting because it privately connects on-premises networks to a VPC cheaply, but AWS Direct Connect provides the dedicated private connection required here.

AWS Transit Gateway

Why it fails: Transit Gateway is a regional hub connecting VPCs, VPNs and Direct Connect attachments; it does not itself provide the private on-premises path. It is tempting because it centralises hybrid routing, but it still needs an underlying Direct Connect or VPN attachment to reach on-premises.

AWS PrivateLink

Why it fails: PrivateLink exposes specific services via interface endpoints inside a VPC, not broad on-premises access to VPC resources. It is tempting because it keeps traffic off the public internet, but it is service-to-service connectivity; Direct Connect is needed for private on-premises-to-VPC access.

Setting long certificate validity periods to reduce renewal frequency

Why it fails: Long validity periods widen the exposure window if a key is compromised and delay revocation propagation, weakening CA security. It is tempting because fewer renewals reduce operational effort, yet short-lived certificates with automated renewal are the practice that limits compromise impact.

Using certificate pinning to prevent man-in-the-middle attacks

Why it fails: Certificate pinning hardens clients against fraudulent certificates; it does nothing to protect the CA's own keys, issuance process or infrastructure. It is tempting because pinning is a recognised MITM defence, but the question asks about CA security practices such as offline root keys and HSM storage.

Using self-signed certificates for all internal services

Why it fails: Self-signed certificates bypass the CA entirely, so they neither protect the CA nor provide the trust chain and revocation the PKI requires. It is tempting because they are free and quick for internal services, but the scenario demands practices that safeguard the CA's keys and issuance.