Cloud Software Development Final Exam Review

0.0(0)
studied byStudied by 0 people
0.0(0)
full-widthCall Kai
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
GameKnowt Play
Card Sorting

1/82

encourage image

There's no tags or description

Looks like no tags are added yet.

Study Analytics
Name
Mastery
Learn
Test
Matching
Spaced

No study sessions yet.

83 Terms

1
New cards

NIST definition of cloud computing

A model for ubiquitous, convenient, on-demand network access to shared configurable resources that can be rapidly provisioned/released with minimal management effort.

2
New cards

Cloud model is composed of what?

Five essential characteristics, three service models, four deployment models.

3
New cards

Cloud infrastructure (big picture)

Hardware + software that enables essential cloud characteristics.

4
New cards

Physical layer

Hardware resources: server, storage, network components.

5
New cards

Abstraction layer

Software across physical layer that manifests essential characteristics.

6
New cards

5 design principles in review

Scalability; high availability/fault tolerance; cost optimization; automation/DevOps; serverless.

7
New cards

AWS (per notes)

Largest/most widely adopted; wide range of services (compute/storage/databases/ML/analytics).

8
New cards

Azure (per notes)

Strong Windows Server/Active Directory integration; popular for hybrid solutions.

9
New cards

Google Cloud (per notes)

Strong AI/ML + data analytics/big data focus.

10
New cards

Virtualization (definition)

Abstracts hardware resources to create VMs so multiple OSs run on one server.

11
New cards

Hypervisor role

Manages resource allocation between hardware and VMs.

12
New cards

Containers (definition)

Package apps to run consistently across environments; app is abstracted from environment.

13
New cards

VMs vs containers: overhead

VMs higher overhead (full OS per VM); containers share host OS/kernel.

14
New cards

VMs vs containers: isolation

VMs more isolation; containers less (shared kernel).

15
New cards

VMs vs containers: compatibility

VMs can run any OS; containers must match host OS + runtime.

16
New cards

Docker (what it is)

Tool to run apps in containers; packages app + dependencies into standardized unit.

17
New cards

Docker benefits

Portability; scalability; isolation.

18
New cards

Docker drawbacks

Learning curve; performance overhead.

19
New cards

Container characteristics

Self-contained; isolated; independent; portable.

20
New cards

Container vs image

Container is runnable instance of an image.

21
New cards

Image definition

Package with files/binaries/libs/configs needed to run a container.

22
New cards

Image immutability

Once created, can't modify; rebuild or add layers.

23
New cards

Image layers

Each layer is a set of filesystem changes.

24
New cards

Dockerfile steps

Base image (FROM), install deps, copy source, configure final image.

25
New cards

FROM scratch

Creates minimal images.

26
New cards

OCI purpose

Open standards for container formats and runtimes.

27
New cards

OCI specs

runtime-spec; image-spec; distribution-spec.

28
New cards

Registry vs repository

Registry stores/manages images; repository is a collection of related images inside a registry.

29
New cards

Monolithic architecture

Tightly coupled processes running as a single service.

30
New cards

Monolith scaling issue

If one process spikes, entire architecture must scale.

31
New cards

Microservices architecture

App built as independent services/components.

32
New cards

Microservices communication

Well-defined interfaces using lightweight APIs.

33
New cards

REST meaning

Representational State Transfer; architecture style for web services.

34
New cards

SOAP vs REST (what they are)

SOAP protocol; REST architecture style.

35
New cards

SOAP vs REST (operation vs data)

SOAP exposes operations; REST exposes data.

36
New cards

SOAP vs REST (formats)

SOAP XML only; REST supports XML/JSON/plain text/HTML.

37
New cards

SOAP vs REST (state/scaling)

SOAP stateful, hard to scale; REST stateless, easy to scale.

38
New cards

CRUD stands for

Create, Retrieve, Update, Delete.

39
New cards

HTTP method mapping (per slides)

GET=Retrieve; POST=Update; PUT=Create; DELETE=Delete.

40
New cards

PUT to create when?

Only when client controls part of URI (client can assign URIs).

41
New cards

Postman (purpose)

Tool to build/test/modify APIs; supports many HTTP methods and environments.

42
New cards

Orchestration process steps

Write config; scheduler chooses host; monitor/manage lifecycle + auto-heal.

43
New cards

Kubernetes control plane

Manages nodes; exposes APIs to deploy/manage containers' lifecycles.

44
New cards

Kubernetes node definition

Worker machine (VM/physical) that runs pods and provides CPU/memory.

45
New cards

Node components

Kubelet; container runtime; kube-proxy.

46
New cards

Kubelet role

Ensures pods run properly + communicates with control plane.

47
New cards

kube-proxy role

Manages networking rules within node and across cluster.

48
New cards

Pod definition

Smallest deployable unit; 1+ closely coupled containers.

49
New cards

Pod provides

Shared storage (volumes), IP, container communication, run info.

50
New cards

Pod vs node vs cluster

Pod=smallest unit; node=runs pods; cluster=nodes + control plane.

51
New cards

Ingress purpose

Exposes HTTP/HTTPS routes from outside cluster to inside services.

52
New cards

Rancher purpose

Manages Kubernetes; centralizes authentication and RBAC.

53
New cards

Serverless definition

Run code without provisioning/managing servers; CSP manages servers.

54
New cards

Serverless billing + idle cost

Pay per execution; idle cost zero (scales to zero).

55
New cards

When serverless is beneficial

Event-driven, highly variable workloads; instant scaling needs.

56
New cards

Favor serverless criteria examples

Stateless tasks; rapid prototyping; dynamic traffic.

57
New cards

Favor containers/VMs criteria examples

Long-running processes; OS-level customization; in-memory caching needs.

58
New cards

Function-oriented pattern

High-frequency stateless requests; scales independently.

59
New cards

Event-driven pattern

Decouples services using topics/queues for integration.

60
New cards

BFF pattern

Tailors APIs to specific clients (mobile/web variations).

61
New cards

Saga pattern

Long workflows; orchestration with compensation.

62
New cards

Queue-based load leveling

Absorbs spikes; processes at consistent pace.

63
New cards

Strangle pattern

Gradually replace legacy without full rewrite.

64
New cards

Monitoring definition

Continuous inspection for bottlenecks/errors/downtime.

65
New cards

Logging definition

Record events/activities for debugging and behavior analysis.

66
New cards

Common container logging

Write to stdout/stderr.

67
New cards

Why native logging can fail

Crashes/evictions/node death can make logs hard to access.

68
New cards

Cluster-level logging approaches

Node-level agent; sidecar; push logs to backend.

69
New cards

OpenMetrics

Metrics wire format; metrics are snapshots (not logs/events).

70
New cards

DevOps definition

Collaboration + automation between dev and ops to streamline delivery.

71
New cards

CI principles

Frequent commits; automated builds; automated testing; immediate feedback.

72
New cards

CD principles

Automated deployment; continuous testing; incremental changes; rollback.

73
New cards

DevSecOps definition

Security testing integrated across SDLC; shared responsibility dev/sec/ops.

74
New cards

Shared responsibility model

Provider secures infrastructure; customer secures apps/data/user access.

75
New cards

IAM definition

Controls user validation and resource access; "new perimeter" in cloud security.

76
New cards

User provisioning

Create digital identity + access privileges; ideally automated by rules.

77
New cards

RBAC vs ABAC vs PBAC

Roles vs attributes vs granular policy with user+context attributes.

78
New cards

Authentication vs authorization

Who you are vs what you can access.

79
New cards

OIDC vs OAuth (per slides)

OIDC for authentication; OAuth 2.0 framework for authorization.

80
New cards

Identity federation

IdP authenticates; RP manages authorization; consolidates user mgmt.

81
New cards

SAML

XML assertions between IdP and RP (authn/attributes/authz).

82
New cards

IDaaS

API mediating auth flow; CIAM/workforce/B2B IAM classes.

83
New cards

CAS

SSO protocol only for authentication; authorization handled separately.