Cloud Security Fundamentals And Shared Responsibility practice questions

Network-level encryption

Why it fails: This protects data in transit, not at rest.

Client-side encryption only

Why it fails: Server-side is sufficient for most cloud storage needs.

Physical security locks

Why it fails: Physical locks do not protect against data breaches in the cloud.

Design of the global network backbone

Why it fails: Exclusively provider responsibility.

Physical security of the facility

Why it fails: Exclusively provider responsibility.

Physical maintenance of the underlying server hardware

Why it fails: This is exclusively AWS responsibility.

Patching the underlying database engine operating system

Why it fails: This is managed by AWS in the RDS service model.

Managing network isolation of the RDS instances

Why it fails: AWS provides the VPC infrastructure, but the customer manages the configuration.

Implementation of physical disk encryption at rest

Why it fails: Google handles infrastructure-level encryption automatically.

Redundancy of the data across physical regions

Why it fails: Google provides these options, but the customer manages the bucket policy.

Management of the underlying storage hardware lifecycle

Why it fails: This is a provider responsibility.

Management of the host hardware lifecycle

Why it fails: Exclusively provider.

Physical server maintenance

Why it fails: Exclusively provider.

Data center facility security

Why it fails: Exclusively provider.

Configuring firewall rules to restrict traffic to the Compute Engine instances

Why it fails: Firewall rules in GCP are customer-configured. The customer defines ingress and egress rules to control traffic to their instances. Google provides the firewall service, but the customer sets the rules. This option misassigns a customer responsibility to Google. In IaaS, network security controls are part of the customer's domain, requiring careful configuration to avoid exposure.

Managing the guest operating system updates on the Compute Engine instances

Why it fails: On Compute Engine, the customer is responsible for the guest operating system, including updates and patches. Google manages the hypervisor and physical infrastructure, but not the guest OS. This option incorrectly assigns a customer duty to Google. In IaaS, the customer controls the OS layer, so they must apply security patches to maintain compliance and security.

Encrypting data at rest in the customer's Cloud Storage buckets

Why it fails: While Google encrypts data at rest by default, the customer is responsible for managing encryption keys if they choose customer-managed encryption keys (CMEK) or for ensuring data is encrypted before storage. The customer also controls access to the data. This option oversimplifies. In the shared responsibility model, data security, including encryption key management, is a customer duty when using CMEK.

Maintain the physical security of the data center that houses the RDS database.

Why it fails: Physical security of AWS data centers is always the responsibility of AWS, regardless of the service model. The customer cannot control or manage physical access to AWS facilities. Even in IaaS, the provider secures the buildings, power, cooling, and hardware. Therefore, this control is not the customer's responsibility in this scenario.

Apply security patches to the underlying host operating system that runs the RDS database.

Why it fails: RDS is a managed database service. AWS is responsible for patching the database engine and the underlying host operating system. The customer only manages data, schema, and access controls. They cannot access the host OS. Thus, this control belongs to AWS, not the customer, under the shared responsibility model.

Configure the network ACLs and security groups for the Application Load Balancer.

Why it fails: While the customer is responsible for configuring security groups and network ACLs that apply to their resources, the Application Load Balancer itself is a managed service. AWS manages the load balancer's underlying infrastructure, including its scaling, patching, and availability. The customer only configures listener rules and target groups, not the load balancer's security patching.

Managing the hypervisor that isolates Compute Engine instances

Why it fails: The hypervisor is a critical part of Google's managed infrastructure. Google is responsible for its security, patching, and isolation between tenants. Customers do not have access to the hypervisor and cannot manage it. This is a fundamental aspect of the shared responsibility model: the provider secures the virtualization layer. Hence, this is not a customer responsibility.

Patching the operating system of the Compute Engine instances

Why it fails: Google is responsible for the global network infrastructure that connects its regions and zones. This includes routers, switches, and physical links. Customers do not manage or secure this network. Therefore, this is not a customer responsibility. The customer's focus is on their own VPC networks and firewall rules, but the underlying physical network is Google's.

Securing the physical infrastructure of the GCP region where the data is stored

Why it fails: Google is responsible for the physical security of its data centers and regions. This includes access controls, power, cooling, and hardware disposal. Customers do not have any role in securing the physical infrastructure. Therefore, this is not a customer responsibility under the GCP shared responsibility model. It remains entirely with Google.

To automate the revocation of keys

Why it fails: Least privilege governs granting identities only the permissions their tasks require; key revocation is a separate lifecycle control. Automated revocation would be the answer if the question asked about credential rotation or deprovisioning, not permission scoping.

To reduce the number of IAM users

Why it fails: Least privilege grants each identity only the permissions its tasks require; it does not mandate fewer IAM users. Consolidating accounts can even concentrate access. Reducing IAM user count is the goal of identity consolidation or federation, not of limiting permissions per principal.

To increase the complexity of password requirements

Why it fails: Increasing password complexity hardens credential strength against brute-force and guessing attacks, but least privilege governs authorisation — which identities may perform which actions on which resources. Password policy is the right control when the requirement is credential assurance, such as enforcing length and character rules under a Microsoft Entra ID password policy, not limiting standing access.

Allow all traffic by default

Why it fails: AWS security groups deny all inbound traffic by default; nothing is permitted until an explicit allow rule is added. It is tempting because some firewall products ship with permissive defaults, but AWS follows a default-deny model for inbound security group rules.

Allow only SSH and RDP traffic

Why it fails: AWS security groups deny all inbound traffic by default; SSH and RDP are permitted only when explicitly added as rules. The option tempts because those ports are commonly opened for remote administration, but no such default rule exists.

Allow traffic from the VPC CIDR

Why it fails: Security groups start with no inbound rules, so VPC CIDR traffic is blocked until explicitly allowed. The option tempts because VPC-internal communication is often permitted in practice, but that requires an added rule, not default behaviour.

Physical datacenter security

Why it fails: Google secures the physical datacentre under the shared responsibility model, so this is never the customer's task on Cloud SQL. It tempts because physical controls are a genuine customer concern for on-premises databases, where the organisation owns the building, power and hardware.

Host operating system hardening

Why it fails: Cloud SQL is a managed service; Google patches and hardens the underlying host operating system, so this is not the customer's task. It is tempting because OS hardening is a customer duty on IaaS compute instances, but that responsibility shifts to Google under the managed database model.

Database software patching

Why it fails: Google patches the underlying database engine for Cloud SQL; the customer patches only data and access configuration. It tempts because software patching is a real customer duty on self-managed databases such as MySQL on Compute Engine, where no managed service intervenes.

Relying on manual configuration audits

Why it fails: Cloud-native security automates policy enforcement through infrastructure-as-code and continuous scanning, so manual audits cannot keep pace with constantly redeployed workloads. It tempts because periodic manual auditing remains workable for slowly changing, on-premises environments with infrequent releases.

Using only on-premises security appliances

Why it fails: Cloud-native security relies on cloud-delivered controls such as identity-based policies and workload protection, which on-premises appliances cannot extend to multi-cloud estates. It tempts because physical appliances remain valid for inspecting traffic inside a single, static data centre you fully own.

Focusing exclusively on perimeter security

Why it fails: Cloud-native security assumes no trusted perimeter, authenticating and authorising every workload and API call individually; perimeter-only defence cannot secure ephemeral, distributed workloads. It tempts because perimeter firewalls remain valid for protecting traditional static data-centre networks with clear inside/outside boundaries.

Shared responsibility for data encryption

Why it fails: Encryption responsibility varies by service and data state, so it is not the model's hardware-maintenance element. Microsoft alone handles physical host upkeep, which the question targets. Shared encryption duties would fit a question about protecting data at rest or in transit across IaaS, PaaS or SaaS.

Customer responsibility for OS patching

Why it fails: Hardware maintenance sits with Microsoft under the Shared Responsibility Model, not the customer. OS patching is a customer task for IaaS virtual machines, so it addresses software layers the customer controls. It would be the correct answer only if the question asked who patches the guest operating system.

Customer responsibility for identity management

Why it fails: Identity management is a customer responsibility under the Shared Responsibility Model; hardware maintenance sits with Microsoft as part of the physical and infrastructure layer. It is tempting because identity controls are a major customer duty in cloud deployments, and this option would be correct if the question asked who manages users, credentials and access policies.

Static IP allow-lists

Why it fails: Static IP allow-lists grant implicit trust based on network location, which Zero Trust explicitly rejects; they cannot verify user identity, device compliance or request context. They are tempting because they are simple to configure, and would be correct for restricting access to fixed on-premises egress addresses, not cloud identities.

Default open network ports

Why it fails: Open ports describe a permissive configuration state, not a verification mechanism; Zero Trust requires every request to be authenticated and authorised regardless of port. It is tempting because closing ports reduces attack surface, and would be correct as a hardening step, but it never verifies a request's identity or context.

Physical firewalls

Why it fails: Physical firewalls filter at the network perimeter by IP and port, so they cannot evaluate user identity, device health or per-request context inside the cloud. They are tempting because perimeter filtering is a familiar control, and would be correct for segmenting on-premises data-centre traffic, not cloud Zero Trust verification.

The AWS Support Team

Why it fails: Bucket policies are configured by the customer, not AWS; under the Shared Responsibility Model, AWS secures the cloud infrastructure itself, while the customer secures what they put in it. The Support Team assists with service issues and billing, and would only be the right contact for AWS-managed infrastructure faults, not customer S3 permissions.

AWS

Why it fails: AWS secures the infrastructure underlying S3, but configuring bucket policies and access controls remains the customer's duty under the Shared Responsibility Model. AWS is tempting because it operates the service, yet it is the correct party only for security of the cloud itself, not customer data configuration.

The Cloud Service Provider (CSP) Shared Responsibility Framework

Why it fails: The Shared Responsibility Framework is a model describing how duties divide, not an entity that configures bucket policies; it cannot act on the account. It is tempting as the conceptual basis for the split, but it is the correct reference when explaining responsibility boundaries, not performing configuration.

AWS CloudTrail

Why it fails: AWS CloudTrail records API activity and account events for auditing, but does not evaluate resource configuration against compliance rules or detect drift. It is tempting because it is a governance service, yet it would be correct for tracing who made an API call, when and from where.

AWS Shield

Why it fails: AWS Shield provides DDoS protection at the network and transport layers; it reports no configuration state, so drift and compliance posture remain invisible. It is tempting because Shield is a security service, but it would be correct when defending internet-facing endpoints against volumetric attacks.

Amazon Inspector

Why it fails: Amazon Inspector scans compute and container workloads for software vulnerabilities and unintended network exposure, not resource configuration drift against compliance baselines. It is tempting as a security assessment tool, but it would be correct for continuous vulnerability findings on EC2, ECR images or Lambda functions.

The Azure Tenant Administrator

Why it fails: Tenant administrators govern identities, roles and access policies in Microsoft Entra ID, but never physical HSM hardware. The role is tempting because administrators control who can use keys, yet Microsoft alone operates and protects the underlying FIPS 140-2 Level 2 modules.

The Customer

Why it fails: Microsoft, not the customer, secures the HSM hardware under the shared responsibility model; customers manage keys and access policies only. Choosing the customer confuses data and identity responsibility with physical HSM custody, which would apply only to customer-managed HSMs or on-premises hardware.

The Security Auditor

Why it fails: Auditors assess and report on controls; they hold no operational custody of HSM hardware. The option tempts because auditors verify compliance evidence for key protection, but the actual safeguarding of the physical module remains Microsoft's responsibility under the shared responsibility model.

Manual provisioning

Why it fails: Manual provisioning depends on human action, delaying restoration during an incident when speed matters. Infrastructure as code and automated deployment pipelines restore services rapidly. Manual provisioning suits one-off, non-critical workloads where automation overhead is unjustified.

Security through obscurity

Why it fails: Security through obscurity hides implementation details to deter opportunistic attackers, but it neither restores services nor provides any recovery mechanism after a breach. It is tempting because obscurity can reduce reconnaissance exposure, and it would suit hardening a low-value internal system where disclosure of design details is the primary risk.

Local backup storage

Why it fails: Local backup storage ties recovery data to the affected site, so an incident damaging that location also destroys the backups. Cloud-based, geographically redundant backups enable rapid restoration. Local storage suits low-cost retention of non-critical data within a single facility.

Reviewing physical datacenter floor plans

Why it fails: Cloud-native threat modelling examines identities, IAM policies, APIs, serverless functions, containers and shared-responsibility boundaries; physical floor plans are irrelevant because the provider secures the datacentre. It is tempting as classic threat modelling often maps physical access, but that layer sits outside the customer's control. The correct step enumerates cloud attack surfaces.

Updating local workstation antivirus

Why it fails: Cloud-native threat modelling focuses on IAM, APIs, containers and serverless attack paths; endpoint antivirus on local workstations falls outside the cloud workload boundary. It is tempting because antivirus is a familiar security control, but it does not address cloud service misconfiguration or identity abuse. The correct step enumerates cloud-native attack surfaces.

Ordering new network hardware

Why it fails: Cloud-native threat modelling addresses identity, API, container and serverless attack surfaces under the shared-responsibility model; hardware procurement is a provider concern and irrelevant to design analysis. It is tempting because on-premises threat modelling historically included network hardware, but cloud infrastructure is abstracted. The correct step maps cloud-specific trust boundaries and IAM permissions.

To manage employee identity lifecycle

Why it fails: CSPM assesses cloud resource configurations for misconfigurations and compliance drift; it does not provision, authenticate or deprovision user accounts. Identity lifecycle management belongs to Microsoft Entra ID or an IGA platform, so this describes a different discipline entirely.

To perform deep packet inspection of encrypted traffic

Why it fails: CSPM compares cloud configuration against security baselines to find misconfigurations like public buckets; it does not inspect packet payloads. Deep packet inspection belongs to network security tooling such as NGFWs or IDS, making this the wrong capability for posture assessment.

To block DDoS attacks

Why it fails: CSPM continuously assesses cloud configurations against benchmarks and compliance baselines, so it detects misconfigurations rather than absorbing volumetric traffic. Blocking DDoS attacks is the function of a dedicated DDoS mitigation service or cloud provider edge protection, which is the correct choice when the requirement is defending availability against flood attacks.