Dynamic vs explicit mapping in Elasticsearch - Practice Questions

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this dynamic mapping example?

Given the following Elasticsearch mapping and document indexing, what will be the type of the age field in the index?

{
  "mappings": {
    "dynamic": true
  }
}

Document:
{
  "name": "Alice",
  "age": 30
}

A The document will fail to index due to missing explicit mapping.

B "age" will be mapped as a <code>text</code> type by default.

C "age" will be mapped as a <code>long</code> type automatically.

D "age" will be mapped as a <code>keyword</code> type automatically.

💡 Hint

Dynamic mapping tries to guess the field type based on the value.

With dynamic mapping enabled, Elasticsearch detects the age field as a number and maps it as long automatically.

❓ Predict Output

intermediate

What happens when explicit mapping conflicts with dynamic mapping?

Given this explicit mapping and a document, what will be the type of the price field?

{
  "mappings": {
    "properties": {
      "price": { "type": "keyword" }
    },
    "dynamic": true
  }
}

Document:
{
  "price": 19.99
}

A "price" will be mapped as <code>text</code> by dynamic mapping.

B "price" will be mapped as <code>keyword</code> as per explicit mapping, ignoring dynamic mapping.

C "price" will be mapped as <code>float</code> because the document value is a number.

D The document will fail to index due to type conflict.

💡 Hint

Explicit mappings override dynamic mapping for specified fields.

Explicit mapping for price as keyword takes precedence, so dynamic mapping does not change it.

🔧 Debug

advanced

Why does this dynamic mapping cause a runtime error?

Consider this mapping and document indexing attempt:

{
  "mappings": {
    "dynamic": "strict"
  }
}

Document:
{
  "title": "Book",
  "pages": 250
}

What error will Elasticsearch raise when indexing this document?

A Elasticsearch will raise a <code>strict_dynamic_mapping_exception</code> because <code>pages</code> is not defined in mapping.

B Elasticsearch will index the document successfully with dynamic mapping.

C Elasticsearch will ignore the <code>pages</code> field silently.

D Elasticsearch will raise a <code>mapper_parsing_exception</code> due to invalid field type.

💡 Hint

Strict dynamic mapping forbids new fields not defined explicitly.

With dynamic": "strict", Elasticsearch rejects documents with fields not in the mapping, raising strict_dynamic_mapping_exception.

🧠 Conceptual

advanced

How does explicit mapping improve search performance compared to dynamic mapping?

Which of the following best explains why explicit mapping can improve Elasticsearch search performance?

A Explicit mapping forces Elasticsearch to reindex data on every search.

B Explicit mapping disables indexing, so searches are faster.

C Explicit mapping automatically caches all fields, speeding up searches.

D Explicit mapping defines field types and analyzers upfront, allowing optimized indexing and queries.

💡 Hint

Think about how knowing field types helps Elasticsearch.

Explicit mapping lets Elasticsearch know field types and analyzers in advance, so it can index and search more efficiently.

❓ Predict Output

expert

What is the number of fields indexed with this mixed mapping?

Given this mapping and document, how many fields will be indexed?

{
  "mappings": {
    "dynamic": false,
    "properties": {
      "user": { "type": "keyword" },
      "message": { "type": "text" }
    }
  }
}

Document:
{
  "user": "bob",
  "message": "Hello world",
  "timestamp": "2024-06-01T12:00:00Z"
}

A 2 fields will be indexed: <code>user</code> and <code>message</code> only.

B 3 fields will be indexed including <code>timestamp</code>.

C Only 1 field will be indexed because <code>dynamic</code> is false.

D No fields will be indexed due to <code>dynamic</code> false.

💡 Hint

Dynamic false disables indexing of fields not explicitly mapped.

With dynamic": false, only explicitly mapped fields (user and message) are indexed; timestamp is ignored.

Practice

1. What is the main difference between dynamic mapping and explicit mapping in Elasticsearch?

easy

A. Dynamic mapping automatically detects field types, explicit mapping requires manual definition.

B. Dynamic mapping requires manual field type definition, explicit mapping guesses types automatically.

C. Dynamic mapping disables indexing, explicit mapping enables indexing.

D. Dynamic mapping is only for text fields, explicit mapping is only for numeric fields.

Solution

1. Step 1: Understand dynamic mapping

   Dynamic mapping lets Elasticsearch guess the data type of fields automatically when new data arrives.

2. Step 2: Understand explicit mapping

   Explicit mapping means you define each field's type and settings manually before indexing data.

3. Final Answer:

   Dynamic mapping automatically detects field types, explicit mapping requires manual definition. -> Option A

4. Quick Check:

   Dynamic = auto detect, Explicit = manual define [OK]

Hint: Dynamic guesses types; explicit means you set types yourself [OK]

Common Mistakes:

• Confusing which mapping guesses types
• Thinking dynamic disables indexing
• Assuming explicit mapping is only for numbers

2. Which JSON snippet correctly defines an explicit mapping for a field age as an integer?

easy

A. {"mappings": {"properties": {"age": "number"}}}

B. {"mappings": {"age": {"type": "text"}}}

C. {"properties": {"age": "integer"}}

D. {"mappings": {"properties": {"age": {"type": "integer"}}}}

Solution

1. Step 1: Check correct mapping structure

   Explicit mapping requires "mappings" with "properties" and field name with type inside.

2. Step 2: Verify field type for age

   "age" field must have "type": "integer" to define it as integer.

3. Final Answer:

   {"mappings": {"properties": {"age": {"type": "integer"}}}} -> Option D

4. Quick Check:

   Correct JSON structure with integer type [OK]

Hint: Explicit mapping needs mappings > properties > field > type [OK]

Common Mistakes:

• Missing 'properties' level in JSON
• Using wrong type names like 'number' instead of 'integer'
• Placing fields outside 'mappings'

3. Given this explicit mapping, what will be the type of the price field after indexing?

{"mappings": {"properties": {"price": {"type": "float"}}}}

medium

A. integer

B. text

C. float

D. keyword

Solution

1. Step 1: Read the explicit mapping for price

   The mapping defines "price" with "type": "float", so Elasticsearch will store it as a floating-point number.

2. Step 2: Understand type assignment

   Explicit mapping overrides dynamic guessing, so price will be float regardless of input data.

3. Final Answer:

   float -> Option C

4. Quick Check:

   Explicit float mapping means price = float [OK]

Hint: Explicit mapping sets exact type, here float for price [OK]

Common Mistakes:

• Assuming price becomes integer automatically
• Thinking dynamic mapping applies here
• Confusing float with text or keyword

4. You have this mapping snippet:

{"mappings": {"properties": {"date": {"type": "date"}}}}

After indexing a document with "date": "not-a-date", what error will occur?

medium

A. No error, field stored as text

B. Document rejected with parsing exception

C. Field ignored silently

D. Mapping conflict error due to wrong type

Solution

1. Step 1: Check mapping type for date

   The field "date" is explicitly mapped as "date" type, so Elasticsearch expects a valid date format.

2. Step 2: Indexing invalid date string

   Indexing "not-a-date" will cause a parsing exception because it cannot convert the string to a date.

3. Final Answer:

   Document rejected with parsing exception -> Option B

4. Quick Check:

   Invalid date string causes parsing error [OK]

Hint: Invalid date string causes parsing error, not silent ignore [OK]

Common Mistakes:

• Thinking field stores as text automatically
• Assuming no error occurs
• Believing field is ignored silently

5. You want to prevent Elasticsearch from automatically adding new fields to your index but still allow existing fields to be indexed. Which mapping setting should you use?

hard

A. "dynamic": "strict"

B. "dynamic": "true"

C. "dynamic": "false"

D. "dynamic": "runtime"

Solution

1. Step 1: Understand dynamic mapping options

   "dynamic": "true" allows new fields to be added automatically, "false" ignores new fields, "strict" rejects documents with unknown fields.

2. Step 2: Choose setting to prevent new fields but allow existing

   "strict" rejects documents with new fields, so only existing fields are indexed, preventing unwanted additions.

3. Final Answer:

   "dynamic": "strict" -> Option A

4. Quick Check:

   Use strict to block new fields, allow existing [OK]

Hint: Use dynamic: strict to block new fields but keep existing [OK]

Common Mistakes:

• Using dynamic: false which ignores new fields silently
• Using dynamic: true which allows new fields
• Confusing runtime with dynamic setting