A team running an application on a PaaS offering discovers during an incident investigation that it cannot obtain operating system or platform-level logs, because the provider manages those layers and does not expose them to customers. Which cloud-specific risk has the team encountered?
Select an answer to reveal the explanation.
Short Explanation
You've rented a furnished apartment, and now you want to see the building's wiring diagram. Tough luck; the landlord owns that layer. Not being able to see or change what the provider manages is the lack of visibility and control risk, and you plan for it before the incident, not during it.
Full Explanation
Lack of visibility and control is the risk that a cloud customer cannot observe or influence layers the provider manages. The higher up the service model, the more of the stack sits with the provider: in PaaS the customer typically sees application logs and selected platform metrics, but not the underlying operating system, hypervisor or network devices. During incident response that gap limits what can be investigated. The mitigation is planning: deciding during the SDLC which logs and telemetry the application must produce itself, which data the provider makes available through its logging and API features, and what the contract guarantees about incident support and evidence access. Shared technology issues refer to vulnerabilities in components shared between tenants, such as hypervisors or shared engines, that can let one tenant affect another; the team's problem is missing insight, not cross-tenant exposure. Cloud service provider insider threats concern provider personnel misusing their access, which does not appear in the scenario. Legal and jurisdiction issues concern which laws apply to data, also absent here. Exam caveat: on the exam, the customer's response to limited visibility is contractual and architectural, because it cannot simply be demanded during an incident. Operational check: list the log sources the incident response plan assumes, confirm each is actually available for the service model in use, and fill gaps with application-level logging.