Cloud Platform & Infrastructure Security

The correct answer is to instantiate Confidential Virtual Machines enabling whole-instance memory encryption with platform attestation.

This architecture directly addresses the scenario's constraints. First, Confidential Virtual Machines (CVMs) provide hardware-based memory encryption that isolates data-in-use from the cloud provider's infrastructure, including the hypervisor. Second, because the encryption is applied at the VM level provided by the hardware (such as AMD SEV-SNP or Intel TDX), it allows for 'lift and shift' migration of legacy applications without requiring code modifications or recompiling. Finally, platform attestation serves as the cryptographic challenge mechanism to verify the integrity of the underlying hardware environment before sensitive secrets are released to the instance.

Refactoring critical functions into application-level enclaves is incorrect because the scenario explicitly requires processing existing binaries without code modification; application-level enclaves (like SGX) typically require rewriting the application to separate trusted and untrusted components. Implementing Full Homomorphic Encryption is incorrect because, while it protects data in use, it is computationally prohibitive for general legacy applications and usually requires significant changes to how data is processed and stored, failing the 'no modification' constraint for standard binaries. Configuring dedicated bare-metal hosts with HSMs is incorrect because while an HSM protects keys, it does not encrypt the main system volatile memory (RAM) against physical or firmware-level attacks in the way Confidential Computing does, nor does it inherently offer the specific attestation flow for memory isolation from a hypervisor in an IaaS context.

The correct answer is the Proof Key for Code Exchange (PKCE) extension. In the context of OAuth 2.0 for public clients, such as Single Page Applications (SPAs) running in a browser, maintaining the confidentiality of a static client secret is impossible. Consequently, these applications are vulnerable to authorization code interception attacks. PKCE (defined in RFC 7636) mitigates this risk by creating a cryptographic binding between the initial authorization request and the subsequent token exchange. It achieves this by generating a unique 'code verifier' and 'code challenge' for every transaction. The server verifies that the entity exchanging the authorization code is the same entity that initiated the request by validating these dynamic secrets, rendering intercepted codes useless to attackers who do not possess the original verifier.

Mutual Transport Layer Security (mTLS) certificate binding is a mechanism often used for sender-constrained tokens or authenticating confidential clients, but managing client certificates securely within a public browser environment is generally impractical for this specific use case.

Encrypted Assertion Consumer Service validation mixes terminology from SAML (Security Assertion Markup Language) with OAuth concepts. While SAML uses an Assertion Consumer Service (ACS), the scenario describes an OAuth/OIDC authorization code flow, making this option technically incorrect.

The State parameter integrity validation is a standard OAuth 2.0 mechanism used to prevent Cross-Site Request Forgery (CSRF) attacks. While it helps ensure the response belongs to the request, it does not effectively prevent an attacker who has stolen an authorization code from exchanging it for an access token, which is the specific threat addressed by PKCE.

The correct answer is Server-Side Request Forgery targeting the instance metadata service.

The scenario describes a classic Server-Side Request Forgery (SSRF) attack. SSRF creates a situation where an attacker can induce a server-side application to make requests to an unintended location. In cloud environments, the IP address 169.254.169.254 is a link-local address universally reserved for the Instance Metadata Service (IMDS). This service provides information about the running instance to the instance itself, including temporary Identity and Access Management (IAM) credentials. By manipulating the application to send a GET request to this specific IP, the attacker bypassed the network boundary and accessed the cloud control plane's internal trust relationship with the instance to steal credentials.

Why the other answers are incorrect:

Remote File Inclusion involves forcing an application to include a file residing on a remote server, typically to execute malicious code. While this is a server-side attack, the specific targeting of the local metadata IP address to retrieve data characterizes an SSRF attack, not RFI. Additionally, the target IP is the metadata service, not a hypervisor administration interface.

XML External Entity (XXE) attacks exploit vulnerabilities in how an application parses XML input. While XXE can be a mechanism used to achieve SSRF, the scenario describes an image rendering function issuing HTTP GET requests directly. SSRF is the specific vector defined by the server issuing requests to internal resources on behalf of the attacker.

Cross-Site Request Forgery (CSRF) is a client-side attack that tricks a user's browser into executing unwanted actions on a web application where they are currently authenticated. The scenario described occurs entirely on the server-side (the cloud workload), making CSRF irrelevant.