CloudFront

Question 1

In CloudFront, what is the Origin?

Answer 1

The source of the original version of your content to be cached.

Question 2

In CloudFront, what is a Distribution?

Answer 2

A Distribution is the configuration entity within CloudFront that defines how your content is delivered to end users

Question 3

In CloudFront, what are Edge Locations?

Answer 3

They are local caches of your data.

Question 4

In CloudFront, where are Distributions pushed out to?

Answer 4

Edge Locations.

Question 5

In CloudFront, what are Regional Edge Caches?

Answer 5

Larger caches that Edge Locations can query when they get a cache miss. They are fewer in number but larger in size.

Question 6

In CloudFront what is it called, and what happens, if a user requests some content and the Edge Location doesn’t have it?

Answer 6

It’s called a Cache Miss.
The Edge Location will check the Regional Edge Cache.

Question 7

With CloudFront, what happens if the Regional Edge Cache doesn’t have the content that an Edge Location has requested?

Answer 7

It performs an Origin Fetch.

Question 8

Does CloudFront work with SSL/TLS certificates for HTTPS?

Answer 8

Yes

Question 9

Does CloudFront integrate with ACM?

Answer 9

Yes

Question 10

How does write-caching work with CloudFront?

Answer 10

Write-caching isn’t supported with CloudFront.

Question 11

With CloudFront, where do uploads go?

Answer 11

Directly to the Origin. Write-caching isn’t supported.

Question 12

With CloudFront, what are Behaviours?

Answer 12

They are sub-configurations within Distributions, are associated with a path pattern. They allow multiple configurations of Origins and cache behaviour.

Question 13

How many Behaviours can there be in a CloudFront Distribution?

Answer 13

Minimum of one, but there can be more.

Question 14

What is the default TTL for a Behaviour?

Answer 14

24 hours.

Question 15

What other TTL values can be set at the Behaviour level?

Answer 15

Minimum TTL and Maximum TTL.

Question 16

What effect do the Behaviour-level minimum and maximum TTL values have?

Answer 16

They limit the range of TTL values that objects can use.

Question 17

What happens if an object’s TTL value is outside the Behaviour-level minimum or maximum TTL values?

Answer 17

The object’s TTL will be re-set to the limit that it exceeded.

Question 18

What are the three Origin headers that can define TTL at a per-object level (including their unit) ?

Answer 18

1. Cache-Control max-age (seconds)
2. Cache-Control s-maxage (seconds)
3. Expires (date & time)

Question 19

What first step occurs when a request is made to an Edge Location for an object whose TTL has expired?

Answer 19

The Edge Location will forward the request to the Origin.

Question 20

When an Edge Location forwards a request to the Origin for a TTL-expired object, what does the Origin do if the object is unchanged?

Answer 20

It will respond with HTTP 304 (Not Modified).

Question 21

When the Edge Location receives an HTTP Not Modified from the Origin, what will it do next?

Answer 21

The Edge Location will deliver the object to the user from its cache.

Question 22

When an Edge Location forwards a request to the Origin for a TTL-expired object, what does the Origin do if the object has changed?

Answer 22

The Origin sends an HTTP 200 response that includes the new version of the object.

Question 23

How are object-level TTLs set when using S3?

Answer 23

They are set via object metadata.

Question 24

How are object-level TTLs set when using a Custom Origin?

Answer 24

They are set by the web/application server.

Question 25

Is filename versioning related to S3 object versioning?

Answer 25

No! They are completely separate things.

Question 26

At what level are cache invalidations performed?

Answer 26

They are performed on the whole Distribution.

Question 27

Are all Edge Locations affected by a cache invalidation?

Answer 27

Yes.

Question 28

What does a cache invalidation do?

Answer 28

It immediately expires any objects that match a specified pattern, such as /images/*

Question 29

What is the main downside of using invalidations?

Answer 29

There is an AWS charge.

Question 30

What is the recommended alternative to using invalidations?

Answer 30

Versioned filenames.

Question 31

What are the four benefits of using versioned filenames?

Answer 31

1. Avoids invalidations 2. Avoids stale versions cached by web browsers 3. Logs will be more useful because object names will indicate the version. 4. Allows Edge Locations to retain previous versions.

Question 32

What is the most cost-effective way to handle frequently updated objects, instead of using cache invalidation?

Answer 32

Versioned filenames. This will avoid the AWS charge for invalidations.

Question 33

What format does the CloudFront distribution default CNAME have?

Answer 33

[random-characters].cloudfront.net

Question 34

You have created a new CloudFront distribution but have not created a certificate or assigned an alternate domain name. Does this distribution support SSL?

Answer 34

Yes, using a default CNAME.

Question 35

How does CloudFront support SSL by default without requiring the user to issue their own certificate?

Answer 35

It uses a wildcard certificate for *.cloudfront.net

Question 36

What does the Alternate Domain Name feature allow you to do?

Answer 36

Use your own domain name to front your CloudFront distribution, eg. www.catagram.io.

Question 37

When configuring an alternate domain name for your CloudFront distribution, why is it better to use a certificate to prove domain ownership, if that domain is hosted on Route 53?

Answer 37

Because you'll need a certificate for SSL anyway (ie. one that matches your custom domain).

Question 38

What must the SAN of the certificate match? (two possibilities)

Answer 38

The SAN must be the same as alternate domain name, OR a wildcard that matches it.

Question 39

Can SAN wildcards match greater than one level of subdomain? E.g. if the SAN says *.catagram.io, can the cert be used for a domain name web.corp.catagram.io?

Answer 39

No.

Question 40

In a given client-server session via CloudFront, how many SSL sessions exist?

Answer 40

Two.

Question 41

In a given client-server session via CloudFront, what are the two SSL connections called?

Answer 41

1. The Viewer connection or request 2. The Origin connection or request

Question 42

When generating certificates with CloudFront, what ACM region must you use? Why?

Answer 42

us-east-1, because CF distributions are always tied to the us-east-1 region.

Question 43

Do the Viewer and Origin SSL sessions require their own valid certificates?

Answer 43

Yes.

Question 44

When was the SNI extension to TLS introduced?

Answer 44

2003.

Question 45

Prior to the introduction of SNI, why wasn't it possible for a TLS-terminating web server to serve multiple websites from the same IP?

Answer 45

Because the only way to know which site a user is requesting is via the HTTP header "Host"; but HTTP (layer 7) cannot be established until TLS (layer 4) is established, and TLS can't match the FQDN to the certificate if it doesn't know which certificate to serve to the user.

Question 46

In technical terms, what does the SNI extension allow TLS to include in its handshake, and what does this allow the server to do?

Answer 46

To include Host (ie. the requested FQDN) information in the TLS handshake, allowing the server to respond with the associated certificate for that FQDN.

Question 47

You have clients with older web browsers - what is the issue with SNI here?

Answer 47

Older browsers won't support it.

Question 48

What is the CloudFront mitigation for older browsers that don't support SNI?

Answer 48

Dedicated IPs.

Question 49

Why would you choose to use the CloudFront dedicated IP option?

Answer 49

Because your clients don't support SNI (usually because of older web browsers)

Question 50

What is the downside of the CloudFront dedicated IP option?

Answer 50

Cost. Around $600pcm per distribution.

Question 51

Broadly speaking, what do Origin Access Identity (OAI) and Origin Access Control (OAC) do?

Answer 51

They restrict access to CloudFront origins, usually to prevent clients accessing the origin directly.

Question 52

What is Origin Access Identity (OAI) designed to protect?

Answer 52

S3 buckets ONLY.

Question 53

How does Origin Access Identity (OAI) protect S3 buckets?

Answer 53

By creating a special user, which CloudFront uses to access your S3 bucket, ensuring that only CloudFront can serve the content from the S3 bucket.

Question 54

What types of origins can OAC protect? (Two types)

Answer 54

Both S3 origins and custom origins.

Question 55

When OAC is enabled, what effect does it have on Origin requests?

Answer 55

OAC signs the Edge Location's request to the origin.

Question 56

What two methods can be used to secure CloudFront custom origins?

Answer 56

1. Use OAC to add a custom header, which the origin is configured to authenticate & authorise. 2. Firewalling the origin with a whitelist based on the published list of Edge Location IPs.

Question 57

Can OAI protect custom origins?

Answer 57

No. It can only protect S3.

Question 58

Can OAC use IAM for granular control?

Answer 58

Yes.

Question 59

Can OAI use IAM for granular control?

Answer 59

No.

Question 60

Does CloudFront Geo Restriction allow whitelisting/blacklisting by city?

Answer 60

No, it can only provide country-level granularity.

Question 61

What is the main advantage of using CloudFront Geo Restriction?

Answer 61

Simplicity - everything is self-contained within AWS.

Question 62

What is the main disadvantage of CloudFront Geo Restriction?

Answer 62

It can restrict based only on the country of the client's IP.

Question 63

Is CloudFront Geo Restriction applied at the Behaviour level, Distribution level, or Origin level?

Answer 63

Distribution.

Question 64

What is the main advantage of Third Party Geolocation?

Answer 64

It can make allow/deny decisions based on anything that the app server has access to. E.g. IP geolocation, user, browser, app state, etc.

Question 65

What additional AWS resource(s) is required when using Third Party Geolocation?

Answer 65

One or more compute instances (to make decisions)

Question 66

If you want to make content restriction decisions based on license, which option do you need to use?

Answer 66

Third Party Geolocation.

Question 67

If you want to make content restriction decisions based on user data fields, which option do you need to use?

Answer 67

Third Party Geolocation.

Question 68

If you want to make content restriction decisions based on headers, which option do you need to use?

Answer 68

Third Party Geolocation.

Question 69

If you want to make content restriction decisions based on the user's latitude & longitude, which option do you need to use?

Answer 69

Third Party Geolocation.

Question 70

If you want to make content restriction decisions based on the user's city, which option do you need to use: CloudFront Geo Restriction or Third Party Geolocation?

Answer 70

Third Party Geolocation.

Question 71

If you want to make content restriction decisions based on anything other than the user IP's country, which option do you need to use?

Answer 71

Third Party Geolocation.

Question 72

If you only need to restrict content by country, which option can you use?

Answer 72

CloudFront Geo Restriction.

Question 73

Which CloudFront security mode is the default, public or private?

Answer 73

Public.

Question 74

In CloudFront private mode, how does security work?

Answer 74

Requests must have a signed cookie or signed URL, or they will be denied.

Question 75

Is the CloudFront security mode set per distribution or per behaviour?

Answer 75

Per behaviour.

Question 76

In a real-world scenario what is the likely setting of CF behaviours: all public, all private, or a mixture?

Answer 76

A mixture.

Question 77

In CF terminology, what is the entity called which can create signed cookies or signed URLs?

Answer 77

A signer.

Question 78

What happens as soon as you add a Signer to a behaviour?

Answer 78

The behaviour becomes Private.

Question 79

Are Trusted Key Groups the old way or the new way to control access to a distribution?

Answer 79

The new way.

Question 80

Are CloudFront Keys the old way or the new way to control access to a distribution?

Answer 80

The old way.

Question 81

Why are Trusted Key Groups better than CloudFront Keys? (3 reasons)

Answer 81

1. You don’t have to use the Account’s Root user. 2. They can be managed via the API. 3. Key rotation is easier, because you can add and remove keys to a key group without having to reconfigure your CF distribution.

Question 82

What is the key architectural difference between CloudFront Keys and Trusted Key Groups?

Answer 82

A CloudFront Key is associated directly with a distribution, whereas Trusted Key Groups are a layer of abstraction that allows you to add and remove keys from the group without reconfiguring the distribution.

Question 83

What are two key advantages of signed cookies over signed URLs?

Answer 83

1. Signed cookies can grant access to multiple objects, whereas signed URLs only work for a single object. 2. Signed cookies allow you to preserve the original application URL.

Question 84

Why would you choose signed cookies over signed URLs? (two reasons)

Answer 84

A. You need to grant access to multiple objects. B. You need to preserve original application URLs.

Question 85

When would you choose signed URLs over signed cookies?

Answer 85

If your application doesn’t support cookies.