Always consider all polices in line to the S3 bucket when troubleshooting S3 access. Remember that on top of S3 bucket policies and ACLs, the IAM policies can also have S3 permissions defined for users, groups, and roles being used to access S3. The policy evaluation flow is shown in Figure 5.2.
FIGURE 5.2 Policy evaluation logic
Answer these questions. The answers follow the last question. If you cannot answer these questions correctly, consider reading this section again until you can.
1. Which of the following S3 tiers is most appropriate for archives that need to be restored in less than seven hours?
A. S3 Infrequent Access
B. S3 Infrequent Access–One Zone
C. Glacier
D. Glacier Deep Archive
2. You have been asked to select a security approach for an S3 bucket. The bucket has two types of users: an owner with unlimited security and writers who deposit work results with a unique filename based on the node name and time. Writers are not allowed to ever read any of the files on S3, even the ones they created.
A. This is not possible on S3 because all writers would need read/write permissions.
B. Create an S3 bucket ACL for the writers with write-only permissions.
C. Create S3 object ACLs for each possible object with write-only permissions.
D. Create an S3 bucket policy for the writers with write-only permissions.
1. Answer: C is correct. The Glacier service can restore any number of archives in less than seven hours.
2. Answer: D is correct. A bucket policy allows you to create a write-only (PutObjects API) rule that allows the writers to only create new files.
This chapter covers the following official AWS Certified SysOps Administrator – Associate (SOA-C02) exam domain:
Domain 2: Reliability and Business Continuity
If you can correctly answer these questions before going through this section, save time by completing the Cram Quiz at the end of the section.
1. What is the maximum number of primary nodes supported in a Multi-AZ RDS MySQL cluster?
2. How many read replicas are supported on DynamoDB global tables?
1. Answer: One. A Multi-AZ has the primary replica for SQL reads and writes in one AZ and a secondary inaccessible synchronous replica in another AZ.
2. Answer: None. DynamoDB global tables are designed with replica tables, which are all primary. Any writes to any of the regions are replicated to all other regions across the globe within one second.
As mentioned in the previous chapter, you can generally sort databases into two categories: relational or SQL and nonrelational or NoSQL (Not only SQL).
Although there are many benefits of using NoSQL databases, such as built-in elasticity, horizontal scalability, high availability, and built-in resilience, many applications still do require the capability to store data in a traditional relational database.
So why are traditional databases so difficult to make highly available and resilient? Any relational database needs to comply with the ACID requirements, which stand for
Atomicity: Transactions need to be atomic. If any suboperation within the transaction fails, the whole transaction needs to fail and be rolled back.
Consistency: Data must be consistent at all times. When written to, data must not be available until the write transaction has completed in its entirety.
Isolation: Concurrent transactions can never interfere with each other and are isolated with unique IDs.
Durability: Data must be stored durably. All operations must be recoverable (transactions can be rolled back; tables or the entire database can be restored from backups).
These requirements mean that there needs to be a central location that validates all the write operations and maintains session isolation and consistency. Essentially, in a traditional application, only one node (the primary) can ever be permitted to perform writes. This means that the database write performance can only scale to the maximum size of that one node. Although mechanisms available out there enable you to design multiprimary databases (for example, Aurora multimaster clusters), they can be difficult to manage and also have a limit of scalability due to the fact that more replication across primaries requires additional resources.