Virtualization, Cloud, and AI Essentials practice questions

The policy restricts the user to read-only access for files inside the root directory only.

Why it fails: The inclusion of the wildcard character on the resource arn:aws:s3:::company-data/* explicitly grants access to all objects within the bucket, not just the root directory. This allows the user to traverse and access any file located within the entire bucket structure, representing a potential security risk.

The policy permits the user to delete data from the bucket because s3:ListBucket is present.

Why it fails: The s3:ListBucket permission is limited to viewing the metadata of the bucket contents; it does not authorize deletion. Deletion requires the s3:DeleteObject or s3:DeleteBucket permissions, which are absent from this policy. Therefore, the user cannot modify or destroy the data based on these specific permissions.

The policy is invalid because the resource ARN formatting is missing the account ID.

Why it fails: S3 resource ARNs do not require an account ID to be valid. The format provided in the exhibit is syntactically correct for AWS IAM policies. The security issue is not with the syntax or the format, but rather with the excessive scope defined by the resource wildcards.

Cloud provider failure to patch physical server firmware.

Why it fails: The physical infrastructure, including server hardware and firmware, is the responsibility of the cloud provider. While a failure here is a risk, it is part of the provider's scope in the shared responsibility model, not a failure of the customer to manage their own cloud security.

Lack of visibility into the cloud provider's physical security protocols.

Why it fails: Physical security of the datacenter is handled by the cloud provider. While customers might want audits, the actual management and mitigation of physical security risks are solely the provider's responsibility. This is not a risk the customer manages under the standard shared responsibility model.

Encrypt all input strings using AES-256 before model processing.

Why it fails: Encryption does not prevent prompt injection because the model needs to decrypt the input to process it. Once decrypted, the malicious prompt is still present and will be executed by the model, providing no protection against the injection technique itself.

Increase the training dataset size to include more financial scenarios.

Why it fails: More training data does not protect against prompt injection. An attacker can still craft a malicious prompt regardless of how diverse the training data is. The issue is in the interaction layer, not the underlying training knowledge, so increasing the dataset provides no security benefit.

Limit the number of API queries allowed per user per hour.

Why it fails: Rate limiting is an effective control against brute-force or Denial of Service attacks, but it does not prevent prompt injection. Even a single allowed query can contain a malicious prompt that bypasses the model's security instructions, making rate limiting irrelevant for this specific vulnerability.

Deploying a Network Intrusion Detection System (NIDS) at the virtual switch level.

Why it fails: NIDS solutions are primarily visibility tools that monitor traffic rather than enforcing granular access controls. While useful for logging and alerting on suspicious activity, they do not inherently prevent lateral movement between virtual machines, as they lack the blocking capabilities required for active security enforcement.

Implementing a traditional hardware-based firewall at the edge of the datacenter.

Why it fails: Edge firewalls protect the perimeter but are completely invisible to East-West traffic occurring within the hypervisor layer. Since traffic between virtual machines on the same host never leaves the physical switch fabric, the edge device cannot inspect or block such communication flows effectively.

Enforcing full disk encryption on all virtual hard drives.

Why it fails: Full disk encryption protects data at rest in the event of physical storage theft or unauthorized access to the virtual disk file. It provides no protection against network-based lateral movement or unauthorized traffic between active virtual machines, making it irrelevant to this specific security objective.

Enable public access and rely on bucket ACLs for granular object permission.

Why it fails: Public access should never be enabled for buckets containing sensitive data, as it creates an immediate risk of mass exfiltration. Relying solely on ACLs is an outdated practice that often leads to inconsistent security postures; IAM policies are the preferred method for managing modern cloud permissions.

Assign full administrative rights to the bucket root user for ease of management.

Why it fails: Assigning full administrative rights to any user, especially for routine bucket access, violates the principle of least privilege. This creates excessive risk if credentials are compromised, as the attacker would have full authority to delete data, modify policies, or change encryption settings across the bucket.

Use a wildcard principal in the bucket policy to allow internal cross-account access.

Why it fails: Using wildcard principals in IAM policies is dangerous because it grants permissions to unauthorized accounts or identities. Cross-account access should always be explicitly scoped to specific, trusted AWS account IDs to prevent privilege escalation or unauthorized data access by external entities within the cloud environment.

Increase the confidence interval thresholds in the model API output.

Why it fails: While adjusting thresholds might change behavior, it does not address the fundamental vulnerability of model inversion. It may actually make the model less useful for legitimate users without providing any meaningful security improvement against sophisticated adversaries attempting to reverse-engineer the underlying training dataset.

Implement multi-factor authentication for all API management endpoints.

Why it fails: Multi-factor authentication is a best practice for administrative access and protecting cloud infrastructure, but it does not protect against model inversion. Inversion attacks typically occur via legitimate queries to the model's inference API, where the attacker acts as a standard user of the service.

Regularly rotate the API keys used to access the inference model.

Why it fails: Rotating API keys helps prevent unauthorized access to the service and mitigates the impact of credential theft. However, it does nothing to prevent an authorized user or an attacker from performing model inversion attacks using the legitimate API endpoints provided by the application.

Resource exhaustion.

Why it fails: Resource exhaustion is a Denial of Service condition where a VM consumes all available CPU or memory on the host, impacting other VMs. While a serious operational issue, it does not involve the attacker gaining unauthorized access to the underlying hypervisor or other guest systems.

Snapshot tampering.

Why it fails: Snapshot tampering involves modifying the state of a virtual machine saved at a previous point in time. While this can lead to security issues if an attacker injects malicious code into a snapshot, it is not the same as breaking out of the VM to the hypervisor.

Hypervisor misconfiguration.

Why it fails: Hypervisor misconfiguration refers to insecure settings, such as open management ports or weak administrative credentials. While misconfigurations can lead to a VM escape, the term itself refers to the setup error rather than the exploit technique where an attacker jumps from a guest to the host.

Container Orchestration.

Why it fails: Container orchestration, such as Kubernetes, focuses on managing the lifecycle of containerized applications, not the underlying infrastructure provisioning. While IaC can be used to deploy orchestration platforms, it is not the definition of the concept of defining infrastructure through code templates.

Serverless Computing.

Why it fails: Serverless computing refers to a cloud execution model where the provider manages the infrastructure, allowing developers to focus on code. It is an execution paradigm, not an automation tool for defining and deploying resources like IaC, and it involves a different set of security considerations.

Hyper-converged Infrastructure.

Why it fails: Hyper-converged infrastructure combines compute, storage, and networking into a single hardware system. It is a physical architecture strategy for datacenters, not a method for managing security configurations or deploying virtualized resources via automation as described in the question.

Host-based intrusion detection system (HIDS) on each guest

Why it fails: A HIDS installed on each guest monitors the guest OS's file system, logs, and processes. If an attacker escapes the guest, the HIDS is bypassed because it runs inside the compromised guest. It cannot observe hypervisor-level activities or memory access from the guest to the hypervisor, making it ineffective for detecting escape attempts.

Virtual firewall

Why it fails: A virtual firewall controls network traffic to and from VMs, typically operating at Layer 2-4. While it can segment traffic and enforce policies, it does not monitor internal VM memory or detect hypervisor escape attempts. It focuses on network perimeter security within the virtual environment, not on the hypervisor-guest boundary or memory introspection.

Security information and event management (SIEM) correlation

Why it fails: A SIEM aggregates and correlates logs from various sources, but it relies on data fed to it. Without a mechanism like hypervisor introspection to generate relevant events, the SIEM cannot detect hypervisor escape attempts. It is a monitoring and analysis tool, not a control that directly inspects VM memory or hypervisor interactions.

Enable server-side encryption with provider-managed keys and enforce TLS for data in transit.

Why it fails: Server-side encryption with provider-managed keys encrypts data at rest, but the provider holds the keys. TLS protects data in transit, not at rest. The requirement is specifically that the provider cannot access plaintext at rest; with provider-managed keys, the provider can decrypt the data, so this approach fails to meet the security objective.

Use provider-managed encryption keys with automatic rotation.

Why it fails: Provider-managed keys are controlled by the cloud provider. While they encrypt data at rest, the provider has access to the keys and can potentially decrypt the data. This does not meet the requirement that the provider cannot access plaintext, as the provider could be compelled or compromised. It also violates the principle of customer-controlled encryption for sensitive data.

Use a cloud access security broker (CASB) to encrypt data before it reaches the cloud.

Why it fails: A CASB can encrypt data in transit or apply policies, but it typically does not provide persistent encryption at rest with customer-controlled keys. If the CASB encrypts data before it reaches the cloud, the cloud provider still might have access if keys are managed by the CASB vendor. This does not guarantee that the provider cannot access plaintext, as the CASB may be cloud-based.

Enable Encrypted vMotion on the VMkernel adapter.

Why it fails: Encrypted vMotion protects VM memory in transit during live migration between hosts, not memory resident on the same host. In this scenario no migration is described; the attacker read another VM's memory on the same ESXi host, so encrypting the vMotion channel would not block a local cross-VM read. It addresses a different threat model entirely.

Configure a vSphere Standard Switch with VLAN tagging for each VM.

Why it fails: VLAN tagging on a vSphere Standard Switch segments Layer 2 network traffic between VMs. It has no effect on memory isolation inside the hypervisor. The scenario is about one VM reading another VM's physical memory, which is a hypervisor-level isolation failure, not a network segmentation issue, so VLAN configuration would not stop the attack.

Set the VM's isolation.tools.copy.disable parameter to TRUE.

Why it fails: This advanced parameter disables copy and paste operations through VMware Tools between the guest and the remote console. It restricts user-facing clipboard functionality and does not enforce memory isolation between VMs. It would not prevent a malicious guest from reading another VM's memory, making it irrelevant to the described hardware-level disclosure.

Set the imagePullPolicy to Always on every container manifest.

Why it fails: imagePullPolicy Always only forces the kubelet to fetch the image from the registry each time a pod starts. It does not verify that the image was scanned or approved, and an attacker could still push a malicious tag. The control affects caching behavior, not admission decisions, so it fails to meet the audit requirement.

Configure the container runtime to run all pods as non-root users.

Why it fails: Running as non-root reduces the impact of a container breakout but says nothing about image provenance. An unscanned or malicious image can run perfectly well as a non-root user and still introduce vulnerabilities. This setting addresses runtime privilege, not the requirement to block images that failed scanning, so it does not satisfy the auditor.

Configure a network policy that denies egress from all namespaces.

Why it fails: Network policies restrict pod-to-pod and pod-to-external traffic at Layers 3 and 4. They do not inspect image provenance or block the scheduling of a pod based on which image it references. A pod built from an unscanned image would still be admitted and run, so this control does not satisfy the auditor's requirement for image integrity enforcement.

Increase the model's temperature setting to make responses less predictable.

Why it fails: Temperature controls randomness in token selection; higher values make output more varied, not safer. Raising it could increase the chance of unpredictable or hallucinated content and does nothing to prevent sensitive data from being included. It is unrelated to data exposure risk and may worsen reliability in a customer support context.

Store the model weights in a versioned object storage bucket with access logging enabled.

Why it fails: Versioning and logging on model weights protect the integrity and auditability of the model artifact itself. They do not govern what data the model retrieves or returns at inference time. The risk described is runtime data exposure through responses, so this control addresses a different asset and does not mitigate the stated risk.

Fine-tune the model on a dataset of historical customer interactions.

Why it fails: Fine-tuning changes the model's behavior and style but can actually increase risk if the training data contains sensitive information that the model memorizes and later emits. It does not provide runtime control over which live data enters responses. This option fails to address the exposure risk and may introduce new leakage paths.

Apply a Layer 2 ACL on the physical switch to permit only ESXi management IP addresses on the guest VLAN.

Why it fails: A Layer 2 ACL restricting traffic by management IP does not separate vMotion from guest data, because vMotion uses its own VMkernel interface and IP. The ACL would not prevent a compromised guest on the same segment from observing migration frames, nor does it provide encryption. This control addresses management access, not the confidentiality or integrity of live migration traffic.

Move all virtual machines to a single ESXi host so that vMotion is never used.

Why it fails: Consolidating all workloads onto one host eliminates vMotion but destroys the availability and maintenance benefits of the cluster and creates a single point of failure. It does not address the underlying security architecture and is operationally unacceptable for a production three-tier application. The requirement is to secure migration traffic, not to abandon live migration entirely.

Enable promiscuous mode on the vSwitch so that vMotion frames can be inspected by the host firewall.

Why it fails: Promiscuous mode allows virtual network adapters to receive frames not addressed to them, which would actually worsen the exposure by permitting guests to observe more traffic. It provides no cryptographic protection for vMotion and does not isolate migration traffic from guest data. The host firewall does not inspect vMotion frames in this manner, so this setting fails to remediate the auditor's finding.

Infrastructure as code

Why it fails: Infrastructure as code is the practice of managing and provisioning infrastructure through machine-readable definition files. It improves consistency and auditability but does not assign security responsibilities between a provider and a customer. The question is about responsibility boundaries, not deployment automation, so this option does not answer the scenario.

Defense in depth

Why it fails: Defense in depth is a strategy of layering multiple controls so that failure of one does not compromise the whole. It does not specify who patches the operating system or secures the hypervisor. The scenario asks for the concept that divides provider and customer duties, which defense in depth does not define, making it the wrong fit.

The principle of least privilege

Why it fails: Least privilege is an access control principle that grants users and services only the permissions needed to perform their tasks. It does not describe the split of security duties between a cloud provider and a customer. While valuable, it addresses authorization scope, not the allocation of patching and infrastructure responsibilities described in the scenario.

Increase the model's temperature setting to make responses less deterministic and harder to exploit.

Why it fails: Temperature controls randomness in token selection and has no security effect on instruction hierarchy. Raising it would make outputs less predictable but would not prevent the model from following injected instructions, and it could degrade answer quality for financial data. This is a tuning parameter, not a security control, and it fails to address the injection vulnerability.

Require multi-factor authentication for all API consumers before they can submit prompts.

Why it fails: Authentication verifies who is calling the API but does not constrain what an authenticated user can ask. A legitimate but malicious or compromised account can still submit injection payloads. MFA raises the bar for account takeover but leaves the prompt injection vulnerability intact, so it does not directly mitigate the demonstrated extraction of the system prompt and schema.

Fine-tune the model again using only publicly available financial data to remove sensitive schema information.

Why it fails: Retraining changes what the model knows but does not change how it processes instructions. An attacker can still inject override phrases to extract the system prompt or manipulate behavior. Removing sensitive data is good practice but does not stop prompt injection, which is an input-handling flaw rather than a data-content flaw, so this does not mitigate the demonstrated attack.

Enable function-level concurrency limits to prevent runaway executions.

Why it fails: Concurrency limits control how many instances of the function run simultaneously, which helps with cost and availability. They do not constrain what permissions the function has. An attacker using the function's role would still have full administrative access, so this control does not address the least privilege finding.

Move the function's credentials into environment variables encrypted with a customer-managed key.

Why it fails: Encrypting credentials at rest protects them from casual disclosure, but the role still grants full administrative access once assumed. The over-privileged permissions remain the core problem, so this change does not reduce the effective privilege of the function and fails to apply least privilege.

Configure the function to run inside a virtual private cloud with restrictive security groups.

Why it fails: Network controls restrict where the function can send and receive traffic but do not limit which cloud API actions its role can perform. The function could still call administrative APIs over allowed endpoints. Since the finding is about excessive permissions rather than network reachability, this option does not remediate the issue.

ResourceQuota objects that limit CPU and memory consumption per namespace.

Why it fails: ResourceQuota prevents resource exhaustion and noisy-neighbor problems by capping compute and storage usage. It has no bearing on network reachability, so a compromised container can still communicate with other pods and node services. This control addresses availability and capacity planning, not lateral movement, and therefore does not satisfy the security lead's requirement.

Horizontal Pod Autoscaler configured to scale replicas based on CPU utilization.

Why it fails: The Horizontal Pod Autoscaler adjusts the number of pod replicas in response to load. It is an availability and performance mechanism and does not filter or restrict network traffic. Scaling up replicas could even increase the attack surface if those pods are equally reachable, so it does not limit lateral movement from a compromised container.

PodSecurityPolicy admission controller configured to disallow privileged containers.

Why it fails: PodSecurityPolicy governs pod creation requirements such as privilege, volume types, and capabilities. It does not control network traffic between running pods, so a compromised container could still reach other workloads over the network. It reduces the impact of a container escape but does not restrict lateral movement at the network layer, making it the wrong control for this objective.

Configuring the SaaS application's database engine parameters for optimal query performance.

Why it fails: The database engine underpinning a SaaS application is managed by the provider. Customers typically have no direct access to database configuration parameters and cannot tune them. Performance tuning at that layer is a provider concern, while the customer focuses on configuration exposed through the application, such as workflows, roles, and retention settings.

Maintaining the physical security of the data center facilities where the service runs.

Why it fails: Physical security of data centers is always the cloud provider's responsibility, regardless of service model. The provider controls access to facilities, hardware, and environmental controls. The customer cannot influence or perform these functions, so they are not part of the customer's shared responsibility for a SaaS deployment.

Patching the operating system and hypervisor that host the SaaS application.

Why it fails: In a SaaS model, the provider owns and operates the underlying infrastructure, including operating systems, hypervisors, and the application runtime. Patching these layers is entirely the provider's responsibility. The customer has no access to these layers and cannot perform patching, so this is not a customer responsibility under the shared responsibility model.

Disable the S3 bucket's default encryption so that stolen credentials cannot decrypt the content.

Why it fails: Disabling encryption does not prevent credential theft and would expose the unreleased content to anyone who obtains access. Encryption protects data at rest; the attack targets the credentials used to authorize access. Removing encryption weakens confidentiality and does not address the metadata service vulnerability, making it a harmful and ineffective response.

Attach a broader IAM role to the instance so that stolen credentials have more permissions but are easier to rotate.

Why it fails: Expanding permissions increases the blast radius if credentials are stolen and does nothing to prevent theft. Rotation is a detective and recovery measure, not a preventive one, and broader roles violate least privilege. This approach would worsen the impact of the compromise rather than mitigate the attacker's ability to retrieve and abuse temporary credentials.

Store long-term IAM user access keys in the application configuration file on the instance.

Why it fails: Long-term access keys in a configuration file are far more dangerous than temporary instance role credentials because they do not expire automatically and are easily exfiltrated. This introduces a permanent credential that persists even after the instance is terminated. It directly contradicts best practice and increases the risk of unauthorized S3 access rather than reducing it.