Security Architecture practice questions

Serverless shifts infrastructure, OS and runtime maintenance to the provider; the customer keeps its code, data and permissions.

Moving to serverless removes every layer below the code from the customer's control: the physical hosts, hypervisor, operating system and managed runtime are maintained by the provider, and the platform scales capacity on its own. What the company still owns is the function itself, meaning secure code, input validation and the permissions the function runs with. The OS patching option is tempting because the company patched it on virtual machines, but that duty moved to the provider.

1. List what the company managed on virtual machines: OS, runtime, code and permissions.
2. Remove the layers a serverless provider takes over: hosts, hypervisor, OS and runtime.
3. What remains is the function code and the permissions it uses.

Exam tip: In serverless you secure the code and its permissions; the provider secures everything underneath.

In serverless the main customer-controlled boundary is the identity and permissions each function runs with.

Two facts combine. First, serverless removes the guest OS, host firewall and hypervisor from the customer's control, so those options do not describe anything the company configured. Second, once code is exploited the attacker acts with the function's own permissions, so how far the attack reaches depends on what that identity may access. Reading every bucket means the function was granted far more than file conversion needs.

1. Rule out host-level causes: serverless customers manage no OS, host firewall or hypervisor.
2. Note the attacker reused the function's legitimate access after exploiting code.
3. Ask what decided how much that access could reach: the function's permissions.
4. Conclude the permissions were broader than the function needed.

Exam tip: In serverless, a function's permissions set the blast radius of any code flaw.

Multicloud reduces single-provider dependence but multiplies the platforms whose controls must be kept consistent.

Every cloud provider has its own consoles, identity and access management, logging formats and security services. Running across three of them means writing and enforcing equivalent policies three times and correlating three sets of logs, which raises the chance of gaps and misconfiguration. Dependence on one provider goes down, not up, each provider still has a shared responsibility model, and each provider's tenant isolation is the same as before.

1. Identify what multicloud changes: several providers, each with its own tooling.
2. Recognize the benefit it brings: less dependence on any one provider.
3. Recognize the cost it brings: more control sets to keep aligned.
4. Pick the challenge that follows from that added complexity.

Exam tip: Multicloud trades vendor dependence for complexity: more platforms, more places for controls to drift.

Matching an architecture to two requirements: provider independence (multicloud) and ownership of hardware (on-premises).

Each requirement eliminates options. Surviving the outage of any single provider needs more than one provider, which rules out multi-region and any single-platform design. Keeping payroll on hardware the company owns rules out every arrangement where a provider or community operator owns the servers. Only a multicloud portal combined with on-premises payroll storage satisfies both. Multi-region is the tempting answer because it is a common resilience pattern, but it still depends on one provider.

1. Translate requirement one: no single provider can be a dependency, so more than one provider is needed.
2. Translate requirement two: payroll must sit on company-owned hardware, which means on-premises.
3. Eliminate options that fail either requirement.
4. Choose the combination of multicloud and on-premises.

Exam tip: Outage of a whole provider needs multicloud; hardware you must own needs on-premises.

Cloud deployment models: public, private, hybrid and community.

A community cloud serves a specific group of organizations that share concerns such as security or compliance requirements. The hospitals are separate organizations, which rules out private, and the platform is closed to others, which rules out public. Nothing describes two environments being combined, which rules out hybrid.

1. Count the organizations using the platform: several.
2. Note what they share: the same regulatory requirements.
3. Note who else can use it: no one outside the group.
4. Match a shared, closed platform for a group with common needs to a community cloud.

Exam tip: Several organizations with shared requirements on one closed platform: community cloud.

Public cloud is multi-tenant and provider-controlled; private cloud is dedicated to one organization.

The defining property of a public cloud is that its infrastructure is shared among many customers and run by the provider. That brings economies of scale but means the customer relies on the provider's tenant isolation and has no say over the physical hardware. Exclusive use, hardware control and large up-front spending all describe the private or on-premises side of the comparison.

1. Recall what defines a public cloud: provider-run infrastructure open to many customers.
2. Find the option that follows from that shared design.
3. Check the others: each describes a private or on-premises trait.

Exam tip: Public cloud means shared, multi-tenant infrastructure you do not control.