AP Subject A #10 — Cloud, Virtualization, and Distributed Processing

0. Exam basis

• Target: 2026 Applied Information Technology Engineer Examination (AP), Subject A
• Syllabus: IPA AP (Level 3) Syllabus Ver.7.2
• Revised: 2026-10-21
• Source checked: 2026-10-21

1. Disclaimer

• This is an unofficial study note. It is not affiliated with, reviewed by, or endorsed by IPA (Information-technology Promotion Agency, Japan).
• Exam scope, format, and syllabus may change. Always confirm the latest official IPA announcements before the exam.
• All 5 questions in this installment are original. No past exam questions are used, quoted, or adapted.
• Vendor product names and mutable service specifications are intentionally excluded. Every numeric example holds only under its stated assumptions.

2. Learning index

1. Exam basis
2. Disclaimer
3. Official syllabus mapping
4. Terminology table
5. VM vs container
6. IaaS/PaaS/SaaS shared responsibility
7. Scale-up vs scale-out
8. Load balancing vs distributed processing
9. Failure conditions and traps
10. Worked examples A–D
11. Cross-references (AP8/AP9)
12. Quick sheet
13. Common traps
14. Practice questions
15. Answers and explanations
16. Self-check
17. 1/3/7-day review plan
18. Sources

3. Official syllabus mapping (Ver.7.2)

Syllabus location	Item	Covered in this installment
Major 2 Computer Systems / Middle 4 System Components / 1.(1)②	Distributed processing systems (distributed architecture, function allocation, horizontal function distribution, horizontal load distribution, vertical function distribution)	§8, §9, Example D
Major 2 / Middle 4 / 1.(2)	System configuration (cluster, load sharing, shared-everything, shared-nothing, tight/loose coupling, virtualization: host/hypervisor/container, VM, cloud computing, SaaS, PaaS, IaaS)	§5, §6, §8
Major 2 / Middle 4 / 2.(1)②	Capacity planning (load, sizing, scale-out, scale-up, provisioning)	§7, Example A
Major 2 / Middle 5 Software / 2.(3)①	OSS for virtualization/cloud	§5 (concepts only; no product specifications)
Major 3 Technology / Information security management	Cloud service shared responsibility model, account and access-right management	§6
Major 7 / Middle 17 System Strategy / (2)①	Cloud services (SaaS, PaaS, IaaS, on-demand, cloud native)	§6

4. Terminology table

Korean	Japanese	English
가상 머신	仮想マシン（VM）	virtual machine (VM)
하이퍼바이저	ハイパーバイザー	hypervisor
게스트 OS	ゲストOS	guest OS
컨테이너	コンテナ	container
호스트 커널	ホストカーネル	host kernel
책임 공유 모델	責任共有モデル	shared responsibility model
스케일업	スケールアップ	scale-up
스케일아웃	スケールアウト	scale-out
로드밸런서	ロードバランサ（負荷分散装置）	load balancer
헬스 체크	ヘルスチェック	health check
단일 장애점	単一障害点（SPOF）	single point of failure (SPOF)
스티키 세션	スティッキーセッション	sticky session
멱등성	冪等性	idempotency
멱등 키	冪等キー	idempotency key
부분 장애	部分障害	partial failure
네트워크 분단	ネットワーク分断	network partition
스트래글러(지연 작업)	ストラグラー（遅延タスク）	straggler
데이터 편중	データの偏り（スキュー）	data skew

5. VM vs container

• VM: A hypervisor provides virtual hardware, and each VM runs its own guest OS (including its own kernel) on top of it.
• Container: Containers share the host OS kernel. The kernel isolates processes and resources (process view, file system, network, CPU/memory limits), and the container image packages the application with its user-space dependencies (libraries, runtime, configuration).
• A container is not a small VM. It has no guest OS kernel of its own, so it depends on the host kernel being compatible.

Aspect	VM	Container
Kernel	One guest kernel per VM	Shared host kernel
Typical startup	Tends to be slower (guest OS boot)	Tends to be faster (process start)
Typical density	Tends to be lower (guest OS overhead per VM)	Tends to be higher
Typical isolation boundary	Tends to be stronger (separate kernels)	Tends to be weaker (shared kernel)

These are typical tendencies, not absolutes; actual results depend on configuration and workload.

6. IaaS/PaaS/SaaS shared responsibility boundary

P = mainly provider, C = mainly customer (user). The on-premises column is shown for reference.

Layer	On-premises	IaaS	PaaS	SaaS
Physical facilities / physical network	C	P	P	P
Virtualization layer	C	P	P	P
Guest OS	C	C	P	P
Middleware / runtime	C	C	P	P
Application	C	C	C	P
Data / identity / access / configuration	C	C	C	C

• Moving IaaS → PaaS → SaaS shifts more layers to the provider.
• In every model, the customer remains responsible for its own data, accounts, access rights, and the settings it controls (for example, sharing settings in SaaS or virtual network/firewall settings in IaaS).
• Warning: this is the standard conceptual model. Exact boundaries vary by provider, product, and contract. Always confirm them in the terms of service and contract.

7. Scale-up vs scale-out

Aspect	Scale-up (vertical)	Scale-out (horizontal)
Method	Add CPU/memory etc. to one machine	Add more machines (nodes)
Advantages	Usually little or no application change; no inter-node coordination	Capacity can grow in steps; losing one node can leave the others running
Limits	Hardware upper limit; cost rises steeply; often needs downtime	Needs load distribution, state sharing, coordination; added overhead
State/coordination	State stays in one place	State must be externalized or shared; coordination needed
Bottlenecks	The single machine itself	Shared DB/storage, load balancer, coordination traffic
Failure domain	The single machine is a SPOF	Smaller per node, but shared components remain SPOFs

Scaling is not the same as high availability (HA). Adding capacity does not by itself remove SPOFs or provide failover.

8. Load balancing vs distributed processing

• Load balancing: Spreads independent requests across equivalent nodes.
  • Round robin: assigns requests to nodes in turn.
  • Least connections: assigns to the node with the fewest active connections.
  • Health check: periodically probes nodes and removes failed ones from the target list.
• Distributed processing: Splits one job across multiple nodes.
  • Task partitioning (split by function/step) and data partitioning (split by data range).
  • Parallelism shortens time only where the parts are independent.
  • Coordination overhead (communication, synchronization, merging results) is added.
  • Partial failure: some nodes fail while others continue, so the job must detect, retry, or reassign the failed parts.

9. Failure conditions and traps

Condition	Why it is a problem
Single load balancer	The LB itself is a SPOF unless it is made redundant
Shared DB/storage	Becomes a bottleneck and SPOF even if app nodes are scaled out
Stale health check	Requests can go to a failed node until the next check detects it
Local session state / sticky session	Sessions are lost when that node fails; sticky routing is not failover
Retrying non-idempotent work	Can duplicate an operation (e.g., double order)
Timeout ambiguity	A timeout does not prove failure; the server may have completed the work
Data skew / stragglers	The slowest part determines total completion time
Network partition	Nodes cannot tell a failed peer from an unreachable one; risk of inconsistency
Duplicate / reordered messages	Receivers need deduplication and ordering control
Consistency / coordination requirements	Coordination adds latency and can limit throughput

Distribution does not automatically improve reliability or speed. More components can mean more failure points and more coordination cost.

10. Worked examples

Example A: Capacity and N+1

Assumptions: sustained load 900 requests/s; each identical application node has verified usable capacity 250 requests/s at the target latency; perfect, even distribution; no LB or shared-backend bottleneck; no capacity degradation or overhead.

• Normal minimum: ⌈900 / 250⌉ = ⌈3.6⌉ = 4 nodes
• To survive loss of any one node: (N − 1) × 250 ≥ 900 → N − 1 ≥ 3.6 → N − 1 ≥ 4 → N ≥ 5
• Check: with 4 nodes, losing one leaves 3 × 250 = 750 < 900 (short by 150). With 5 nodes, losing one leaves 4 × 250 = 1000 ≥ 900.

This arithmetic holds only under these assumptions. Real designs need headroom and measurement (load tests, monitoring), and must also account for LB and shared-backend capacity.

Example B: Sessions and failover

Setup: three web nodes (W1, W2, W3) that look stateless sit behind a load balancer, but sessions are stored only in each node’s memory. Sticky sessions are enabled.

1. User U is pinned to W2 by the sticky session; U’s session exists only in W2’s memory.
2. W2 fails. The LB (after a health check detects it) sends U to W1 or W3.
3. W1/W3 do not have U’s session → U is logged out or loses in-progress state.

Sticky sessions only keep routing to the same node; they do not provide failover. Needed: external/replicated session state (e.g., a redundant session store), or state that can be safely reconstructed (e.g., re-login or re-fetch).

Example C: Retry and idempotency

Setup: a client sends an order (payment-like) request; the client times out waiting for the response. The server may already have committed the order.

• A timeout does not prove failure. The request may have failed, succeeded with the response lost, or still be processing.
• Blind retry can create a duplicate order.
• Countermeasure: the client attaches a unique idempotency key to the request and reuses the same key on retry; the server records processed keys, and for a repeated key it does not process again but returns the first result (deduplication).

Example D: Upper bound of parallelism

Assumptions: 100 independent tasks, each taking exactly 1 second; 5 workers; zero overhead; perfect balance.

• Ideal lower bound: 100 × 1 s ÷ 5 = 20 seconds
• Under these assumptions, actual time is ≥ 20 seconds, because coordination, skew/stragglers, and failures can only add time.

Do not claim a general real-world speedup of exactly 5×. The 20-second figure is a lower bound under the assumptions above.

11. Cross-references

• AP8 (reliability): availability, MTBF/MTTR, and series/parallel availability formulas are covered there; this installment does not repeat them.
• AP9 (OS): process, scheduling, and memory management internals are covered there; this installment mentions the kernel only for the VM/container comparison.

12. Quick sheet

• VM = virtual hardware + guest OS per VM. Container = shared host kernel + process/resource isolation + user-space packaging.
• IaaS → PaaS → SaaS: the provider manages more layers; the customer always keeps data, identity, access, and configuration. Exact boundaries depend on provider, product, and contract.
• Scale-up = bigger machine; scale-out = more machines. Scaling ≠ HA.
• Load balancing = spread independent requests; distributed processing = split one job.
• N+1: (N − 1) × capacity ≥ load. Example A → 5 nodes (only under its assumptions).
• Sticky session ≠ failover. Timeout ≠ failure. Retry needs idempotency.
• Parallel time ≥ total work ÷ workers (with zero overhead and perfect balance as the ideal).

13. Common traps

• “A container is a lightweight VM with its own OS” → wrong; it shares the host kernel.
• “With SaaS, the user has no security responsibility” → wrong; data, accounts, access, and configuration remain the user’s.
• “Scale-out makes the system highly available” → not by itself; LB and shared DB can still be SPOFs.
• “Health checks make failure invisible” → there is a detection delay, and the LB itself needs redundancy.
• “Sticky sessions protect sessions from node failure” → no; they only pin routing.
• “A timeout means the request failed, so just resend” → may cause duplicates.
• “5 workers make it exactly 5× faster” → only an ideal upper bound on speedup.

14. Practice questions (original)

Q1

Which of the following is the most appropriate description of virtual machines (VMs) and containers?

• ア: A container is a lightweight VM that includes its own guest OS kernel, so it can run any OS kernel independently of the host.
• イ: In hypervisor-type virtualization, every VM shares the host OS kernel, so a guest OS is not required.
• ウ: Each VM runs a guest OS on virtual hardware provided by a hypervisor, whereas containers share the host OS kernel, isolate processes and resources, and package the application with its user-space dependencies.
• エ: Because containers share the kernel, they always provide stronger isolation than VMs and are therefore always the better choice for separating tenants.

Q2

Which of the following is the most appropriate description of the shared responsibility model for IaaS, PaaS, and SaaS?

• ア: In IaaS, the provider is generally responsible for patching the guest OS of the virtual machines the user builds.
• イ: In PaaS, the provider generally manages layers up to the OS and runtime, while the user manages the application, data, and access settings; however, the exact boundary must be confirmed in the provider’s terms and contract.
• ウ: In SaaS, the provider manages everything, so the user has no responsibility for data, account management, or access settings.
• エ: Within the same service model, the responsibility boundary is identical for every provider and contract, so checking the contract is unnecessary.

Q3

Under the following assumptions, what is the minimum number of nodes needed so that 900 requests/s can still be served even if any one node fails?

Assumptions: sustained load 900 requests/s; each identical node has verified usable capacity 250 requests/s at the target latency; perfect, even distribution; no LB or shared-backend bottleneck; no capacity degradation or overhead.

• ア: 3
• イ: 4
• ウ: 8
• エ: 5

Q4

Three web nodes sit behind a load balancer. Session information is stored only in each node’s memory, and sticky sessions are enabled. Which statement is most appropriate?

• ア: If a node fails, the sessions stored only in that node’s memory are lost. Sticky sessions only route a user to the same node and do not provide failover, so session state must be externalized or replicated, or be safely reconstructible.
• イ: Sticky sessions copy session data to the other nodes, so no session is lost when a node fails.
• ウ: If the distribution method is changed from round robin to least connections, sessions are automatically moved to a healthy node when a node fails.
• エ: If health checks are configured, the load balancer never sends a request to a failed node, and the load balancer itself never becomes a single point of failure.

Q5

A client sends an order request and times out waiting for the response. The server may already have committed the order. Which statement is most appropriate?

• ア: A timeout proves the server did not process the request, so the client should immediately resend the same request without any identifier.
• イ: Increasing the number of retries without limit guarantees that the order is processed exactly once.
• ウ: Because a timeout does not prove failure, the client attaches an idempotency key to the request, and the server deduplicates requests with the same key and returns the first result, so a retry does not create a duplicate order.
• エ: Distributing order processing across more servers automatically eliminates duplicate and reordered messages, so idempotency is unnecessary.

15. Answers and explanations

Q	Answer
Q1	ウ
Q2	イ
Q3	エ
Q4	ア
Q5	ウ

Q1 — Answer: ウ

• ア: Wrong. A container has no guest OS kernel of its own; it shares the host kernel, so it is not a small VM.
• イ: Wrong. In hypervisor-type virtualization, each VM runs its own guest OS on virtual hardware.
• ウ: Correct. This accurately states the VM (virtual hardware + guest OS) vs container (shared host kernel + isolation + user-space packaging) distinction.
• エ: Wrong. Sharing the kernel typically makes the isolation boundary weaker, not stronger, and “always” is an absolute that does not hold.

Q2 — Answer: イ

• ア: Wrong. In IaaS, the guest OS is generally the user’s responsibility.
• イ: Correct. It matches the standard PaaS boundary and includes the caveat that exact boundaries depend on provider and contract.
• ウ: Wrong. Even in SaaS, the user remains responsible for data, accounts, access rights, and configuration.
• エ: Wrong. Exact boundaries vary by provider, product, and contract.

Q3 — Answer: エ (5)

• ア: Wrong. 3 × 250 = 750 < 900, so 3 nodes cannot handle even normal load.
• イ: Wrong. 4 is the normal minimum (⌈900/250⌉ = 4), but losing one leaves 3 × 250 = 750 < 900.
• ウ: Wrong. 8 (doubling 4) satisfies the requirement but is not the minimum.
• エ: Correct. (N − 1) × 250 ≥ 900 → N ≥ 5. Losing one leaves 4 × 250 = 1000 ≥ 900. Valid only under the stated assumptions.

Q4 — Answer: ア

• ア: Correct. Local in-memory sessions are lost on node failure; sticky sessions do not provide failover.
• イ: Wrong. Sticky sessions only pin routing; they do not copy session data.
• ウ: Wrong. The distribution algorithm decides where new requests go; it does not move session state.
• エ: Wrong. Health checks have a detection delay (stale state), and the load balancer is a SPOF unless made redundant.

Q5 — Answer: ウ

• ア: Wrong. A timeout does not prove failure; resending without an identifier can duplicate the order.
• イ: Wrong. Unlimited retries increase the risk of duplicates and load; they do not guarantee exactly-once processing.
• ウ: Correct. An idempotency key with server-side deduplication makes the retry safe.
• エ: Wrong. Distribution does not eliminate duplicate/reordered messages; it can increase them.

16. Self-check

• I can explain why a container is not a small VM, in one sentence.
• I can fill in the IaaS/PaaS/SaaS responsibility matrix and state the contract caveat.
• I can state the bottleneck and failure-domain difference between scale-up and scale-out, and why scaling ≠ HA.
• I can distinguish load balancing from distributed processing and list three partial-failure issues.
• I can derive N ≥ 5 in Example A and state its assumptions.
• I can explain why sticky sessions are not failover.
• I can explain why a timeout plus blind retry can duplicate an order, and how an idempotency key prevents it.
• I can explain why 20 seconds in Example D is a lower bound.

17. 1/3/7-day review plan

Day	Task
Day 1	Re-read the quick sheet; redraw the responsibility matrix and the scale-up/out table from memory; re-solve Q1–Q5.
Day 3	Re-derive Examples A and D without notes; explain Examples B and C aloud; review the common traps.
Day 7	Re-solve Q1–Q5 and explain why each wrong option is wrong; complete the self-check; revisit AP8/AP9 cross-references briefly.

18. Sources

• IPA, Applied Information Technology Engineer Examination (Level 3) Syllabus Ver.7.2 (official PDF, printed pages 20–21, 32, 56, 107): https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kq5-att/syllabus_ap_ver7_2.pdf (checked 2026-10-21)