CompTIA SecurityX — Practice Questions and Mock Exam

In the AWS Shared Responsibility Model, AWS manages security "of" the cloud (physical infrastructure, hypervisor, global network), while customers manage security "in" the cloud (AWS Shared Responsibility Model, aws.amazon.com/compliance/shared-responsibility-model). Security groups (stateful, instance-level) and NACLs (stateless, subnet-level) are always customer-configured network controls regardless of service model. Why not the others? Physical data center security is AWS's core obligation. Global network infrastructure is AWS-managed. Hypervisor patching is AWS's responsibility per the IaaS boundary. The boundary shifts by service model: EC2 (IaaS) gives more customer responsibility; Lambda (serverless) gives less. Per the AWS Well-Architected Security Pillar, any configuration decision about customer workloads belongs to the customer. Ref: AWS Shared Responsibility Model; AWS Well-Architected Security Pillar; NIST SP 800-145.

Classify by the delivery mechanism, not by the story wrapped around it. An adversary sending messages in order to gain access to victim systems is phishing, and the class explicitly covers malicious attachments and links as well as posing as a trusted source. Impersonating a supplier is a targeting refinement that makes the message more convincing, but it does not change what the technique is.

The distractors belong to later stages or to different objectives. Abusing existing credentials describes an adversary who already holds valid account access, which is how an intrusion continues rather than how this one arrives. Blending command traffic into ordinary application-layer protocols is a command-and-control behavior that only matters once a foothold exists. Running code inside another process is an execution and evasion technique on a host that has already been compromised.

Exam tip: getting the classification right matters because the countermeasures differ. Delivery is countered with message authentication, attachment detonation and a reporting path for users, while credential abuse and code execution need entirely different controls, so mislabeling the technique sends you to the wrong defense.

Shadow IT is the use of technology systems, devices, software, or cloud services without explicit organizational approval, creating unmanaged risk and governance blind spots. Here, the IT department used unapproved cloud storage — the textbook definition. Why not the others? Residual risk is risk remaining after controls are applied, presupposing controls exist. Inherent risk is baseline risk before any controls, not about unauthorized usage. Transferred risk involves shifting risk to a third party via insurance or outsourcing. Shadow IT undermines asset inventory, compliance, incident response, and data protection because security teams cannot secure what they don't know exists. It creates gaps in risk assessments, policy enforcement, and regulatory compliance. Ref: NIST CSRC Glossary (shadow_it); NIST SP 800-53 Rev 5 CM-8 (System Component Inventory); NIST CSF Identify function.

Certificate pinning binds a specific certificate or public key to an application's expected server, supplementing standard TLS chain validation. Standard TLS trusts any CA in the device store; a compromised or rogue CA can issue fraudulent certificates enabling MITM interception. Pinning defeats this by verifying the server's certificate matches a pre-embedded hash. Approaches: leaf pinning (strict), intermediate CA pinning (flexible), or public key pinning (survives cert renewal). Why not the others? DoS attacks target availability, not authentication. XSS exploits browser DOM, unrelated to transport security. SQL injection targets query parsing, not TLS. Risks of pinning include operational complexity during cert rotation; backup pins are essential to prevent lockout. Ref: OWASP Mobile Security Testing Guide (MSTG); OWASP Mobile Top 10 M3; RFC 7469 (HTTP Public Key Pinning).