Skip to content
academia.sh

Course Advanced

Cloud Governance, Security and Cost

Published Updated

By the end of this course

Start course

01

Cloud Identity

Writing down who can access what: the distinction between user, group, and role identity types, the policy structure built from permission, resource, and condition statements, evaluating identity-based and resource-based policies from both directions, assuming a role with temporary credentials, giving an application an identity, detecting unused permission and narrowing to least privilege, and separating workload and environment through account and organization structure.

  1. 01 Users, Groups, and Roles The needs of five teams on the fictional regional measurement network are built and compared using three identity types: the connection count, excess permission, new-member cost, and permission left behind on departure for permission granted directly to a user, to a group, and to a role.
  2. 02 Policy Structure A policy document evaluator is written and the same intent is expressed four separate ways to count how many actions each phrasing actually covers: the scope a wildcard opens is pulled apart item by item, an explicit deny is shown to always win, and how far a condition narrows the scope is measured.
  3. 03 Identity and Resource-Based Policies The same access request is passed through two separate policy sets and their intersection is computed: how many requests are denied for being allowed in only one direction, why a resource-based policy becomes mandatory once the account boundary is crossed, and how many documents it takes to find out why an access was denied.
  4. 04 Role Assumption Access with temporary credentials is compared against a long-lived key: the leak window, the length of the assumption chain, how the trust relationship determines who can assume it, and how many steps it takes before the true subject disappears from the audit record.
  5. 05 Workload Identities Three ways of giving an application an identity are measured side by side: a long-lived key sitting in a file, a secret in an environment variable, and an identity issued by the runtime. Leak surface, rotation work, and identity scope are counted; how identity is issued at the edge and function layer is worked out separately.
  6. 06 Least Privilege Practice Granted permission is set side by side with used permission: the unused permission ratio, how many lines the narrowed policy runs to, and how much legitimate work narrowing stops are counted. The observation window is scanned and the safe narrowing threshold is given as a number.
  7. 07 Account and Organization Structure The same workload set is set up in three structures — single account, account by environment, account by workload. Blast radius, quota sharing, how the bill splits apart, and management overhead are counted; what the organization-level protection band cuts and cannot cut is measured.

02

Cloud Security

Protecting data and access in the rented layer: encryption at rest with a key management service and customer keys, end-to-end encryption enforced in transit, rotation and access control in secret storage services, audit logs that track API calls, configuration compliance auditing that catches drift automatically, taking resources off the open internet with private endpoints, threat detection through anomalous-activity alerts, and how compliance requirements map onto the cloud.

  1. 01 Encryption at Rest Data at rest is compared across three options: no encryption, provider key, customer key. How many subjects can decrypt, whether key use lands in the audit log, and the overhead the customer key brings are counted with real envelope encryption; on key loss, 3,973 GB across 14 datasets becomes permanently unreadable.
  2. 02 Encryption in Transit What happens when transit encryption is enforced is counted: 9 of 16 connection legs are open, 4 have unknown status. Three-stage enforcement changes 23 configuration items and breaks 79 connections; 34 cannot be upgraded. Only one of six paths becomes proven end to end, and reaching all of them needs encryption in its own layer.
  3. 03 Secret Storage Services The measure of secret rotation is the window: the span where the old and new values are valid together is scanned. A short window misses 44 clients, and the window that misses zero runs 3,624 minutes and leaves an old secret standing for 601,584 minutes a year. Fixing just the 18 clients that read only at startup cuts the window to 227 minutes; 17 of 41 secrets have never been rotated.
  4. 04 Audit Logs A set of events is dropped into the audit log, and how many of four questions it can answer is counted: 273 of 480 events answer all four, 88 in the default configuration. 3 of 8 investigations get answered. 11 subjects can delete the log; moving it to a separate account stops 6 legitimate jobs, and data-plane logging costs 772 times as much as management-plane logging.
  5. 05 Configuration Compliance Auditing Automatic detection of drift: running 6 rules against 22 rented resources, 40 of 46 firing pairs get flagged, 32 of 38 actual noncompliance pairs get caught and 6 are missed, and across three remediation modes the open resource count drops from 16 to 6 while 8 legitimate configurations break and 5 of 6 legitimate changes get blocked.
  6. 06 Network Isolation and Private Endpoints Measuring whether a managed service is reached through the public endpoint or a private one: closing the public endpoint on 25 access records breaks 12 legitimate ones, drops 12 to zero paths, moves the same name from resolving to a private address in 11 places to 14, and closing the gaps costs 12 new private endpoints at 180 fictional units a month.
  7. 07 Threat Detection Measuring anomalous-activity alerts against a known event set: 9 detection rules over 30 events catch 9 of 11 malicious events, produce 13 false alarms, 8 events get caught by only a single signal source, three sources cost 612 fictional units a month, and once the false-alarm threshold is crossed two rules close and caught drops to 7.
  8. 08 Mapping Compliance Requirements to the Cloud Turning compliance requirements into evidence in the rented layer: across 12 requirement types and 26 evidence items, 7 items come from the provider's document and 16 from the tenant's own record, 3 requirements' evidence stays in the gap, 7 of the 14 items sitting outside the tenant's layer have evidence that does not come from the provider, and producing evidence costs 139 fictional units and 160 person-hours a year.

03

Cost and Limits

Reading the bill and planning the ceiling: a cost model made of compute, storage, transfer, and request fees; tagging with ownership-based cost allocation; a budget and alerts that catch unexpected spending early; resource sizing to reduce overprovisioning; quotas and service limits in scale planning; and evaluating vendor lock-in through portability and exit cost.

  1. 01 Cost Model The bill for the rented layer splits into four items: of the monthly 1,542 fictional units, 37.7% is compute, 31.8% is transfer, 20.2% is request, and only 10.3% is storage; the request fee is 1.95 times the storage fee. When the same bill is mapped to eleven design decisions, more than half of the decisions (50.8%) belong to the platform, and four spread across more than one item. In the raw measurement stream, the point where the request fee overtakes storage comes out at 693,370 items/month (11,364 bytes); the network writes 152 bytes per item, sitting 74.8 times past that point, and pays 299.43 units of request fee against 6.48 units of storage.
  2. 02 Tagging and Cost Allocation Ownership information comes from outside the bill, and it does not come in full: in a fictional inventory of 148 resources, visible tag coverage is 77.7% while valid coverage is 75.0%, and 25.1% of the monthly 4,214.3 fictional units stays unallocatable, entering no rule at all. When the shared 1,584.9 units is split across three rules, the same team's bill swings between 8.7% and 18.6%. A tag mandate zeroes the unallocatable share but rejects 37 resources and stalls 14 legitimate jobs worth 511.9 units; even once tags reach 95.9% coverage by month's end, that month's 568.6 units (13.5%) never correct retroactively.
  3. 03 Budget and Alerts Measures when unexpected spending gets noticed: across five rises placed on a fictional spending curve, the threshold alert misses two of them entirely and, by the time it first fires, 86.4% of the monthly budget is already spent (204 units remain); the forecast alert catches all five but stays open on 63 of ninety days. The threshold family's best setting misses 821 units while the forecast family stays at 12.5; the false-alarm gap is 5 versus 6 across 21 event-free days. The bill's delay adds directly to the day noticed: a three-day delay adds 1.8 days to the average delay and 210 units to the missed amount, and an eight-day delay lets one rise go entirely unnoticed.
  4. 04 Resource Sizing Measures the bill side of overprovisioning: across the fictional network's ten resources, average p95 occupancy is 31.4%, and downsizing that leaves a 20% margin over p95 promises 401 of the monthly 875 fictional units (45.8%). 353 units of that savings (88.0%) require a disruption, seven candidates have a past peak that exceeds the new tier, and the worst moment falls 168.4% short; the share that is both non-disruptive and risk-free is only 10 units. Raising the safety margin from 0% to 100% drops savings from 458 to 64 units and short hours from 47 to 3. An idle 147.2 units, invisible in any usage report, is deleted with no disruption and hands over 37% of the downsizing savings on its own.
  5. 05 Quotas and Service Limits The scaling plan is applied to a fictional limit table: eight limits average 66.5% full, six are shared by five teams, and two can never be increased. Once the growth plan runs, the first limit to fill is not the fullest one but the one tied to the fastest driver — name resolution at month 3.1, function concurrency at month 4.3; by month twelve, seven of the eight limits are exceeded. Scanning request growth from 2% to 25% changes the identity of the limit that fills first. The cost of hitting a limit depends on its behavior and increase time: a total of 2,195 fictional units and 116 limit-days, 51.7% of which comes from a single silent-throttling limit.
  6. 06 Vendor Lock-In The twelve rented items split into portability degrees, and it turns out bill weight never measures portability: 48.3% of the monthly bill comes from two items portable through a standard interface, 9.6% from three items that cannot be moved at all. The exit bill is 879 fictional units, 52% of it request fee rather than bytes; yet that is only 9.1% of the move cost, the rest is 257 person-days of work. The three paths to reducing lock-in are measured by prep, move, and capability lost: the lowest break-even point is 48.9%, and one path's break-even is 466% — it does not pay off even if the move is certain.

Final exam

Cloud Governance, Security and Cost — Final Exam

In preparation

This course's question bank is not complete yet. The exam opens here automatically once enough questions are added.

Start typing to search.

↑↓ ↵ Esc navigate · open · close