Security and Compliance practice questions

Security IN the cloud is everything the customer creates, configures, or grants access to: data, identities, guest operating systems, network configuration, and encryption choices.

Configuring network ACLs and routing is the customer's job because only the customer knows which traffic their workload should permit; AWS supplies the virtual networking, but the rules encode customer intent. The three distractors all live in layers the customer can never touch. The hypervisor is host virtualization software AWS operates, retiring and destroying physical disks is part of AWS's hardware and media-disposal process, and the network connecting Availability Zones is AWS's global infrastructure. A reliable test is whether the activity requires access to AWS hardware or host software: all three distractors do, so all three are security OF the cloud.

1. Recall that IN the cloud means the customer's data, access, and configuration layers.
2. Check each option for whether it requires access to AWS hardware, host software, or facilities.
3. Hypervisor patching, media destruction, and inter-AZ networking all require infrastructure access, so they are AWS's.
4. Network ACL and routing configuration expresses the customer's traffic decisions, so it is the customer's responsibility.

Exam tip: Network and firewall configuration for your resources is always your responsibility, even though AWS provides the networking features.

The shared responsibility model has three components: AWS responsibilities, customer responsibilities, and shared responsibilities, and the boundary between them shifts with the service's management level.

The two accurate statements capture the model's defining traits. First, the dividing line is not fixed: the more managed the service, the more AWS takes on, which is why OS patching belongs to the customer on EC2 but to AWS on RDS. Second, a small set of controls, patch management, configuration management, and awareness and training, are genuinely shared, with each party acting at its own layer. The distractors each violate an anchor of the model: customers never touch host operating systems on AWS's physical servers because that is host software AWS operates, the model governs every AWS service rather than only infrastructure services, and customer data never becomes AWS's responsibility regardless of the service's management level.

1. Recall the model's three components: AWS responsibilities, customer responsibilities, and shared responsibilities.
2. Confirm the boundary shifts by service: EC2 versus RDS versus Lambda place the line at different heights.
3. Confirm the three shared controls exist, with each party acting in its own layer.
4. Eliminate options that contradict the anchors: host OS and hypervisor are always AWS's, and customer data is always the customer's.

Exam tip: The responsibility line moves with the service, but shared controls and the two absolutes (data = customer, infrastructure = AWS) never change.

AWS is responsible for the full hardware lifecycle of its infrastructure, including procuring, maintaining, and securely decommissioning servers and storage media.

When a disk that held customer data is retired, AWS destroys it according to its media-disposal process, because the physical device is AWS property inside an AWS facility. The customer option fails on a physical impossibility: customers can never enter a data center or touch the hardware. The auditor option confuses verification with execution; third-party audits confirm AWS performs disposal correctly but do not carry it out. The shared option fails because sharing requires both parties to act in their own layer, and there is no customer layer in physically destroying a disk. Note the subtle point the question tests: even though the disk held customer data, the physical device is infrastructure, so disposal is AWS's, while protecting the data logically (encryption, access) remains the customer's.

1. Identify the layer: a physical storage device inside an AWS data center is hardware.
2. Apply the anchor: hardware and facilities are always AWS's responsibility.
3. Do not be misled by the mention of customer data; the physical device belongs to AWS even when the logical data belongs to the customer.
4. Reject shared responsibility because the customer performs no part of physical media destruction.

Exam tip: Hardware and media disposal is always AWS's job; customers never handle physical devices.

Customer data is one of the responsibilities that never moves: on every AWS service, the customer owns its classification, protection, encryption, and access control.

AWS operates the S3 service and secures the infrastructure it runs on, but it cannot know which documents are sensitive, which users deserve access, or whether encryption should be applied, so those decisions and their consequences belong to the customer. The AWS option fails because operating a storage service is different from owning the data in it. The public-versus-private split is a fabricated rule: bucket access settings are themselves customer configurations, so they cannot transfer responsibility to AWS. The shared option fails because the only shared controls are patch management, configuration management, and awareness and training; data protection is a purely customer-side, customer-specific concern.

1. Identify the subject of the question: the customer's data and access to it, not the storage infrastructure.
2. Apply the anchor: customer data is always the customer's responsibility, without exception.
3. Reject any option that makes data responsibility conditional on a configuration setting or service type.
4. Reject shared responsibility because data protection is not among the three shared controls.

Exam tip: Your data is always your responsibility; no AWS service, however managed, takes ownership of protecting its contents.

The hypervisor and host operating systems are part of the virtualization and host software layer that AWS always operates, on every service and every deployment option.

The hypervisor isolates one customer's instances from another's, which means it must be controlled by the infrastructure operator; customers never see or patch it. The EC2 distractor exploits the true fact that customers manage the most on EC2, but that management starts at the guest OS, one layer above the hypervisor. The shared-control distractor misapplies patch management: patching is shared across the whole model because each party patches its own layer, but any single layer has exactly one owner, and the hypervisor's owner is AWS. The dedicated-instance distractor invents an exception that does not exist; hardware dedication changes tenancy, not the responsibility for virtualization software.

1. Locate the hypervisor in the stack: it sits below the guest OS, on AWS's physical hosts.
2. Apply the anchor: virtualization and host software are always AWS's responsibility.
3. Recognize that EC2 giving customers the most control still stops at the guest operating system.
4. Reject shared or conditional ownership because a single layer always has one owner, and this layer is AWS's.

Exam tip: You never patch a hypervisor or host OS on AWS; the customer's patching duty begins at the guest OS.

Identity and access management is one of the responsibilities that never moves: the customer creates users and roles, assigns permissions, enforces least privilege, and manages credentials on every service.

Even on the most fully managed service AWS offers, only the customer knows who in their organization deserves which access, so IAM permissions remain security IN the cloud. The fully-managed distractor tests the trap that managed does not mean AWS owns everything: management moves operational layers like OS and runtime patching to AWS, but never access decisions. The review-only distractor misstates how IAM works; AWS supplies the service, but the customer authors every policy. The shared-control distractor fabricates a split that does not exist; the shared controls are patch management, configuration management, and awareness and training, and IAM appears in none of them.

1. Identify the task: granting permissions, which is identity and access management.
2. Apply the anchor: IAM is always the customer's responsibility, on every service.
3. Recognize that a service being serverless or managed shifts operational layers to AWS, never access decisions.
4. Reject any option that assigns AWS a role in authoring the customer's permissions.

Exam tip: IAM permissions are always the customer's responsibility; no level of service management changes that.