Merge branch 'main' of https://git.baldy.ga/Rijn/DVA-01-Notes

.agents/tasks/dva-notes-review.md

@@ -0,0 +1,276 @@
+# DVA-C02 Notes Review: Findings Report
+
+Scope: all 33 markdown files in `c:\src\repos\DVA-02-Notes` (read-only review; nothing modified). Images checked: `ACM/terminating_diagram_at_alb.png`, `ACM/terminating_ssl_e2e.png`, `Route 53/route_53_routing_example.png` all exist.
+
+Severity key: **high** = factually wrong, **medium** = misleading/incomplete (likely to cost exam points), **low** = typo/formatting.
+
+## Summary answer
+
+Yes, there are several real errors. The most important ones:
+
+1. **VPC is "Virtual Private Cloud", not "Virtual Private Connection"** (`VPC/_VPC.md`), and the description actually describes VPC peering / VPN, not a VPC.
+2. **ACM pricing is wrong** (`ACM/_ACM.md`): imported certificates are not $400/month. ACM public and imported certs are free; the $400/month is AWS Private CA (per private CA). "Public vs Private" is also conflated with "ACM-issued vs imported".
+3. **Elastic Beanstalk deployment policies are described incorrectly** (`_Concepts/Deployments.md`): All-at-once doesn't recreate instances; Immutable and Traffic Splitting use a temporary ASG behind the *same* load balancer (not a new ELB); the policy is "Traffic splitting", not "Traffic Shifting"; Blue/Green swaps environment CNAMEs.
+4. **CodeDeploy blue/green does not support on-premises instances** (`_Concepts/Deployments.md` says "EC2 / On-Prem, Lambda & ECS").
+5. **Route 53 is not a CloudFront origin** (`CloudFront/_CloudFront.md`).
+6. **AppSync auth list is incomplete**: missing OpenID Connect and AWS Lambda authorizers (5 modes, a common exam question).
+7. **Outdated info**: CodeCommit is back to GA (since 24 Nov 2025), X-Ray SDKs/Daemon entered maintenance mode on 25 Feb 2026 (OpenTelemetry recommended), CloudFront Functions are no longer "only ES 5.1", OAI is "legacy" rather than "not available".
+8. **REST is not "a kind of CRUD"** (`_Concepts/Glossary/REST.md`). This contradicts `CRUD vs REST.md`.
+9. **About 15 broken wiki-links**, including CodePipeline's "Build" stage linking to CodePipeline itself instead of CodeBuild.
+
+---
+
+## Evidence, by file
+
+### `_Concepts/Deployments.md`
+
+| # | Snippet | Problem | Correct info | Sev |
+|---|---|---|---|---|
+| D1 | `[[_Elastic BeanStalk\|_Elastic BeanStalk]]` (line 4) | Broken link; no Elastic Beanstalk note exists. | Create `_Elastic BeanStalk.md` or remove the link. | low |
+| D2 | CodeDeploy In-place: "Stops apps on _every_ instance" | Misleading. Instances are taken down according to the deployment configuration (`CodeDeployDefault.OneAtATime`, `HalfAtATime`, `AllAtOnce`, or custom minimum healthy hosts), not all at once. | Note the deployment configs and minimum healthy hosts. | medium |
+| D3 | CodeDeploy Blue/Green scope: "EC2 / On-Prem, Lambda & ECS" | **Wrong**: AWS says EC2/On-Premises blue/green "work with Amazon EC2 instances only" ([CodeDeploy docs](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create.html)). | Scope: EC2 (not on-prem), Lambda, ECS. | high |
+| D4 | CodeDeploy Blue/Green description ("Make a new set of instances…") | Only true for EC2. For Lambda and ECS, blue/green means **traffic shifting** between versions/task sets using Canary, Linear, or AllAtOnce configs (e.g. `LambdaCanary10Percent5Minutes`, `ECSLinear10PercentEvery1Minutes`). This is heavily tested. | Add a Lambda/ECS row with canary/linear/all-at-once. | medium |
+| D5 | EB All at Once: "Recreates the instances and boots them again" | **Wrong**. All-at-once deploys the new version to the *existing* instances simultaneously; no new instances are created. | "Deploys to all existing instances at once; short downtime; fastest; no extra cost." | high |
+| D6 | EB Rolling with Additional Batches: "switch out the old instances over time until one is left, which you discard" | Misleading. EB launches one extra batch first so full capacity is kept, then deploys in batches to existing instances. At the end the extra batch's worth of instances is terminated. Impact should read "full capacity maintained, small extra cost". | See [EB deployment policies](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html). | medium |
+| D7 | EB Immutable: "spin up an entire extra Auto Scailing Group, then once ready, point the ELB to the new ASG. The safest… because the old instances remain." | EB creates a **temporary ASG behind the same load balancer**. Old and new serve together, then new instances move to the original ASG and old instances are **terminated**. It's "safest" because rollback is just terminating the new instances. Typo "Scailing". | See [Immutable updates](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environmentmgmt-updates-immutable.html). | medium |
+| D8 | EB Blue/Green: "You spin up an entire extra ELB, then switch out the URLs." | Blue/green in EB means cloning a whole separate **environment** (its own ASG, LB, etc.) and doing **Swap Environment URLs** (a CNAME swap). It isn't a built-in deployment policy. | "New environment, then swap CNAMEs; Route 53 weighted records also possible." | medium |
+| D9 | EB "Traffic Shifting": "spin up and extra ELB, the split the traffic" | **Wrong name and mechanism**. The policy is **Traffic splitting** (canary). It launches new instances in a temporary ASG behind the **same** load balancer and sends a set percentage of traffic to them for an evaluation period. Typos "and extra", "the split". | See [AWS What's New, 2020](https://aws.amazon.com/about-aws/whats-new/2020/05/aws-elastic-beanstalk-traffic-splitting-deployment-policy/) and the EB docs above. | high |
+| D10 | "the reregistered", "replace and existing instance" | Typos ("then re-registered", "replace the existing instances"). | | low |
+| D11 | Five empty rows and a dotted row at the end of the table | Formatting leftovers. | Remove them. | low |
+
+### `_Concepts/CRUD vs REST.md`
+- Content is fine. Note that `REST.md` contradicts it (see below). **(medium, inconsistency)**
+
+### `_Concepts/Glossary/REST.md`
+- "A kind of [[CRUD]]": **wrong**. REST is an architectural style (stateless, resource-based, uniform interface). HTTP methods often *map* to CRUD (POST→Create, GET→Read, PUT/PATCH→Update, DELETE→Delete), but REST isn't a kind of CRUD. This contradicts `CRUD vs REST.md`, which is correct. **(medium)**
+
+### `_Concepts/Glossary/HTTPS.md`
+- "a layer of encryption, either on the Application on IP layer": **wrong**. HTTPS is HTTP over **TLS** (sits between the application and transport/TCP layers). IP-layer encryption is IPsec, which isn't HTTPS. Also "on" should be "or". Default port 443 (HTTP is 80) is worth adding. **(medium)**
+
+### `_Concepts/Glossary/HTTP.md`
+- "Web browser protocol": oversimplified. HTTP is an application-layer request/response protocol used by browsers and also by APIs (REST, GraphQL, AWS APIs). **(low)**
+
+### `_Concepts/Glossary/VPN.md`
+- "Secures connections between two networks": incomplete. A VPN can also connect a single client to a network (client VPN versus site-to-site). **(low)**
+
+### `_Concepts/Glossary/API.md`, `AWS.md`, `CRUD.md`, `SQL.md`
+- No errors. `AWS.md` heading `# [[AWS]]` links to itself (harmless). **(low)**
+
+### `README.md`
+- No issues.
+
+### `ACM/_ACM.md`
+
+| # | Snippet | Problem | Correct info | Sev |
+|---|---|---|---|---|
+| A1 | `# Amazon Certificate Manager` | The service is **AWS** Certificate Manager. | | low |
+| A2 | "1. Public - Certificates provided by ACM (Free) 2. Privates - Certificates you import ($400 / month)" | **Wrong**. Two separate ideas are mixed up. (a) ACM-issued public certs used with integrated services are free. (b) **Imported** certs are also free to manage in ACM. (c) **Private** certs come from **AWS Private CA**, which costs about $400/month per CA (general-purpose mode) plus per-cert fees. ACM docs: no additional charge for certificates you manage with ACM ([ACM user guide](https://docs.aws.amazon.com/acm/latest/userguide/)). | Re-split into: Public (ACM-issued, free) / Imported (free) / Private (via AWS Private CA, paid). | high |
+| A3 | "public and private SSL/TLS certificate" | "certificates" (plural). | | low |
+| A4 | Attachable resources list | Missing the exam-relevant constraint: **for CloudFront, the ACM cert must be in `us-east-1`**. For ALB/NLB/API Gateway regional endpoints, the cert must be in the same Region. Also "ELB" should say ALB/NLB (CLB too). Note that ACM-issued certs can't be installed directly on EC2 (except by export, see A6). | Add the Region rule. | medium |
+| A5 | `[[ELB]]` (twice), `[[API Gateway]]`, `[[_Elastic BeanStalk\|…]]` | Broken links. The files are `_ELB.md` and `_API Gateway.md`. No Beanstalk note exists. | `[[_ELB\|ELB]]`, `[[_API Gateway\|API Gateway]]`. | low |
+| A6 | E2E: "You can't do this with ACM by itself. You can set up Let's Encrypt for it." | Partly outdated. ACM now supports **exportable public certificates** (paid) that can be installed on your own servers ([ACM public certs doc](https://docs.aws.amazon.com/acm/latest/userguide/acm-public-certificates.html)). Also, ALB doesn't validate target certificates, so a self-signed cert on the instance is enough for ALB→EC2 encryption. | Mention both options. | medium |
+| A7 | "Terminating SSL at Load Balancer… beyond the ALB is unencrypted" | Fine, but worth noting that NLB can also do TLS passthrough (TCP listener) for true end-to-end. | | low |
+| A8 | "on each instances" | "each instance". | | low |
+
+### `ALB/_ALB.md`, `NLB/_NLB.md`, `S3/_S3.md`
+- Placeholders with no content, so nothing is wrong. These are core DVA-C02 topics (S3 especially) and are gaps. **(medium, coverage gap)**
+
+### `ELB/_ELB.md`
+- Lists only ALB and NLB. ELB also includes the **Gateway Load Balancer** and the legacy **Classic Load Balancer**. **(low)**
+
+### `API Gateway/_API Gateway.md`
+- REST / HTTP / WebSocket flavours are correct.
+- `[[REST]]` and `[[HTTP]]` link to glossary terms, not to the API Gateway API types, which could mislead. **(low)**
+- Placeholder: missing stages, integration types, caching (TTL default 300s), throttling (10,000 rps / 5,000 burst account default), usage plans/API keys, authorizers. **(medium, coverage gap)**
+
+### `AppSync/_AppSync.md`
+
+| # | Snippet | Problem | Correct info | Sev |
+|---|---|---|---|---|
+| P1 | `# Authorisation`: API Key, AWS IAM, Cognito User Pools | **Incomplete**. AppSync has five auth types: API key, **AWS Lambda**, IAM, **OpenID Connect**, Cognito User Pools ([AppSync docs](https://docs.amazonaws.cn/en_us/appsync/latest/devguide/security-authz.html)). Several can be combined (multiple auth modes). Heading level `#` is inconsistent with the other `##` sections. | Add OIDC and Lambda. | high |
+| P2 | "Full request caching: Self explanatory; caches all requests." | Oversimplified. AWS describes it as caching each resolver's result separately for all resolvers invoked during a request, keyed by request context ([AppSync caching](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html), [API ref](https://docs.aws.amazon.com/appsync/latest/APIReference/API_ApiCache.html)). | | medium |
+| P3 | "Caching isn't serverless; you must provision an on-demand instance." | "On-demand" is misleading. You choose a cache **instance type** (dedicated, ElastiCache-backed) that's billed hourly while it exists. | | low |
+| P4 | "Resolvers… used to implement the state-changing operations" | Resolvers fulfil **all** operations, reads (queries) included. Also missing: unit vs **pipeline** resolvers. | | medium |
+| P5 | API Types: GraphQL APIs, Merged APIs | Missing **AppSync Event APIs** (WebSocket pub/sub, launched in 2024) ([Event API docs](https://docs.aws.amazon.com/appsync/latest/eventapi/configure-event-api-auth.html)). "a collection of Graph APIs" should be "source GraphQL APIs". | | low |
+| P6 | Data sources | Fine. Could add the "None" data source (local resolvers). The RDS entry is really Aurora via the RDS Data API. | | low |
+| P7 | "Resolvers attached to specific fields" | Grammar: "are attached"; "used" should be capitalised. | | low |
+
+### `AppSync/GraphQL.md`
+- "GraphQL is an FOSS agnostic query adaptor": imprecise. GraphQL is an open-source **query language and runtime specification** for APIs. "adaptor" is the wrong word. **(low)**
+- "composed on" should be "composed of". "Allow for data to be create" should be "created". **(low)**
+- The **Fields** bullet is empty. **(low)**
+- The examples don't match: the schema defines `Query { me: User }` and `User { id, name }`, but the query uses `currentUser { name age }`. `age` isn't on `User` and `currentUser` isn't a Query field. `createUser` and `newPerson` aren't defined either. This would fail validation. **(low/medium)**
+- Missing: GraphQL APIs typically use one endpoint with POST. **(low)**
+
+### `Athena/_Athena.md`
+- The analogy suggests the **catalog** decides which "boxes" to open. Data skipping actually comes from **partitioning** (partition pruning) and **columnar formats** (Parquet/ORC) with compression. The Glue Data Catalog stores schema and location. **(medium)**
+- "query any book in any format (CSV, JSON, Parquet)": overstated. Athena supports specific SerDes/formats (CSV/TSV, JSON, Parquet, ORC, Avro, Ion, logs, etc.), not *any* format. **(low)**
+- "never alters the original books": mostly true for standard tables, but Athena can write results/CTAS/`INSERT INTO`, and with **Apache Iceberg** tables it supports `UPDATE`/`DELETE`/`MERGE`. **(low)**
+- Missing exam facts: serverless (Trino/Presto engine), priced per TB scanned, query results written to S3, workgroups for cost control. **(medium, coverage gap)**
+- Typo: "a box contains fictions" should be "fiction". **(low)**
+
+### `CloudFront/_CloudFront.md`
+
+| # | Snippet | Problem | Correct info | Sev |
+|---|---|---|---|---|
+| C1 | "**Origin**… Examples include: S3, EC2, ELB, Route53." | **Wrong**. Route 53 is DNS and can't be an origin. | Origins: S3, ALB/ELB, EC2, API Gateway, Lambda function URLs, MediaStore/MediaPackage, any custom HTTP server. | high |
+| C2 | Origin Request row use cases "Add security headers (CSP/HSTS), set cookies…, customise error messages" vs. Origin Response row "Rewrite URLs…, inject headers for origin authentication…" | The use cases look **swapped**. URL rewrites, adding origin-auth headers, and picking the origin by user agent are **origin request** tasks. Adding security headers and customising error responses are **response** tasks. | | medium |
+| C3 | Origin Response description: "After CloudFront receives the request from the origin." | Should say "receives the **response** from the origin". | | low |
+| C4 | "Max Memory… L@E 128MB-3,008MB" | Unclear: **viewer** triggers are fixed at 128 MB, and higher memory applies only to origin triggers. The exact current upper bound (3,008 MB versus Lambda's 10,240 MB) is **unverified**; the AWS doc page couldn't be fetched (TLS error) and third-party sources disagree. | Write "128 MB (viewer) / up to Lambda max (origin)" and check against [AWS comparison page](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-functions-choosing.html). | low |
+| C5 | "Lambda@Edge… JavaScript" / CF Functions "Only supports ECMAScript 5.1" | Outdated. CloudFront Functions runtime 2.0 is ES 5.1 compliant **plus some ES6–ES12 features** ([AWS docs](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/functions-javascript-runtime-20.html)). Runtime 2.0 is also needed for CloudFront KeyValueStore. | | medium |
+| C6 | `CloudFront will failover on: GET, HEAD, and OPTION` | Typo: `OPTIONS`. The status codes (400, 403, 404, 416, 500, 502, 503, 504) are correct. Failover also happens on connection failures/timeouts. | | low |
+| C7 | "OAI… Lots of drawbacks. Not available anymore." | Overstated. OAI is **legacy** and AWS recommends OAC, but OAI still works on existing distributions ([AWS re:Post KC](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-serve-static-website/)). Name the drawbacks: no SSE-KMS, no S3 Regions launched after Dec 2022, limited PUT/POST support. | | medium |
+| C8 | "can stream Videos On Demand using [[ISS Microsoft Smooth Streaming]]" | Typo "ISS" should be "IIS". Smooth Streaming is legacy. CloudFront more commonly serves HLS/DASH (e.g. with MediaPackage). | | low |
+| C9 | "Regional Caches: Compute located in board geographical locations" | "broad". They're larger caches that sit between edge locations and the origin; calling them "compute" is odd. Edge locations are points of presence/caches, not general compute. | | low |
+| C10 | "Distribution: A collection of Edge locations and Regional Cache…" | A distribution is a **configuration** (origins, cache behaviours, policies, certs, domain names) that tells CloudFront where to fetch content and how to cache/deliver it. It isn't a set of locations (the price class chooses which locations are used). | | medium |
+| C11 | "Origin Request always returns:" | Should be "always includes". The list (URL path, body, Host, User-Agent, X-Amz-Cf-Id) is fine. | | low |
+| C12 | "⚠️ If you are dealing with CORS, you will be setting things here, as this will mess with them." | Unclear. Suggest: "CORS response headers (Access-Control-Allow-*) can be set via a response headers policy (AWS has managed CORS policies). To *forward* the `Origin` header to the origin, use an origin request policy." | | low |
+| C13 | "charged pre request" | "per request". | | low |
+| C14 | `[[AWS WAF]]`, `[[Videos On Demand]]`, `[[ISS Microsoft Smooth Streaming]]` | Broken links (no such notes). | | low |
+| C15 | Managed cache policies list | Correct but incomplete. Also `UseOriginCacheControlHeaders` and `UseOriginCacheControlHeaders-QueryStrings`. | | low |
+
+### `CloudFront/CloudFront Functions.md`
+- "Only supports ECMAScript 5.1": outdated (see C5). **(medium)**
+- "They live directly at Edge Locations": correct.
+
+### `CloudFront/Lambda@Edge.md`
+- Python and Node.js: correct. "deployed at Regional Edge Caches": correct.
+- Missing exam-relevant facts: functions must be **authored in `us-east-1`** and replicated, you must reference a **numbered version** (not `$LATEST` or an alias), and there are no environment variables. **(medium, gap)**
+
+### `CodeBuild/_CodeBuild.md`
+- "build tools such as Apache, Maven, Gradle": it's **Apache Maven** (one tool), not "Apache" and "Maven". **(low)**
+- Workflow step 3 says `buildspec.yaml`, but the section header says `buildspec.yml`. The default filename is **`buildspec.yml`**. **(medium, inconsistency)**
+- Step 4 "Push into a bucket, or any other AWS SDK action (I think?)": artifacts go to **S3**. Docker images are pushed to ECR by commands you write (usually in `post_build`). Also covers reports and cache. **(medium)**
+- Build environments: "If you need specific software, you need to make an image and upload it to ECR and reference it in the pipeline". Not required: you can install software in the `install` phase (`runtime-versions`, package managers). Custom images can come from ECR **or Docker Hub/other registries** and are set on the **build project**, not the pipeline. **(medium)**
+- Triggers: also webhooks (GitHub, Bitbucket, GitLab) and EventBridge schedules. **(low)**
+- "Scaled automatically": should be "Scales". **(low)**
+- Missing: `env` (variables, `parameter-store`, `secrets-manager`), `artifacts`, `cache`, `reports` sections, `finally` blocks, VPC config, logs to CloudWatch/S3, default timeout. **(low, gap)**
+
+### `CodeCommit/_CodeCommit.md`
+- No mention of service status. AWS closed CodeCommit to new customers on 25 Jul 2024, then **returned it to full GA on 24 Nov 2025** ([AWS DevOps blog](https://aws.amazon.com/blogs/devops/aws-codecommit-returns-to-general-availability), [InfoQ](https://infoq.com/news/2025/12/aws-codecommit-ga)). Worth noting because study materials from 2024–25 call it deprecated. **(medium)**
+- "HIPPA" should be "HIPAA". **(low)**
+- "No limit on the size of your repositories": matches AWS marketing. Note that Git LFS wasn't supported historically (on the roadmap per InfoQ). **(low)**
+- Missing exam-relevant auth options: HTTPS Git credentials, SSH keys, `git-remote-codecommit` (GRC), and triggers/notifications (SNS/Lambda/EventBridge). **(low, gap)**
+
+### `CodeDeploy/_CodeDeploy.md`
+- Blue/Green section describes only EC2 (instances and ELB). It's missing (a) **EC2 only; on-premises can't use blue/green** ([docs](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create.html)), and (b) Lambda/ECS blue/green via Canary/Linear/AllAtOnce traffic shifting. **(medium)**
+- Deployment Groups: "A set of EC2 instances or Lambda Functions". For EC2/on-prem it's instances chosen by **tags** and/or **ASGs**; for ECS it's an ECS service plus load balancer; for Lambda, the group holds the deployment config/alarms. **(low)**
+- Application: "revision deployment configuration, and group" is missing a comma ("revision, deployment configuration, and deployment group"). **(low)**
+- Missing exam staples: the **CodeDeploy agent** (EC2/on-prem), `appspec.yml` location (root of revision) and **lifecycle hooks** (`ApplicationStop`, `BeforeInstall`, `AfterInstall`, `ApplicationStart`, `ValidateService`; Lambda: `BeforeAllowTraffic`/`AfterAllowTraffic`), and rollback on CloudWatch alarms. **(medium, gap)**
+- Consistent with `Deployments.md` on in-place being EC2/On-Prem only (correct).
+
+### `CodePipeline/_CodePipeline.md`
+- `[[_CodePipeline|Build]]`: the "Build" stage links to **CodePipeline**. It should be `[[_CodeBuild|Build]]`. **(low but misleading)**
+- `[[CodeDeploy||Deploy]]` has a double pipe and the wrong target. It should be `[[_CodeDeploy|Deploy]]`. **(low)**
+- `[[_CloudFormation|CloudFormation]]`: broken link (no note). **(low)**
+- "Actions are not restricted to specific stages": **wrong for Source actions**. Source actions can only be in the **first stage**, and the first stage can only contain source actions. Every pipeline needs at least 2 stages. **(medium)**
+- "Action Groups group several Actions": I couldn't confirm "action group" as an official CodePipeline concept. Actions in a stage run in series/parallel by `runOrder`. **(unverified)**
+- "invoke a CloudFormation template": better put as "create/update a CloudFormation stack or change set". **(low)**
+- Typos: "The can pull" should be "They can"; "Deploy Actions is a Build Stage" should be "in a Build Stage"; "Pipeline are only limited" should be "Pipelines are". **(low)**
+
+### `Lambda/_Lambda.md`
+- "A Docker container or a runner that runs code for you": misleading. Lambda runs functions in **Firecracker microVMs**. Container images are one *packaging* option (zip is the other), but Lambda isn't a Docker container. **(medium)**
+- `[[API Gateway|API Gateway]]` is broken (file is `_API Gateway.md`). `[[_DynamoDB|DynamoDB]]` is broken (no note). **(low)**
+- Placeholder: missing limits (15 min timeout, 128 MB–10,240 MB memory, /tmp up to 10 GB, 1,000 default concurrency, 50 MB zipped / 250 MB unzipped deployment, 6 MB sync payload), versions/aliases, layers, invocation types, DLQ/destinations. **(medium, coverage gap)**
+
+### `Route 53/_Route53.md`
+- "A DNS with AWS Services": Route 53 is a managed DNS **service** (registrar, authoritative DNS, health checks). **(low)**
+- "Resolve VPC's outside of AWS": misleading. **Route 53 Resolver** inbound/outbound endpoints let on-premises networks resolve private VPC DNS names (and the reverse), which is hybrid DNS. **(medium)**
+- Missing: routing policies (simple, weighted, latency, failover, geolocation, geoproximity, multivalue, IP-based) and alias vs CNAME (alias works at the zone apex and is free for AWS targets). These are exam staples. **(medium, gap)**
+
+### `Route 53/Record Sets.md`
+- "Record sets are a collection of records which determine where to send traffic": a record set is the set of records with the **same name and type** (e.g. multiple A values). **(low)**
+- "They are always changed in batch via the API": `ChangeResourceRecordSets` takes a change batch, which is roughly correct. **(low)**
+
+### `Route 53/Route 53 Hosted Zone.md`
+- Correct overall. Private hosted zones can be associated with **one or more** VPCs. "Revisit this." is a leftover TODO. **(low)**
+
+### `Route 53/Use Cases.md`
+- "our web backed by ALB" should be "our web app backed by ALB". The image exists. **(low)**
+
+### `VPC/_VPC.md`
+- "Virtual Private Connection": **wrong**. VPC is **Virtual Private Cloud**, a logically isolated virtual network in an AWS Region (CIDR, subnets, route tables, IGW/NAT, security groups/NACLs). **(high)**
+- The description ("a private link between 2 places… connect 2 AWS accounts… a VPN between two places") describes **VPC peering**, **PrivateLink**, or **Site-to-Site VPN**, not a VPC. **(high)**
+
+### `X-Ray/_X-Ray.md`
+
+| # | Snippet | Problem | Correct info | Sev |
+|---|---|---|---|---|
+| X1 | X-Ray SDK / Daemon sections | Outdated. **X-Ray SDKs/Daemon entered maintenance mode on 25 Feb 2026** (security fixes only) and AWS recommends migrating to **OpenTelemetry/ADOT** ([support timeline](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-daemon-timeline.html)). End of support is reported as 25 Feb 2027 ([Classmethod](https://dev.classmethod.jp/articles/x-ray-sdk-daemon-migration-to-opentelemetry/), end date unverified on AWS's page). The X-Ray service itself is still supported. | | medium |
+| X2 | X-Ray Daemon | Missing the key exam fact: the daemon listens on **UDP port 2000**. | | medium |
+| X3 | "Comes with Elastic BeanStalk and Lambda by default" | Lambda runs the daemon only when **Active tracing** is enabled. On EB the daemon is pre-installed but must be enabled (`XRayEnabled` option or `.ebextensions`). On EC2/ECS you install/run it yourself (sidecar for ECS). Instances also need IAM permissions (`AWSXRayDaemonWriteAccess`). | | medium |
+| X4 | Annotations: "Up to 50 annotations per trace" | Correct, but it misses the key contrast with Metadata: annotations are **indexed** key-value pairs (string/number/boolean) usable in **filter expressions**. | | medium |
+| X5 | "Errors, Faults, and Exceptions" | Missing the definitions: **Error = 4xx**, **Fault = 5xx**, **Throttle = 429**. | | medium |
+| X6 | "Tracing Header: All requests are traced up to a configurable minimum…" | This is sampling (reservoir + fixed rate) under the wrong heading. The header is `X-Amzn-Trace-Id` (correct) with `Root`, `Parent`, `Sampled` fields. | | low |
+| X7 | "A Trace ID is the path of a request" | A **trace** is the collection of segments produced by one request. The trace ID is its identifier. | | low |
+| X8 | Groups: "Groups only update after you update them, the data before still remains" | Garbled. A group's filter expression applies to **new** traces only after it's created or edited. | | low |
+| X9 | Integration list "ELB" | X-Ray integrates with **ALB** (adds/propagates the trace header), not all ELB types. App Mesh is being discontinued (Sept 2026, **unverified**). | | low |
+| X10 | `[[_Elastic BeanStalk]]` | Broken link. | | low |
+| X11 | `[...]{.underline}` | Pandoc span syntax. It may not render outside Zettlr/Pandoc. | | low |
+| — | Sampling defaults (1 req/s reservoir + 5%) | Correct. | | — |
+
+---
+
+## Broken internal links (consolidated)
+
+Existing note names: `API, AWS, CRUD, HTTP, HTTPS, REST, SQL, VPN, CRUD vs REST, Deployments, _ACM, _ALB, _API Gateway, _AppSync, GraphQL, _Athena, _CloudFront, CloudFront Functions, Lambda@Edge, _CodeBuild, _CodeCommit, _CodeDeploy, _CodePipeline, _ELB, _Lambda, _NLB, _Route53, Record Sets, Route 53 Hosted Zone, Use Cases, _S3, _VPC, _X-Ray`.
+
+| File | Link | Issue |
+|---|---|---|
+| `_Concepts/Deployments.md` | `[[_Elastic BeanStalk]]` | note missing |
+| `ACM/_ACM.md` | `[[ELB]]` ×2 | should be `_ELB` |
+| `ACM/_ACM.md` | `[[API Gateway]]` | should be `_API Gateway` |
+| `ACM/_ACM.md` | `[[_Elastic BeanStalk]]` | note missing |
+| `CloudFront/_CloudFront.md` | `[[AWS WAF]]`, `[[Videos On Demand]]`, `[[ISS Microsoft Smooth Streaming]]` | notes missing |
+| `CodePipeline/_CodePipeline.md` | `[[_CodePipeline\|Build]]` | wrong target, should be `_CodeBuild` |
+| `CodePipeline/_CodePipeline.md` | `[[CodeDeploy\|\|Deploy]]` | double pipe; should be `_CodeDeploy` |
+| `CodePipeline/_CodePipeline.md` | `[[_CloudFormation]]` | note missing |
+| `Lambda/_Lambda.md` | `[[API Gateway\|API Gateway]]` | should be `_API Gateway` |
+| `Lambda/_Lambda.md` | `[[_DynamoDB]]` | note missing |
+| `X-Ray/_X-Ray.md` | `[[_Elastic BeanStalk]]` | note missing |
+
+All three image references resolve to existing PNGs.
+
+## Internal inconsistencies
+
+- `REST.md` ("a kind of CRUD") contradicts `CRUD vs REST.md` ("an architectural style").
+- `Deployments.md` says CodeDeploy Blue/Green covers On-Prem. `_CodeDeploy.md` describes only EC2 blue/green and never mentions Lambda/ECS traffic shifting. Both should state: EC2 (not on-prem), Lambda, ECS.
+- `_CodeBuild.md` uses both `buildspec.yaml` and `buildspec.yml`.
+- `_ACM.md` and `_ELB.md` treat "ELB" as a single attachable thing, while `_ELB.md` defines it as an umbrella term.
+- `_CloudFront.md` and `Lambda@Edge.md` agree on Node.js/Python and Regional Edge Caches, which is consistent and correct.
+
+## Typos and grammar (grouped, low)
+
+- Deployments: "Auto Scailing", "the reregistered", "replace and existing instance", "spin up and extra ELB, the split".
+- ACM: "Amazon Certificate Manager", "certificate" (plural), "Privates", "each instances".
+- AppSync: "Resolvers attached… used to…".
+- GraphQL: "composed on", "data to be create".
+- Athena: "a box contains fictions".
+- CloudFront: "board geographical", "ISS", "OPTION", "pre request", "receives the request from the origin".
+- CodeBuild: "Apache, Maven", "Scaled automatically".
+- CodeCommit: "HIPPA".
+- CodeDeploy: missing comma in the Application description.
+- CodePipeline: "The can pull", "Deploy Actions is a Build Stage", "Pipeline are only limited".
+- HTTPS: "Application on IP layer".
+- Route 53 Use Cases: "our web backed by".
+
+## Could not verify
+
+- Current Lambda@Edge origin-trigger memory maximum (3,008 MB vs 10,240 MB). The AWS comparison page failed to load (TLS error).
+- Whether "Action Groups" is official CodePipeline terminology.
+- X-Ray SDK end-of-support date (25 Feb 2027) on AWS's own page. The maintenance-mode date (25 Feb 2026) is confirmed by AWS docs.
+- App Mesh discontinuation date.
+
+## Conclusions and recommendations
+
+Fix these first, because they're wrong rather than just incomplete:
+1. `VPC/_VPC.md`: rename to Virtual Private Cloud and rewrite the definition. Move the peering/VPN content to a "VPC connectivity" subsection.
+2. `ACM/_ACM.md`: fix pricing (public and imported certs free; Private CA ~$400/month per CA). Add the CloudFront `us-east-1` rule.
+3. `_Concepts/Deployments.md`: rewrite the EB rows (all-at-once is in place; immutable and traffic splitting use a temporary ASG behind the same LB; blue/green is a CNAME swap). Remove "On-Prem" from CodeDeploy blue/green. Add Lambda/ECS canary/linear/all-at-once.
+4. `CloudFront/_CloudFront.md`: remove Route 53 from origins, swap the origin request/response use cases, and update CF Functions (runtime 2.0) and OAI (legacy).
+5. `AppSync/_AppSync.md`: add OIDC and Lambda authorization.
+6. `Glossary/REST.md`, `HTTPS.md`: fix the definitions (REST is an architectural style; HTTPS is HTTP over TLS, port 443).
+7. Update the status notes: CodeCommit is GA again (Nov 2025); X-Ray SDK/Daemon are in maintenance mode (Feb 2026), so prefer ADOT/OpenTelemetry. Add the daemon's UDP 2000 port.
+8. Fix the broken wiki-links, especially CodePipeline's Build → `_CodeBuild`.
+
+Then fill the exam-critical gaps: S3, ALB/NLB, API Gateway, Lambda limits, Route 53 routing policies, CodeDeploy AppSpec hooks.

Lambda/_Lambda.md

@@ -1 +0,0 @@
-# Lambda

Papers/Practice Exam 3.md

@@ -0,0 +1,66 @@
+# Practice Exam 3 Mistakes
+
+---
+#### A Developer is creating a DynamoDB table for storing application logs. The table has 5 write capacity units (WCUs). The Developer needs to configure the read capacity units (RCUs) for the table. Which of the following configurations represents the most efficient use of throughput?
+
+- Eventually consistent reads of 5 RCUs reading items that are 4 KB in size
+x Strongly consistent reads of 5 RCUs reading items that are 4 KB in size
+- Eventually consistent reads of 15 RCUs reading items that are 1 KB in size
+- Strongly consistent reads of 15 RCUs reading items that are 1KB in size
+
+> [!note] Correct Answer
+>Eventually consistent reads of 15 RCUs reading items that are 1 KB in size
+
+> [!caution] Explanation 
+> Among these options, the most cost-efficient in terms of maximizing the number of read operations per RCU is: 
+> **Eventually consistent reads of 15 RCUs reading items that are 1 KB in size.**
+>
+> This choice utilizes the RCU allocation most effectively because:
+> - It leverages the lower RCU consumption of eventually consistent reads.
+> - It takes advantage of the smaller item size (1 KB), which requires fewer RCUs for the same number of operations compared to items up to 4 KB.
+---
+#### A developer is creating an AWS Serverless Application Model (AWS SAM) template. It includes several AWS Lambda functions, an Amazon S3 bucket, and an Amazon CloudFront distribution. One Lambda function, running on Lambda@Edge, is integrated with the CloudFront distribution, while the S3 bucket serves as an origin for the distribution.However, upon deploying the AWS SAM blueprint in the us-west-1 Region, the stack's creation fails.What could be the possible reason for this failure?
+- Lambda@Edge functions can only be deployed in the us-east-1 Region.
+- AWS SAM templates are not supported in the us-west-1 Region.
+- Amazon S3 buckets serving as origins for CloudFront must be created in a separate Region from the CloudFront distribution.
+x AWS Lambda functions integrated with CloudFront cannot be deployed using AWS SAM templates.
+
+> [!note]  Correct Answer
+> Lambda@Edge functions can only be deployed in the us-east-1 Region
+
+> [!caution] Explanation 
+> Lambda@Edge functions can only be created in the us-east-1 Region. If you want to deploy such functions, they must be done in this specific region.
+---
+#### A Developer has added a Global Secondary Index (GSI) to an existing Amazon DynamoDB table. The GSI is used mainly for read operations whereas the primary table is extremely write-intensive. Recently, the Developer has noticed throttling occurring under heavy write activity on the primary table. However, the write capacity units on the primary table are not fully utilized.What is the best explanation for why the writes are being throttled on the primary table?
+
+    
+
+There are insufficient read capacity units on the primary table
+
+    
+
+The Developer should have added an LSI instead of a GSI
+
+    
+
+There are insufficient write capacity units on the primary table
+
+    
+
+The write capacity units on the GSI are under provisioned
+
+Correct answer
+
+The write capacity units on the GSI are under provisioned
+
+Feedback
+
+**Explanation:**
+
+Some applications might need to perform many kinds of queries, using a variety of different attributes as query criteria. To support these requirements, you can create one or more global secondary indexes and issue Query requests against these indexes in Amazon DynamoDB.
+
+When items from a primary table are written to the GSI they consume write capacity units. It is essential to ensure the GSI has sufficient WCUs (typically, at least as many as the primary table). If writes are throttled on the GSI, the main table will be throttled (even if there’s enough WCUs on the main table). LSIs do not cause any special throttling considerations.
+
+In this scenario, it is likely that the Developer assumed that the GSI would need fewer WCUs as it is more read-intensive and neglected to factor in the WCUs required for writing data into the GSI. Therefore, the most likely explanation is that the write capacity units on the GSI are under provisioned
+
+--- 

README.md

@@ -1,12 +1,9 @@
-# README
+# Read Me
+This is a collection of notes I have written in order to aid me in my learning. 
 
-- [[_CloudFront|CloudFront]]
-- [[_Lambda|Lambda]]
-- [[_X-Ray|X-Ray]]
-- Code:
-    - [[_CodeBuild|CodeBuild]]
-    - [[_CodeCommit|CodeCommit]]
-    - [[_CodeDeploy|CodeDeploy]]
-    - [[_CodePipeline|CodePipeline]]
- 
-[[_AppSync|AppSync]]
+Use [Zettlr](https://www.zettlr.com/) to view this repository.
+
+TODO:
+- Explore links: 
+  - https://examprep.greglab.net/dva-c02/service/amazon-athena
+  - https://courseiva.com/learn/dva-c02/athena-dva

Study/ACM/_ACM.md

@@ -0,0 +1,30 @@
+# Amazon Certificate Manager
+Provisions, manages, and deploys public and private SSL/TLS certificate for use with [[AWS]] Services.
+
+ACM handles the complexity of creating and managing public SSL/TLS certificates for your [[AWS]] based websites and applications.
+
+ACM handles two kinds of certificates:
+1. Public - Certificates provided by ACM (Free)
+2. Privates - Certificates you import ($400 / month)
+
+ACM can handle multiple subdomains and wildcard domains (*.example.com).
+
+ACM can be attached to the following [[AWS]] resources:
+- [[ELB]]
+- [[_CloudFront|CloudFront]]
+- [[API Gateway]]
+- [[_Elastic BeanStalk|_Elastic BeanStalk]] (through [[ELB]])
+
+## Types
+### Terminating SSL at Load Balancer
+All traffic in-transit beyond the ALB is unencrypted
+![terminating_diagram_at_alb.png](./terminating_diagram_at_alb.png)
+
+You can add as many EC2 instances to the ALB as you need, and you don't need to install certificates on each instances. Less secure, in theory, if someone can grab the data in between the ALB and EC2 instances.
+
+### Terminating SSL End-to-End
+Traffic is encrypted in-transit all the way to the application.
+![terminating_ssl_e2e.png](./terminating_ssl_e2e.png)
+
+It guarantees encryption is end to end. It's more complicated to maintain certificates. You can't do this with ACM by itself. You can set up Let's Encrypt for it.
+

Study/ALB/_ALB.md

@@ -0,0 +1,3 @@
+# Application Load Balancer
+Placeholder.
+

Study/API Gateway/_API Gateway.md

@@ -0,0 +1,12 @@
+# [[API]] Gateway
+A front to some kind of application on [[AWS]]. 
+
+Can be one of three flavors:
+- [[REST]]
+- [[HTTP]]
+- WebSocket
+
+
+https://app.exampro.co/student/material/dva-c02/6956
+
+Still a placeholder.

Study/AppSync/_AppSync.md

@@ -2,7 +2,7 @@
 AppSync is a fully managed [[GraphQL|GraphQL]] service.
 
 Notes:
-- It can support real-time APIs via Graph GraphQL subscriptions.
+- It can support real-time [[API]]s via GraphQL subscriptions.
 - AppSync supports custom domains
 - AppSync has a query editor built into the UI
 
@@ -18,8 +18,8 @@ Where data is being pulled from.
 
 - DynamoDB Table
 - Amazon OpenSearch
-- AWS Lambda Function
-- HTTP Endpoint
+- AWS [[_Lambda|Lambda Function]]
+- [[HTTP]] Endpoint
 - Amazon EventBridge
 - Relational Database (RDS HTTP Endpoint)
 

Study/Athena/_Athena.md

@@ -0,0 +1,5 @@
+# Athena
+
+Amazon Athena is like a library with a massive, disorganised warehouse of books (your data in [[_S3|S3]]). Instead of hiring a librarian to manually sort and read every book each time you ask a question, Athena uses a card catalog system ([[AWS]] Glue Data Catalog). You write a query like `find all books by author X published after 2000` on a slip of paper (SQL Query). The catalog tells Athena exactly which shelves and boxes contain relevant books, so it only opens those boxes and scans those pages. Each book is read by a team of temporary workers (distributed query engine) who work in parallel, each reading different pages and jotting down answers on sticky notes. The workers then hand their notes to a foreman (coordinator) who combines them into a single answer. Crucially, the workers never move the books or write in them - they just read. They are paid per page read (data scanned), so you want the catalog to be precise to avoid paying for scanning the entire warehouse. If the catalog is wrong (a box contains fictions when it's actually non-fiction), the workers might miss books or scan irrelevant ones, wasting time and money. Athena's power is that it can query any book in any format (CSV, JSON, Parquet), as long as the catalog describes how to interpret it, and it never alters the original books.
+
+

Study/CloudFront/_CloudFront.md

@@ -10,7 +10,7 @@
 - [[_CloudFront|CloudFront]] can stream [[Videos On Demand]] using [[ISS Microsoft Smooth Streaming]]
 
 ### Core components
-**Origin**: Location where all original files are located. Examples include: S3, EC2, ELB, Route53.
+**Origin**: Location where all original files are located. Examples include: [[_S3|S3]], EC2, ELB, Route53.
 **Edge Locations**: Compute located strategically close to end users.
 **Regional Caches**: Compute located in board geographical locations to speed up requests for edge locations.
 **Distribution**: A collection of Edge locations and Regional Cache that defines how cached content should behave.
@@ -76,7 +76,7 @@ The more people hit the cache, the better the application performance will be.
 ### Cache Policy
 A **Cache Policy** determines the **Cache Key**.
 
-AWS has managed **Cache Policies** for use:
+[[AWS]] has managed **Cache Policies** for use:
 - `Amplify`
 - `CachingDisabled`
 - `CachingOptimized`
@@ -117,7 +117,7 @@ Happens when there is a cache miss and CloudFront must reach out to Origin to re
 
 ### Response Header Policy
 Allows you to modify the HTTP Headers in the response that viewers will see.
-AWS has managed policies for you to use and you can make your own also.
+[[AWS]] has managed policies for you to use and you can make your own also.
 
 ⚠️ If you are dealing with CORS, you will be setting things here, as this will mess with them.
 
@@ -126,11 +126,11 @@ AWS has managed policies for you to use and you can make your own also.
 Lots of drawbacks. Not available anymore.
 
 ## Origin Access Control
-Same as Origin Access Identity, makes sure that an S3 bucket is only accessible through **CloudFront** and not the internet.
+Same as Origin Access Identity, makes sure that an [[_S3|S3]] bucket is only accessible through **CloudFront** and not the internet.
 
 Overview:
 * Enhanced sec.
-* Comprehensive HTTP support.
-* Supports uploading and downloading encrypted S3 objects with SSE-KMS.
-* Supports accessing S3 in all AWS Regions.
+* Comprehensive [[HTTP]] support.
+* Supports uploading and downloading encrypted [[_S3|S3]] objects with SSE-KMS.
+* Supports accessing [[_S3|S3]] in all [[AWS]] Regions.
 

Study/CodeBuild/_CodeBuild.md

@@ -9,13 +9,13 @@
 ## Workflow
 1. Trigger a build
    * You can trigger a build with AWS Console, CLI, SDK or [[_CodePipeline|CodePipeline]] trigger (like pushing to `main`).
-2. Passes the code onto CodeBuild
+2. Passes the code onto CodeBuild.
 3. You give it a `buildspec.yaml` file, which is generally part of your code base.
    * You can override it with other build commands.
 4. Push into a bucket, or any other AWS SDK action (I think?)
 
 ## Build Environments
-The Docker images that run the CodeBuild, can be managed by AWS or you. If you need specific software, you need to make an image and upload it to ECR and reference it in the pipeline.
+The Docker images that run the CodeBuild, can be managed by [[AWS]] or you. If you need specific software, you need to make an image and upload it to ECR and reference it in the pipeline.
 
 ## `buildspec.yml`
 - Provides the build instructions.

Study/CodeCommit/_CodeCommit.md

@@ -1,11 +1,11 @@
 # CodeCommit
-A fully-managed source control service that hosts secure Git-based repositories. (GitHub for AWS)
+A fully-managed source control service that hosts secure Git-based repositories. (GitHub for [[AWS]])
 
 ## Special features
-- In scope with many compliance programs (HIPPA)
-- Repositories encrypted at rest & in transit
+- In scope with many compliance programs (HIPPA).
+- Repositories encrypted at rest & in transit.
 - Can handle repositories with large numbers of files or branches, large file sizes and lengthy revision histories.
 - No limit on the size of your repositories or on the file types you can store.
 - Keeps your repositories close to your production resources in AWS Cloud, which helps to increase the speed and frequency of your development life-cycle.
-- Uses IAM to control which AWS users have access to which repositories.
+- Uses IAM to control which [[AWS]] users have access to which repositories.
 

Study/CodeDeploy/_CodeDeploy.md

@@ -1,8 +1,8 @@
 # CodeDeploy
 - A fully managed deploy service in the cloud.
-- Can deploy EC2, On-Prem, Lambda, or ECS.
+- Can deploy EC2, On-Prem, [[_Lambda|Lambda]], or ECS.
 - Rapidly release new features.
-- Update AWS Lambda function versions.
+- Update AWS [[_Lambda|Lambda]] function versions.
 - Avoid downtime during application deployments.
 - Integrates with existing CI/CD tools eg. Jenkins, [[_CodePipeline|CodePipeline]].
 - Integrates with existing management tools eg. Puppet, Chef, Ansible.
@@ -12,7 +12,7 @@
 The unique identifier for the application being deployed. Ensures the correct combination of revision deployment configuration, and group are referenced during deployment. 
 
 ### Deployment Groups
-A set of EC2 instances or Lambda Functions where the new revision is deployed to
+A set of EC2 instances or [[_Lambda|Lambda Functions]] where the new revision is deployed to.
 
 ### Deployment
 This is the process and components used to apply a new application revision.

Study/CodePipeline/_CodePipeline.md

@@ -2,9 +2,9 @@
 A fully managed CI/CD pipeline.
 
 - **Pipeline** is what encompasses all components.
-- **Stage** represents a step in the pipeline. The most common steps would be Source -> Build -> Deploy. You may add many stages, so use your creativity.
+- **Stage** represents a step in the pipeline. The most common steps would be [[_CodeCommit|Source]] -> [[_CodePipeline|Build]] -> [[CodeDeploy||Deploy]]. You may add many stages, so use your creativity.
 - **Action Groups** group several **Actions** together.
-- **Actions** do things. The can pull source code, build and run tests, deploy to production, invoke a [[_Lambda|_Lambda]], invoke a [[_CloudFormation|CloudFormation]] template.
+- **Actions** do things. The can pull source code, build and run tests, deploy to production, invoke a [[_Lambda|Lambda]], invoke a [[_CloudFormation|CloudFormation]] template.
 - **Artifacts** are zips containing files outputted by an **Action**. An **Artifact** can be passed to any future **Actions** and some **Actions** require to input an **Artifact** and can optionally output an **Artifact**.
 - **Stage Transitions** link the pipeline stages together.
 

Study/ELB/_ELB.md

@@ -0,0 +1,7 @@
+# Elastic Load Balancer
+An ELB is a general term for multiple types of "load balancer" in [[AWS]]. 
+
+Examples include:
+- [[_ALB|Application Load Balancer]]
+- [[_NLB|Network Load Balancer]]
+

Study/Lambda/_Lambda.md

@@ -0,0 +1,4 @@
+# Lambda
+#Placeholder
+A Docker container or a runner that runs code for you. At a high level, it can run code behind an [[API Gateway|API Gateway]], interact with basically all [[AWS]] Resources (most commonly [[_S3|S3]], [[_DynamoDB|DynamoDB]], other [[_Lambda|Lambdas]]). 
+

Study/NLB/_NLB.md

@@ -0,0 +1,3 @@
+# Network Load Balancer
+Placeholder.
+

Study/Practice/Read and Write Units - Set 3.md

@@ -0,0 +1,128 @@
+# DynamoDB Read/Write Units — Numeric Practice, Set 3
+
+20 questions. Give a numeric answer for each, using `1 = <number>`, `2 = <number>`, and so on.
+
+## Assumptions
+
+- Assume provisioned capacity and steady workloads.
+- All item sizes are exact DynamoDB item sizes, including attribute names and values.
+- Each read accesses an individual item, not a Query or Scan. Transactional operations count individual items, not transaction API calls.
+- Normal writes are non-transactional. All writes create new items.
+- Ignore indexes, replication, retries, failed requests, burst capacity and partition limits.
+- Questions 1–14 ask for exact throughput requirements: fractional RCU answers are valid; do not round the final result to a whole number.
+- Questions 15–18 ask for the maximum number of individual item operations per second.
+- Questions 19–20 ask for whole-number provisioned capacity settings.
+
+## Questions
+
+### 1. You normally write six separate 1.8 KB items every second. How many WCUs are required?
+
+Answer: ______
+
+### 2. You normally write nine separate 0.7 KB items every second. How many WCUs are required?
+
+Answer: ______
+
+### 3. You normally write four separate 3.01 KB items every second. How many WCUs are required?
+
+Answer: ______
+
+### 4. You transactionally write three separate 2.01 KB items every second. How many WCUs are required?
+
+Answer: ______
+
+### 5. You transactionally write six separate 1 KB items every second. How many WCUs are required?
+
+Answer: ______
+
+### 6. You perform strongly consistent reads of five separate 5 KB items every second. How many RCUs of throughput are required?
+
+Answer: ______
+
+### 7. You perform strongly consistent reads of three separate 12 KB items every second. How many RCUs of throughput are required?
+
+Answer: ______
+
+### 8. You perform eventually consistent reads of nine separate 0.8 KB items every second. How many RCUs of throughput are required?
+
+Answer: ______
+
+### 9. You perform eventually consistent reads of five separate 8.01 KB items every second. How many RCUs of throughput are required?
+
+Answer: ______
+
+### 10. You perform eventually consistent reads of seven separate 8 KB items every second. How many RCUs of throughput are required?
+
+Answer: ______
+
+### 11. You transactionally read five separate 4.01 KB items every second. How many RCUs of throughput are required?
+
+Answer: ______
+
+### 12. You transactionally read three separate 11 KB items every second. How many RCUs of throughput are required?
+
+Answer: ______
+
+### 13. Each second, you normally write two 0.6 KB items and three 2.4 KB items to the same table. How many WCUs are required in total?
+
+Answer: ______
+
+### 14. Each second, you perform strongly consistent reads of two 5 KB items and eventually consistent reads of three 1 KB items from the same table. How many RCUs of throughput are required in total?
+
+Answer: ______
+
+### 15. You have 28 WCUs available. What is the maximum number of normal item writes per second you can sustain if each item is 3.2 KB?
+
+Answer: ______
+
+### 16. You have 30 WCUs available. What is the maximum number of transactional item writes per second you can sustain if each item is 2.2 KB?
+
+Answer: ______
+
+### 17. You have 15 RCUs available. What is the maximum number of eventually consistent item reads per second you can sustain if each item is 9 KB?
+
+Answer: ______
+
+### 18. You have 32 RCUs available. What is the maximum number of transactional item reads per second you can sustain if each item is 5 KB?
+
+Answer: ______
+
+### 19. You perform eventually consistent reads of eleven separate 3 KB items every second. What is the minimum WHOLE NUMBER of RCUs you must provision?
+
+Answer: ______
+
+### 20. You perform eventually consistent reads of five separate 12.01 KB items every second. What is the minimum WHOLE NUMBER of RCUs you must provision?
+
+Answer: ______
+
+## Answer key
+
+<details>
+<summary>Show answers and calculations</summary>
+
+`ceil` means round up to the next whole number. Sizes are divided by the 1 KB write or 4 KB read increment before rounding.
+
+1. **12 WCUs** — `ceil(1.8 / 1) × 6 = 2 × 6`.
+2. **9 WCUs** — `ceil(0.7 / 1) × 9 = 1 × 9`.
+3. **16 WCUs** — `ceil(3.01 / 1) × 4 = 4 × 4`.
+4. **18 WCUs** — `ceil(2.01 / 1) × 3 × 2 = 3 × 3 × 2`.
+5. **12 WCUs** — `ceil(1 / 1) × 6 × 2 = 1 × 6 × 2`.
+6. **10 RCUs** — `ceil(5 / 4) × 5 = 2 × 5`.
+7. **9 RCUs** — `ceil(12 / 4) × 3 = 3 × 3`.
+8. **4.5 RCUs** — `ceil(0.8 / 4) × 9 × 0.5 = 1 × 9 × 0.5`.
+9. **7.5 RCUs** — `ceil(8.01 / 4) × 5 × 0.5 = 3 × 5 × 0.5`.
+10. **7 RCUs** — `ceil(8 / 4) × 7 × 0.5 = 2 × 7 × 0.5`.
+11. **20 RCUs** — `ceil(4.01 / 4) × 5 × 2 = 2 × 5 × 2`.
+12. **18 RCUs** — `ceil(11 / 4) × 3 × 2 = 3 × 3 × 2`.
+13. **11 WCUs** — `(ceil(0.6 / 1) × 2) + (ceil(2.4 / 1) × 3) = 2 + 9`.
+14. **5.5 RCUs** — `(ceil(5 / 4) × 2) + (ceil(1 / 4) × 3 × 0.5) = 4 + 1.5`.
+15. **7 writes/s** — `28 / ceil(3.2 / 1) = 28 / 4`.
+16. **5 transactional item writes/s** — `30 / (ceil(2.2 / 1) × 2) = 30 / 6`.
+17. **10 reads/s** — `15 / (ceil(9 / 4) × 0.5) = 15 / 1.5`.
+18. **8 transactional item reads/s** — `32 / (ceil(5 / 4) × 2) = 32 / 4`.
+19. **6 provisioned RCUs** — `ceil(ceil(3 / 4) × 11 × 0.5) = ceil(5.5)`.
+20. **10 provisioned RCUs** — `ceil(ceil(12.01 / 4) × 5 × 0.5) = ceil(10)`.
+
+For questions 1–14, RCUs describe exact throughput requirements. Provisioned settings must be whole numbers, as explicitly requested in questions 19–20.
+
+</details>

Study/Route 53/Record Sets.md

@@ -0,0 +1,5 @@
+# [[_Route53|Route 53]] Record Sets
+Record sets are a collection of records which determine where to send traffic.
+
+They are always changed in batch via the API.
+

Study/Route 53/Route 53 Hosted Zone.md

@@ -0,0 +1,15 @@
+# [[_Route53|Route 53]] Hosted Zone
+A hosted zone is a container for [[Record Sets|Record Sets]], scoped to route traffic to a specific domain or subdomain.
+
+There are 2 types of [[Route 53 Hosted Zone|Route 53 Hosted Zones]]:
+- Public Hosted Zones: How you want to route traffic inbound from the Internet
+- Private Hosted Zones: How you want to route traffic within an Amazon [[_VPC|VPC]].
+
+
+```mermaid
+flowchart TD
+    DomainHZ --> RecordSet
+    RecordSet --> WildcardRecordSet
+```
+
+Revisit this.

Study/Route 53/Use Cases.md

@@ -0,0 +1,10 @@
+# [[_Route53|Route 53]] Use Cases
+Use Route 53 to get your custom domains to point at your [[AWS]] Resources. 
+
+![route_53_routing_example.png](./route_53_routing_example.png)
+1. Incoming internet traffic.
+2. Route traffic to our web backed by [[_ALB|ALB]].
+3. Route traffic to an instance we use to tweak our AMI.
+4. Route traffic to [[_API Gateway|API Gateway]], which powers our [[API]].
+5. Route traffic to [[_CloudFront|CloudFront]] which serves our [[_S3|S3]] static hosted website.
+6. Route traffic to an Elastic IP (EIP), which is a static IP that hosts a game server.

Study/Route 53/_Route53.md

@@ -0,0 +1,16 @@
+# Route 53
+A DNS with [[AWS]] Services.
+
+You can:
+- Register and manage domains.
+- Create various records sets on a domain.
+- Implement complex traffic flows (Blue/Green[^1], failovers).
+- Continuously monitor records via health checks.
+- Resolve [[_VPC|VPC]]'s outside of [[AWS]].
+
+[^1]: See [[Deployments|Deployments]].
+
+
+
+
+

Study/S3/_S3.md

@@ -0,0 +1,3 @@
+# S3
+Think of Stanley's Bucket from The Stanley Parable.
+

Study/VPC/_VPC.md

@@ -0,0 +1,4 @@
+# VPC
+Virtual Private Connection. 
+
+A private link between 2 places. It can be used as a way to connect 2 different [[AWS]] accounts via a link that only these two accounts can use. Consider this a [[VPN]] between two places that is managed by [[AWS]].

Study/X-Ray/_X-Ray.md

@@ -1,5 +1,5 @@
 # X-Ray
-AWS [[_X-Ray|X-Ray]] is a AWS Managed service for diagnosing issues (performance and failures) in a microservice architecture. The main idea is that you pass headers in your calls, AWS picks up on those headers and looks at the propagation of the requests across bits of AWS.
+[[_X-Ray|AWS X-Ray]] is a [[AWS]] Managed service for diagnosing issues (performance and failures) in a microservice architecture. The main idea is that you pass headers in your calls, [[AWS]] picks up on those headers and looks at the propagation of the requests across bits of [[AWS]].
 
 It's a distributed tracing system. 
 
@@ -16,12 +16,12 @@ flowchart LR
 ```
 
 ## X-Ray SDK
-- The SDK provides **interceptors** to trace HTTP requests
-- **Client handlers** to **instrument** AWS SDK clients that your application uses to call other AWS Services
-- A HTTP Client to use to instrument calls to other internal and external HTTP web services
+- The SDK provides **interceptors** to trace [[HTTP]] requests
+- **Client handlers** to **instrument** AWS SDK clients that your application uses to call other [[AWS]] Services
+- A [[HTTP]] Client to use to instrument calls to other internal and external [[HTTP]] web services
 
 ## X-Ray Instrumentation
-Measure he level of product's performance to diagnose errors and write trace information.
+Measure the level of product's performance to diagnose errors and write trace information.
 
 ## X-Ray-Daemon
 It buffers segments into a queue and uploads in batches.
@@ -38,7 +38,7 @@ Comes with [[_Elastic BeanStalk]] and [[_Lambda]] by default.
 
 * **Subsegments**:
     * More granular timing information.
-    * Can contain calls to other AWS services
+    * Can contain calls to other [[AWS]] services.
 
 * **Service Graph**:
     * Just the UI graph in the Console.
@@ -54,7 +54,7 @@ Comes with [[_Elastic BeanStalk]] and [[_Lambda]] by default.
         * The first request each second...
         * And 5% of any additional requests.
     * Idea is to reduce service charges when you are getting started. The default sampling rate is low.
-    * You can create limits for the rates
+    * You can create limits for the rates.
 
 * **Tracing Header**:
     * All requests are traced up to a configurable minimum.
@@ -63,11 +63,11 @@ Comes with [[_Elastic BeanStalk]] and [[_Lambda]] by default.
     * The Tracing Header determines if the trace shows up in the viewer.
 
 * **Filter Expressions**:
-    * Applications make a lot of data, you can filter it
+    * Applications make a lot of data, you can filter it.
 
 * **Groups**:
     * Named Filter Expressions.
-    * Groups only update after you update them, the data before still remains (subsequent traces only)
+    * Groups only update after you update them, the data before still remains. (subsequent traces only)
 
 * **Annotations**:
     * Up to 50 annotations per trace.
@@ -82,7 +82,7 @@ Comes with [[_Elastic BeanStalk]] and [[_Lambda]] by default.
 
 ## X-Ray Service Integration
 - [[_Lambda|Lambda]]
-- Api Gateway
+- [[_API Gateway|API Gateway]]
 - ELB
 - SNS
 - SQS

Study/_Concepts/CRUD vs REST.md

@@ -0,0 +1,5 @@
+# [[CRUD|CRUD]] vs [[REST|REST]]
+[[REST|REST]] is an architectural style for designing web services. It represents state transfer through HTTP methods.
+
+[[CRUD]] is more general. It represents the 4 foundational actions of data management: Create, Read, Update, Delete.
+

Study/_Concepts/Deployments.md

@@ -1,4 +1,4 @@
-# Deployments
+# [[AWS]] Deployments
 
 [[_CodeDeploy|CodeDeploy]]
 [[_Elastic BeanStalk|_Elastic BeanStalk]]
@@ -9,7 +9,7 @@
 |  `CodeDeploy` |  Blue/Green | Higher Cost |  Make a new set of instances, install the latest version, start the latest version and then validate them. Once validated, they replace and existing instance in the ELB. The old instances can be terminated or kept running. | EC2 / On-Prem, Lambda & ECS.  |
 |  `ElasticBeanstalk` |  All at Once | Downtime |  Default policy. Takes everything out of service. Recreates the instances and boots them again. Fastest deployment for EB. | EB |
 |  `ElasticBeanstalk` |  Rolling | Lowered Capacity |  Slowly switch out instances over time. Safer than **All at Once**.  | EB |
-|  `ElasticBeanstalk` |  Rolling with Aditional Batches | Higher Cost |  You spin up an extra batch. Then you switch out the old instances over time until one is left, which you discard. | EB |
+|  `ElasticBeanstalk` |  Rolling with Additional Batches | Higher Cost |  You spin up an extra batch. Then you switch out the old instances over time until one is left, which you discard. | EB |
 |  `ElasticBeanstalk` |  Immutable | Higher Cost |  You spin up an entire extra Auto Scailing Group, then once ready, point the ELB to the new ASG. The safest way to deploy applications because the old instances remain. | EB |
 |  `ElasticBeanstalk` |  Blue/Green | Higher Cost |  You spin up an entire extra ELB, then switch out the URLs. | EB |
 |  `ElasticBeanstalk` |  Traffic Shifting | Higher Cost |  You spin up and extra ELB, the split the traffic between the two, until you are satisfied your application works. | EB |

Study/_Concepts/Glossary/API.md

@@ -0,0 +1,2 @@
+# API
+Application Programming Interface. A way that a program can interact with another program or computer.

Study/_Concepts/Glossary/AWS.md

@@ -0,0 +1,2 @@
+# [[AWS]]
+Amazon Web Services. Plain and simple.

Study/_Concepts/Glossary/CRUD.md

@@ -0,0 +1,2 @@
+# CRUD
+Stands for Create, Read, Update, Delete. These are the four foundational actions of data management.

Study/_Concepts/Glossary/HTTP.md

@@ -0,0 +1,2 @@
+# HTTP
+Hypertext Transfer Protocol. Web browser protocol.

Study/_Concepts/Glossary/HTTPS.md

@@ -0,0 +1,2 @@
+# HTTPS
+Stands for Hypertext Transfer Protocol Secure. It is [[HTTP]] with a layer of encryption, either on the Application on IP layer.

Study/_Concepts/Glossary/REST.md

@@ -0,0 +1,3 @@
+# REST
+Representational State Transfer. A kind of [[CRUD]]. It uses [[HTTP]] methods to provide data manipulation.
+

Study/_Concepts/Glossary/SQL.md

@@ -0,0 +1,2 @@
+# SQL
+Structured Query Language. Usually used to interface with databases by performing [[CRUD]] operations.

Study/_Concepts/Glossary/VPN.md

@@ -0,0 +1,2 @@
+# VPN
+Virtual Private Network. Secures connections between two networks.