Cloud Application Security

A healthcare startup builds a patient-scheduling application on public-cloud IaaS, handling data classified as sensitive personal health information. A developer needs a database password for the running service and currently the value sits in a plaintext variable inside the application's version-controlled configuration file. Applying secure coding and software configuration management practices, what should the team do next to remediate this before the next release?

• AMove the password into an environment variable set on the build server so it no longer appears in the source file.
• BRetrieve the password at runtime from a managed secrets vault using the service's own identity, and remove it from version control.check_circle Correct
• CEncrypt the configuration file at rest in the repository and commit the encrypted version alongside the code.
• DRestrict repository access to the two senior developers who maintain the scheduling service and leave the value in place.

Why A is wrong: Using an environment variable removes the literal string from the file and feels like progress, but the secret is still unmanaged, unrotated and readable to anyone with host access, so it does not meet the standard for protecting a sensitive credential.

Why B is correct: Fetching the secret at runtime from a managed vault keyed to the service identity keeps the credential out of source control, supports rotation and access logging, and is the recognised secure practice for handling application secrets.

Why C is wrong: Encrypting the file at rest sounds protective, but the decryption key must then live somewhere and the secret still travels through version control, so this shifts the problem rather than removing the credential from the codebase.

Why D is wrong: Tightening repository permissions reduces who can read the file, but the secret remains committed in history and unrotated, so a single leaked clone or a former maintainer still exposes it; access control alone does not remediate a stored secret.

A healthcare SaaS vendor deploys a patient-portal web service on public-cloud IaaS and classifies its records as sensitive personal data. Its SAST results are clean, but leadership wants evidence of how the running application actually behaves against real attacks, including authentication bypass and session flaws that only appear at runtime. Which validation activity best provides that evidence?

• ADynamic application security testing (DAST) against the deployed portal to exercise it as an attacker would at runtimecheck_circle Correct
• BRepeat SAST with an expanded ruleset to increase coverage of the source code
• CA software composition analysis scan of third-party libraries for known vulnerable versions
• DA configuration review of the IaaS security groups and network access controls

Why A is correct: DAST drives the running application from the outside with malicious inputs, exposing authentication bypass and session-handling flaws that only surface during execution, which directly matches the request for runtime behavioural evidence.

Why B is wrong: Broader SAST rules improve source coverage, which sounds thorough, but static analysis cannot observe live authentication or session behaviour, so it cannot supply the runtime evidence leadership is asking for.

Why C is wrong: Composition analysis is valuable for flagging vulnerable dependencies, but it inspects component inventories rather than exercising the live application, so it does not reveal runtime authentication or session weaknesses.

Why D is wrong: Reviewing security groups hardens the infrastructure layer the vendor is responsible for, but it examines network configuration, not the application's runtime authentication and session logic, so it addresses a different risk.

During which phase of the secure SDLC is threat modelling most valuable, given that it aims to identify design weaknesses before any code is committed?

• AThe requirements phase, before any functionality or data flow has been decided
• BThe design phase, where the architecture and data flows are defined and can still be changed cheaplycheck_circle Correct
• CThe testing phase, so that identified threats can be confirmed against the built system
• DThe deployment phase, once the production environment configuration is known

Why A is wrong: The requirements phase is where security requirements are gathered, but there is not yet enough design detail (trust boundaries, components, data flows) for a meaningful threat model, so this is too early.

Why B is correct: Threat modelling examines the architecture, trust boundaries and data flows, so it delivers the most value in the design phase while changes remain inexpensive and no code has yet been written.

Why C is wrong: Testing can validate that mitigations work, but discovering a design flaw only at this stage forces expensive rework, so threat modelling here is far later than ideal.

Why D is wrong: Deployment configuration matters for operational hardening, but waiting until deployment to model threats means design flaws are already baked into the code and costly to remove.

A fintech firm exposes a set of RESTful microservices from a public PaaS environment to third-party partner applications. The services process confidential financial records. Partners have varied trust levels, and the firm needs a single enforcement point to authenticate callers, apply per-partner rate limits, and route requests to the correct backend service. Which architectural component BEST provides this capability?

• AA web application firewall placed in front of each microservice to sign inbound partner traffic.
• BApplication virtualisation to package each microservice so partners run a consumer-side instance.
• CAn API gateway that authenticates callers, enforces per-partner rate limits, and routes requests to backend services.check_circle Correct
• DDatabase activity monitoring on the backing datastores to record which partner accessed which record.

Why A is wrong: A WAF inspects and filters HTTP requests for malicious content, but it does not natively authenticate API callers, enforce per-partner quotas, or route requests to specific backends.

Why B is wrong: Application virtualisation isolates and delivers applications to endpoints, which does nothing to broker, authenticate, or rate limit inbound partner API calls at a central point.

Why C is correct: An API gateway is the single managed entry point that handles caller authentication, throttling and quotas per consumer, and request routing to the appropriate microservice.

Why D is wrong: Database activity monitoring provides visibility and alerting at the data tier, but it is a detective control and cannot authenticate, throttle, or route the API traffic itself.

A development team wants a single artefact that lists every third-party and open-source component in a container image, including transitive dependencies, so that when a new vulnerability is disclosed they can immediately tell whether the image is affected. Which artefact provides this?

• AA static application security testing (SAST) report for the source code
• BA penetration test report covering the running container
• CA software bill of materials (SBOM) generated for the imagecheck_circle Correct
• DA signed provenance attestation for the build pipeline

Why A is wrong: SAST inspects first-party source for coding flaws; it is tempting because it is a supply-chain-adjacent scan, but it does not enumerate third-party and transitive components.

Why B is wrong: A penetration test records exploitable weaknesses found at runtime, which is useful assurance, but it is not a component inventory and will not list every dependency.

Why C is correct: An SBOM is the formal inventory of every component and dependency in a build, so it is exactly what lets a team map a newly disclosed CVE to affected images.

Why D is wrong: Provenance attestation proves how and where an artefact was built, which strengthens supply-chain trust, but it records build metadata rather than the list of bundled components.