added links

Practice/Papers/Practice Exam 3.md

@@ -0,0 +1,67 @@
+# 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
+
+---
+

Practice/Read and Write Units - Set 3.md

@@ -5,7 +5,7 @@
 ## Assumptions
 
 - Assume provisioned capacity and steady workloads.
-- All item sizes are exact DynamoDB item sizes, including attribute names and values.
+- 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.

Study/DynamoDB/ReadWriteUnits.md

@@ -0,0 +1,19 @@
+# Read / Write Capacity Units
+This is for [[_DynamoDB|DynamoDB]].
+
+The general formula for $CU$s is 
+$$
+\begin{aligned}
+rHz =& \frac{kCU / m}{ceil(nKB/bKB)} \\\ \\
+kCU =& ceil(nKB / bKB) \times rHz \times m \\\ \\
+\text{where:} \\
+nKB =& \text{ input size in KB} \\
+bKB =& \text{ operation block size: 1KB for Writes and 4KB for Reads} \\
+rHz =& \text{ request rate} \\
+m =& \text{ modifier: } \\
+&0.5\text{ for eventually consistent operations, } \\ 
+&1\text{ for normal operations, } \\
+&2\text{ for transactional operations}
+\end{aligned}
+$$
+See [[Read and Write Units - Set 3]] for some examples.

Study/DynamoDB/_DynamoDB.md

@@ -0,0 +1,3 @@
+# DynamoDB
+DynamoDB is a managed Key/Value NoSQL database.
+