CSAA Part 1
CSAA Part 1
html
https://aws.amazon.com/iam/features/mfa/
https://aws.amazon.com/iam/features/
note that the IAM account signin URL is different from the Root account signin URL
https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-
policies/
https://aws.amazon.com/organizations/features/
https://aws.amazon.com/blogs/security/getting-started-follow-security-best-practices-as-you-
configure-your-aws-resources/
JavaScript Object Notation - is a human readable and easily parsed structured data format used
to pass blocks of data into & between systems
https://aws.amazon.com/blogs/security/getting-started-follow-security-best-practices-as-you-
configure-your-aws-resources/
The key driver here is cost, so an awareness of cost is necessary to answer this. Full S3 is quite
expensive at around $0.023 per GB for the lowest band. S3 standard IA is $0.0125 per GB, S3
One-Zone-IA is $0.01 per GB, and Legacy S3-RRS is around $0.024 per GB for the lowest band.
Of the offered solutions SS3 One-Zone-IA is the cheapest suitable option. Glacier cannot be
considered as it is not intended for direct access, however it comes in at around $0.004 per GB.
Of course you spotted that RRS is being deprecated, and there is no such thing as S3 -
Provisioned IOPS. In this case OneZone IA should be fine as users will 'post' material but only
the organization will access it and only to find relevant material. The question states that there is
no concern if some material is lost.
Signed URLs and Signed Cookies are different ways to ensure that users attempting access to
files in an S3 bucket can be authorised. One method generates URLs and the other generates
special cookies but they both require the creation of an application and policy to generate and
control these items. An Origin Access Identity on the other hand, is a virtual user identity that is
used to give the CloudFront distribution permission to fetch a private object from an S3 bucket.
Public S3 buckets should never be used unless you are using the bucket to host a public website
and therefore this is an incorrect option.
Virtual style puts your bucket name 1st, s3 2nd, and the region 3rd. Path style puts s3 1st and
your bucket as a sub domain. Legacy Global endpoint has no region. S3 static hosting can be
your own domain or your bucket name 1st, s3-website 2nd, followed by the region. AWS are in
the process of phasing out Path style, and support for Legacy Global Endpoint format is limited
and discouraged. However it is still useful to be able to recognize them should they show up in
logs.
Until 2018 there was a hard limit on S3 puts of 100 PUTs per second. To achieve this care
needed to be taken with the structure of the name Key to ensure parallel processing. As of July
2018 the limit was raised to 3500 and the need for the Key design was basically eliminated. Disk
IOPS is not the issue with the problem. The account limit is not the issue with the problem.
This IP Address is specific to AWS, where you can use it on any instance to acquire information
about that instance. It is a specific type of address called a 'link-local address', and is only
accessible from that particular instance. You can also disable the metadata service to prevent it's
misuse
EBS uses Block-based storage, where the data is stored on a virtual disk managed by the
Operating System. EFS uses File-based storage, where the underlying filesystem is managed by
AWS. S3 uses Object-based storage, where files are kept in a flat structure
Therefore, of the options available in the question, the Cold (sc1) and Throughout Optimized
(st1) types are HDD based and will be the lowest cost options.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html
This is because the IAM Policy exists in the AWS API, rather than on the instance itself. As a way
to remember it in a scenario, if you think about a compromised system, you would need to
revoke the access immediately, without waiting for changes to take effect
If the original snapshot was deleted, then the AMI would not be able to use it as the basis to
create new instances. For this reason, AWS protects you from accidentally deleting the EBS
Snapshot, since it could be critical to your systems. To delete an EBS Snapshot attached to a
registered AMI, first remove the AMI, then the snapshot can be deleted